I am working on a project at work where I am the sole programmer, and also the project manager. It’s a small app, but it still requires the whole design and support documentation to go along with it.

So the question is: what is the correct level of documentation for a small project?

My thoughts so far are to:

• Limit the amount of writing - no reason to give somebody dozens of pages of junk if I could have said it in two.
• Limit the aging of the docs. There’s nothing worse than inaccurate documentation.
• Limit the restatement of what the code is actually doing. This is a small app, if somebody wants to know how I did something, they can pull up the code and see. That’s not to say I won’t discuss architecture, or external interfaces, but that I won’t say “this class does X” and “to do that, call this method on Y”.
• Have two separate documents. One is the business requirements and analysis document, the other is a support document. The idea is that support doesn’t need the requirements, they want step-by-step fixes of common problems, and maybe pointers to DB schemas and such.

This entry was posted on Tuesday, April 29th, 2008 at 10:46 am and is filed under Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.