Wednesday, April 12, 2006

Bad Documentation a Norm?

Was talking with people from other software companies and it seems that bad documentation is basically the norm in the industry. It is either very outdated, or it is spread out in bits and pieces, or it is non-existent (close to anyway). However, it is good to know that I am not the only one frustrated about the situation. Amazon is using wiki quite a bit for "informal" documentations, and I heard that some parts of Microsoft is also starting to use it "informally". The wiki model is pretty good in terms of "informal" information that are contributed by the community. Wiki is written and updated mostly by the developers or the people with a direct interest on the topic, so it can be quite a useful tool. It should only be an "informal" tool, one that complements the formal documentation. The problem comes in when wiki's documentation becomes more relevant and update, and developers start to "depend" on it more than the formal documents. Wiki is a good tool but when used in the wrong way, it can cause bad habits across the development community.

Should Wiki replace formal docs? No! I hope not anyway. Trust developers to write documentations on their free will, is like trusting your kids to do their homework by themselves.

This raises another problem, the existents of too many documentation points where information is not consistently updated in either. That is, bits and pieces are updated here and there, and at the end it just becomes a nightmare. Putting the same piece of information on two places are just duplicate effort, and how many are willing to do that? This point is the missing link between formal documentation system and the informal documentation system. How can you cross organize information when it is updated on either one of the system? Maybe in the future some startup will come up with a great solution to the problem!

1 Comments:

At 12:20 AM, Anonymous Anonymous said...

...i agree it is a waste of time to put the same piece of information at two places but i feel the job of the document writer is to make the information at the second location more meaningful and easier to understand for the end user.

but unfortunately most of the time the engineers are so clueless about their piece in the context of the whole system or use case scenario, that the document writers become just as clueless.

that's where tech support and my paycheck comes in.

Maxwell
===

 

Post a Comment

<< Home