We’re really at a point in the industry where all developers should be aware of the importance of continuous refactoring. It’s easy to look at deteriorating code bases and get the sense that if only we’d done large refactorings along the way things would be better. But, code goes bad slowly and it happens through a predictable process. We add code to existing methods, making them longer, and we add methods to existing classes making them bigger. In the former case, the effect is particularly pernicious. As methods get longer they lose their focus - responsibilities tangle together and we end up with nightmarish sprawls of code. When the intent of the code becomes that muddied, it’s hard to see the way forward. It’s easy to see when things have gone bad but how do we know whether they are getting better?

I’ve been doing a lot of work in repository analysis recently, and one of the things I’ve found most useful is building a database of the histories of all methods in a repository. I can go back and look at stats for each method in a repository at every commit. With a little bit of scripting, I can arrive at a profile like this:

[135, 89, 14, 2, 1, 1, 1, 1, 1]

This array tells me that for a particular repository, there are 135 methods that increased in size the last time they were changed, and there are 89 methods that increased in size the last two times they were changed. The last element of the array tells us that a single method has increased in size the last nine times that it was changed. Thankfully, no methods have grown the last ten times they were changed.

The idea behind this measure is that there is a culture around any code base. The people working on it should know when methods have been the victim of drive-by code addition. As they go back and modify those methods they should take the time to separate out responsibilities - extract new methods. If they don’t, it shows up in this measure. I don’t like managing by numbers, but I think that having this simple array visible in a team and seeing it change over time could be beneficial.

Here’s a profile for another project:

[71, 17, 1]

Which project do you think is healthier?