Ant is a freelance Java architect and developer. He has been writing a blog and white papers since 2004 and writes about anything he finds interesting, related to Java or software. Most recently he has been working on enterprise systems involving Eclipse RCP, Google GWT, Hibernate, Spring and J2ME. He believes very strongly in being involved in all parts of the software life cycle. Ant is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

When tool strategy get on your nerves

11.03.2011
| 2580 views |
  • submit to reddit

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

Published at DZone with permission of Ant Kutschera, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Eyal Golan replied on Fri, 2011/11/04 - 12:46am

I don't think it is the tool to be blame, but more the usage of it. Changing "bad" code into "good" code shouldn't be automatically the way Sonar tells. Did you investigate each suggestion of Sonar and thought whether it suits you or not? The other thing is, when and how to do a change, once you agree it is needed. Maybe you could have taken a simpler approach of small steps of refactroing, using some kind of TDD. Also, have you changed code that was not testes and only then constructed tests? I agree with you that sometimes tools can be overkill and sometimes they simply don't suit your project. But I think that once you use it, you should understand it and not be a "drone" using it. And if you see it does not fit your project, don't use it.

Martin Martin S. replied on Fri, 2011/11/04 - 3:13am

Sorry to say that, but "a fool with a tool is still a fool". You cannot blame the tool for your problems. When you start using sonar (which is generally a good idea) you have tons of violations at first. But not every single violation needs to be fixed and not every violation needs to be fixed right now! If your code works, everything is fine, you should take a look at the "blocking" and "critical" violations but for the rest, you should use sonar in your continuous integration process. Get the eclipse plugin(if you are using eclipse) and fix the violation, when you change (and test) the code anyway ("leave the playground cleaner then you found it")

Eyal Golan replied on Fri, 2011/11/04 - 8:51am in response to: Martin Martin S.

Totally agree !

Seb Cha replied on Sat, 2011/11/05 - 10:54am

Sick days for IT.

Like said, the problem is not the tool. The problems come from these dumb non-developer people who force us to misuse tools (if not the wrong tools). Can you just imagine a situation where you decide which tools a surgeon doctor will use to operate on you ?

I'm tired to see that private companies sunk into Totalitarism.

Ant Kutschera replied on Sat, 2011/11/05 - 2:56pm

Yes, I agree with these comments.  I am not saying we should not use the tools.  I actually think we should, because they can help us.  But I think we need to use the tools correctly at the right time, and sadly the powers that be do not understand the problems they are creating by using the tools in the wrong way.  Sadly tools like Sonar come with dashboards which Managment love too much.  Sonar without a dashboard in a webapp which a manager can view would be better.  If it were just a plain old Eclipse plugin that only techies could use, that would be just perfect :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.