Most programmers think they can recognize good code and a lot of them think they produce good code, but the sad truth is that not a lot of programmers actually do. Between time constraints, feature creep, and laziness, programmers hardly ever end up producing super quality code.
I remember reading articles about tools and methodologies to improve code quality back in 2006-2007. These articles included Martin Fowlers seminal article on Continuous Integration (CI), and I ended up installing Cruise Control and linking it up to my Subversion repository on a Linux box. It was a pain to setup, but it was great watching Cruise Control retrieve my code from Subversion and build it. I also set up Trac and had full source browsing and task tracking for my home projects.
The tool I learnt the most from was FindBugs, a static code analysis tool. It analyses compiled Java classes looking for patterns of bad programming and potential problems. I ran it on my projects at home and was pretty surprised with the results. While the FindBugs report does give you some false positives, it did find some potential flaws in my small projects.
The only problem was that I never had much time for my personal projects, and the fun of watching a build compile without errors or running FindBugs only lasts a little while.
I helped my company start using Trac, and we setup our own continuous integration build system. We would run FindBugs on our pretty large project now and again and find critical bugs long before they got us into serious trouble. These tools saved us a lot of problems.
Fast forward to 2009, and I am at a new company that also has Trac, Subversion, and a Continuous Integration server (Hudson). I had a look at the Hudson server, but based on my past experience, I didn’t see what a Continuous Integration server would do that I wasn’t already doing myself. I was doing a full Maven package before committing and deploying, and I was alone on my project, so build breaking wasn’t much of an issue.
A few weeks ago everything changed. One of the other developers installed the Continous Integration Game Plugin for Hudson that puts up a leader board link on the main Hudson page. This plugin scores your commits based on how good your code is, how much test-coverage you have, how complex the code is, and many other parameters. One of the tools it uses is FindBugs, and old friend and an excellent tool.
This turned Hudson into a completely different beast, at least from my perspective. Suddenly I could compete with the other developers based on code quality merits, and at the same be improving my code! Sonar, an “open source code quality management platform”, was also integrated with Hudson, giving a detailed breakdown of the code by the same metrics as the CI Game.
Playing the CI game inspired me to start unit-testing. I had been on the fence for a while, and quite honestly been put off by all the evangelism behind Agile, Extreme Programming and Test Driven Development towards using Unit Testing as some kind of silver bullet. Having been to a TDD & Web Driver workshop session a few weeks ago I was looking for a reason to start using unit tests, and this was the perfect opportunity.
I started by setting up JUnit in Eclipse and moving some of the sanity tests I already had into unit tests. I ran them locally through maven, and committed them. A few minutes later Hudson had detected a code-change in Subversion and built and ran the tests, and increased my score on the leader board. In a couple of days I went from 0% test coverage to 30% test coverage. At the same time I was fixing problems found by FindBugs and other plugins, and saw the code quality metrics climb steadily. It is actually a great feeling!
From a management perspective Hudson and Sonar can be a bonus or a scary peek into a bad code base, depending on management and of course depending on the quality of the code. But the good thing is that you can easily see where there is potential for improvement, and when things do improve it will make both developers and management happy!
So, if you want to motivate developers to improve their code quality, and make them feel better about it at the same time, the Continuous Integration Game combined with Sonar can be a very good motivator. If you get management on board then you have an extra reason to spend time on code quality issues.
Go play the code quality game!
One thought on “The Code Quality game”