We’ve been tracking a handful of metrics that we wanted to track about our code base for a while and it’s built up some pretty graphs that tend to indicate that our adoption of XP has improved the quality of our code. Obviously they’re just a guide, the real test of quality will happen when we ship the next release out to clients, but they’re useful none the less. The general trend shows a gradual improvement over time – fewer known bugs, lower complexity, more tests etc.

Towards the end of last week though, all of a sudden the graphs showed a sudden turn for the worse. Complexity suddenly shot up, number of tests dropped and the line count went up. It looked like someone had gone on a wild hacking spree overnight.

Fortunately, it turns out that the answer was a lot less scary than that – we’d rolled back a feature. There’s a lot to be learnt from why we wound up rolling it back, but what struck me by surprise was how much of an improvement we saw in our code by adding that feature. We’d managed to refactor our old code and achieve the same functionality with about 500 fewer lines, improve our code coverage a lot and generally improve the code quality in that area. The thing is, because we were continually integrating and building up the overall feature gradually, we didn’t originally see how big an improvement it was making to our code. All we saw was a gradual improvement over time, mixed in with all the other gradual improvements over time. By rolling it back, suddenly we saw how dramatically we’d improved our legacy code while still improving the product.

It gives a great deal of hope that we’ll bring our legacy code up to scratch a lot faster than I had originally expected. Our refactoring, TDD and general higher standards are paying off and I’m looking forward to being able to show our clients that.