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.