New metric: festering code base vs. budding code base

Michael Feathers wrote recently about "Festering Code Bases and Budding Code Bases" http://michaelfeathers.typepad.com/michael_feathers_blog/2010/06/festering-code-bases-and-budding-code-bases.html where he describes them as:

Some teams produce what I call a festering code base. In a festering code base, the team changes the code primarily by adding code to existing methods and adding methods to existing classes. The results are predictable. Classes and methods grow malignantly, eventually becoming thousands of lines long.

Better teams produce budding code bases. Developers create new classes and methods and delegate work outward. Periodically, they collapse structure back into a simpler form, but the dominant trend is to grow the code by creating new structure.

These distinctions are qualitative, but they are measurable. You can look back at the the change history of a code base and get a sense of how changes occur. What is the ratio of new class and new method addition to change?

Budding code bases generally consist of classes that adhere to the Open/Closed Principle. The code grows outward. Festering, on the other hand, is stagnation. New code grows in the same space as old code, suffocating it.

Would it be possible to automatically measure, based on version history, whether the code base is festering or budding? If implemented well, I think that such a metric would be a good addition to Sonar's metrics.

Then it might be possible to see that into which direction the code is heading, even if the code base would not yet be too bad. Most metrics measure that in what shape the code base is right now, but a festering-budding metric would measure where the code base will be heading in the future.