Finally, the news you have all been waiting for. [QUEUE DRUMROLL]. My new website has been launched. Sure, I still need to add a few things and tidy up a few others, so watch this space. I have plenty of ideas that will materialise over the coming months, but it's all very top secret at the moment so be sure to bookmark this page and come back soon.
August 2007 Archives
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.
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.
Here are a few photos taken in July of Ohio's Amish Country.