Documentation Done Right
by in Alex's Soapbox on 2010-10-05Of all people, I have a pretty high standard for doing things right. After all, I’m probably the last person who wants to be caught being The real WTF. This makes things tricky at the Day Job, <shameless_plug>where I work on BuildMaster, a pretty cool system that streamlines and automates the entire development, build, test, and deployment processes.</shameless_plug>, as I’ll often spend an exorbitant amount of time wondering about the best way to do something. Case in point: what’s the right way to do documentation?
Just to be clear, by “documentation”, I don’t mean manuals, user guides, feature matrices, and the like. Those are produced by technical writers, who seemingly enjoy living in the third circle of hell. What I mean is UML, Data-Flow, Flow Charts, Module Breakdowns, and all other works used internally by the development organization. And expanding on the question, which of these documents are we supposed to produce, and how much documentation is needed?