Technical Catalog

Teams which does IT Services, Application Development & Maintenance or Mobile development has one thing in common. They get stuck, hit a wall, a problem nags them. Often they come across research for a problems on unknown areas. We need to search about the topic, technical spec, domain, patterns and so on.

That’s where there are helps, forums, stack-overflow etc. The solution you get on internet will be generic. However if your software life cycle is more that one year and a you have a team working on it. Two thing will happen

  1. People will move in and out of the team.
  2. Software will keep evolving.

There will be small technical decision that will be every taken each day which will be specific to out software. which will be taken with the help of some reference link or help from internet. So on one kind of problem/issue the team will have to search all over again to get the background. The solution could be inside the code base, document wiki or over the internet. Below mentioned is a thought to take leverage of efforts already put by the team.

Technical Catalog: It is a simple list of reference links from internet, Small description specific to the software and reference in the software.

Problem Statement Solution Category
Sales report does not work in IE 8 http://someweb.url.com Reports

This will be help the team member starting to resolve any problem to check for the local catalog. which is created by the team with common purpose and goal. Thus helping them to get some initial inertia. Some time it help even the author because we don’t remember what we did six months ago when we stuck at the same problem.

 

 

Why developer takes longer time to write a document

Documenting is a skill which very scares in a developer. Although even if one is good at it, won’t enjoy doing it as contrast to coding.

So in order to solve this hurdle, I have a 5 point strategy to ease the documentation activity:

  1. Don’t treat documenting as second citizen.
  2. Check for correcting grammar and spellings.
  3. Make sure the content can be understood by all stake holders.
  4. You need to review the document to improve it more.
  5. Well formatted document is more effective then simple plain text.

In order to apply few or all the above strategy you will have to go through the above check list one by one, so give a little more time to developers, since they don’t go through formal training or experience.

This also applies to testers, leaders, product managers etc.

Happy documenting !