When tool strategy get on your nerves

A long time ago, before the days of code prettifiers like Jalopy, we wrote code and we tested code. That code was fun to write. And because it was fun to write, we were motivated to write it well and test it well.

Welcome Jalopy
It was around 2008 when a powerful tool which auto-magically reformatted our code was forced on us. In the beginning we rejoiced, for this tool added "TODO: Document me!" to all methods missing Javadoc (lots). It made it very easy to see where programmers had failed to document their code. The numerous TODOs were also great, because they made it impossible to find the real meaty stuff that still needed to be done. And in classes where our constants were defined, in a specific order so that it matched our documentation, Jalopy kindly reordered the constants alphabetically, making it hard to match code to the documentation.

Enter Sonar
A while later, realising that programmers program bad code even though Jalopy is present to save the world, we had Sonar forced on us. It is a great tool, because it tells us how bad our code is and what we need to change in order to make it good. Ahhh, what is "good" I hear you ask? Well that is defined by a central department who knows nothing of our projects and who doesn't care about architecture (where our real problems lie). The people who work there only want drones who all program in the same way, according to their rules and the rules of academics who make a living writing books about design patterns, which no one really understands and everyone implements wrongly in their own way anyway. But when we realised just how "bad" our code was, it was decided that a tool would be used to automatically modify the bad code and make it good. Bear in mind while reading this, that the bad code was already working well in production, yet the "good" code that was generated still needed testing. So we started testing the generated "good" code and came to realise it didn't always work. But never fear. To reduce the risks, the task to change the bad code into good code was given to human programmers. Unfortunately none had time to change bad code into good code until the end of the release, when the real work came to an end. Having written bad code which was bug free, some programmers now had time to turn the bad code into good code. So they started delivering patches to convert the code, right at the end of the release. That scared some people, so it was decided that they could check the good code straight into the trunk instead of doing so on the branch using patches.

And then Sonar really ruined my day
Today, we started merging patches from the production branch into the trunk, so that we could start on the next release. Didn't work. Merge conflicts. Why? Because people had modified trunk and checked "good" code in. That unforunately means that the patches which have been tested and are known to work now need to be merged with "good" code. The risk that we will introduce bugs during the merging is not as low as it really should be. Some days, I really hate tools.

Still, good things come out of bad things: this was my 100th posting! 

From http://blog.maxant.co.uk/pebble/2011/11/01/1320182520000.html