This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Alistair Cockburn on Documentation for Small Teams Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

I explicitly say, ?No documentation is not a valid answer,? as far as I?m concerned because in this cooperative game idea, a game doesn't come as a onesy; a game comes in a series. You?re playing a series of games, and if you aren?t going to do anything with the software afterwards, then no documentation is a fine answer. But if someone else is going to come along and join the team, they have to catch up with you. And the documentation that you produce for the future developers should be targeted directly toward letting them catch up.

Now here?s where we veer off from software engineering. Software engineering gives us somehow the impression, and it could be a false impression or not, but we get this impression that there?s such a thing as verisimilitude, a match-up between our model, our documentation, and the truth of the world, and I don?t happen to buy that!

If you say, however, the purpose of this documentation is to help our new team members catch up with us, you can then shift your mindset about how much, when and what form the documentation should take. So I?m a big fan, for instance, of videotape sessions of two designers discussing at a white board as a piece of training material for the next developer: very fast, very inexpensive to make, very informative, not the classical style documentation.

"Agile Software Development"

As always, IT Conversation interviews don't disappoint. And, as there's MP3s for all of them, you can just download 'em and listen to them while you're walking the dogs.