Among numerous metrics on code evaluation (like CRAP index) in product lifecycle, code churn seems to be the one to look for while dealing with post-release and legacy code elimination.
Code churn helps you to evaluate file changes across builds.
Code churn is a good predictor of post-release defects. Thus, it’s a warning sign if you approach a deadline while your code churn increases. That’s a sign that the code gets more and more volatile the closer you get to your deadline. You want the opposite. You want to stabilise more and more code the closer you get to delivery. > > Codescene
Code Churn features
One of the features of code churn - is bottleneck finding across developers and tasks. Low commit rates per author can signal the management, that there’s some sort of problem going on:
- Task ambiguity that prevents to complete the task, indecisive stakeholders * Technical issues within the platform, preventing on completing the task * Legacy code that remains in the product, and possible technical debt increase * Under-engagement *
Ben Thomson in his post about code churn, provides few graphs, illuminating code impact on productive/churn code across release cycle. As an example, I’ve used CodeScene service, to test code churn on one of the plugins I’ve worked a lot back in the days (hopefully will have time to get back to it soon) - cakephp-calendar.
Calendar Sample
cakephp-calendar code churn graph
As we can see, March-April was a major rewrite of the plugin, that followed next spike occurring in July. March re-write made the code more fragile. If we dig deeper, we can see that an overall complexity of March-April release was drastically decrease. Here’s one of the examples:
complexity graph of CalendarsTable.php
It’s still quite high, but it’s nothing comparing to what it was. Still, the code was in semi-prototype mode.
Apart of CodeScene service, there’s a specific churn-code composer package for PHP-based projects, that might be more useful for developers.