Justifying ROI on a wiki.
How to help your boss make a decision to buy a wiki or
Which line do the curly braces go on?
We used to have a big problem with quality, simply put we spent most of our time fixing bugs on old code rather than innovating new products, the problem was code standards.
My team was in 3 countries and we had 3 different sets of coding standards, any collaborations were plagued by technical differences in the code. I wanted to merge the codebase for the main products from all three countries and there for had to get the team to agree to a new set of standards.
I took the traditional approach, got one dev team to make a word document, distribute to all the parties etc … we held meetings to discuss feedback, had reviews and revisions of the document.
After about 3 months we managed to get agreement, and some people started using the new standard ….
However within another 6 months there had been so much change that the standard was out of date, and only a few were following it. Obviously my management team and I tried using the stick, but it just made everyone hate the standard even more. The code was not getting any better and the programmers were still behaving as little teams, rather than as a whole.
So, I copied and pasted the coding standards into our “trac” wiki, which is a free product. I told every one that they must follow the standards, but I also told everyone that anyone could change them. If there was any disagreement then I would make the decision. Over the next couple of months they deleted about ½ the standards, then they had a big row about a whether the curly braces were on the same line.
The end result was that all the developers subscribed to changes of the standards and took an active interest in a) whether they were good and b) how best to follow them.
The difference between wiki and the old “document and versioning” approach was that it allowed standards compliance responsibility to be devolved to a level in the product development team where something could be done about it. I was freed from the mindless task of telling developers to implement the standards, the code was significantly better, there were less bugs and the whole company started making the same products faster.
The investment in installing the wiki (1 day) me adding the standards ( 1 day) the huge row about the curly braces (a lot) was far far out weighed by the reduction in testing and fixing time and the increased revenue by having a better quality product that consumers loved.
About two years after that we started using the wiki for far more important things such as interface specifications, functional specs and architecture documentation.
0COMMENTS