Documentation, Friend or Foe?

We were given questions this week regarding contributed assets and lessons learned from our “no one gets hurt” project. As I had already answered these in my previous post, I’ve decided to use this time to talk about what I learnt from a combined post-mortem discussion with all of the groups in my studio unit. What I noticed was the general dislike toward documentation, particularly as our task was to produce a prototype and not a final product. A majority of peers would have preferred to spend the time jumping right in with development straight off the bat.

I’ll admit that in the beginning I took a similar view. However I have since found respect for the documentation process, having realised its importance first hand as a method of reference and organisation for both the project and team members. I believe that had more time been spent populating our documentation with more detailed and accurate information, our prototype would have taken far less time to produce and have been developed in a far more elegant fashion. This also helps prevent us programmers from having to write sloppy prototype code, two birds with one stone.

The trade-off that is spending more time producing documentation and less time on the project may not seem as beneficial at first, in a best case scenario the total duration may equal out to be quite similar. The advantage however is that if major problems arise later on that should have been solved had the proper documentation been produced, the potential risk of the project being heavily delayed is dramatically reduced. As most issues are accounted for early on, the overall quality of the project is also increased and further reduces the risk for potential setbacks due to poor architectural decisions.