It’s often hard to measure whether or not the quality of your codebase is improving. It’s also very easy to become overwhelmed by software quality metrics. With so many, you stop paying any attention.

One of the metrics my current team has been paying a lot of attention to is a “duplicate count”. It’s a measure of how many lines of duplicated code you have in your codebase, both in the test code and in the production code. Team City, which we are using as our Continuous Integration server, has a built in duplicate count, so that every time you check in you can see whether it has gone up or down. (The way that it counts is sometimes a bit strange… but I won’t focus on that!) You can make sure that the build fails if it goes over a certain number.

We were trying to focus on “improving the quality of our test code”, especially our high counts of duplicates within our test code. As this one was easy to measure, we thought we’d focus our efforts on a single metric and consciously reduce the number with each check-in.

Feeling particularly arty that day, I decided to create a physical counter that we could use to measure how we were doing. I created one counter that I put in front of the build monitor. Leaving the numbers to be coloured in as people got to them. This would then be flipped over as people reduced the numbers.

I also created a summary of the numbers to put on the story wall, so that at standup we could always check on progress. Noting what the number was at the start of the week and then what the number of duplicates was for that particular day.

It worked amazingly well. Suddenly this group of grown men were enthusiastically running over to the build monitor to change the counter as they reduced the duplicates. Cheers would go up when a pair checked in code that reduced the number. Turns out “gamification” is a real motivator. Before I knew it, people were getting shout-outs at standup for being particularly good duplicate reducers that week.

Having the additional counter on the main story wall meant that people outside the developers were aware that we were paying attention to the quality of our code and actively trying to improve it. It has now become part of our daily standup routine to talk about it.

The counter worked so well, that we then introduced one for the number of warnings in the code base. Pick a quality metric and try it!