Documentation: Knowing When Enough is Enough

| No Comments | No TrackBacks
Unlike a lot of programmers, I do not mind documentation as long as it is occasional, does not prevent me from doing my job (documentation should be a part of any programmer's job), and serves a purpose. I understand that it is important to get the requirements and that requirements act as a contract. It's important to test the finished product to make sure that it works and to ensure that the requirements are met. It's important that user guides are also sent out, if the system is one that requires them. I agree with the standards of ISO-9001, and I know that some companies depend on it. However, documentation can also go too far. At this point, I think it is a good idea to take a step back and look over the processes and the procedures. A huge software project that takes a year or more to develop should not be treated the same as a web application that takes two months or two weeks to complete.

For one particular simple 2-page web application (simple HTML, Javascript, CSS), I was required to document everything and spent far too much time with the documentation. Not only that, but there was no scope for change. The client came back with some very minor tweaks, such as a new URL. Each time a simple change was made, each document (requirements, test specifications, design documents) had to be updated and the website fully re-tested. It took much longer to complete the Quality Assurance tasks than it did to make the change. There were four separate instances where minor tweaks were required. It took a few minutes to make the changes and a day to update the documents, re-test, and get the documentation signed off by two individuals.

I am sure this raises the query: How much time should programmers spend on documentation? I'm not sure that I can put a figure on this. I think that this depends on the project, the company, the client, and the cost. I am also certain that other companies or projects go too much the other way and release little or no documentation with their software. 

In short, companies should review each project and determine how much documentation is needed and realise that software and hardware projects are not the same as web-based projects. Time spent on documentation and the types of documentation should be budgeted to avoid over-documentation or under-documentation.
Related Entries

No TrackBacks

TrackBack URL: http://jenikya.com/cgi-bin/mt5/mt-tb.cgi/36

Leave a comment

Archives

OpenID accepted here Learn more about OpenID