There are many different metrics that help drive team performance and creating quality products for the end user. Some metrics are easy to understand like number of bugs and features, others often take a special approach where it’s not enough to just look at the numbers, but instead understand why that number exists.
Code Churn
What: The rate at which your code changes and evolves during the development process
How: Code Churn can be measured at its most basic level as the number of lines of code that have been added, modified and deleted to your source code repository over time.
Why: This metric is often considered to be the canary in the coal mine in regards to the quality of the product that is being released.
Code churn is a good indicator of escaped bugs that might make it into production. If you are approaching the end of an iteration and you are seeing an increase in your code churn, that’s a sign that your code is getting more volatile. Instead, you should be seeing less code churn and (hopefully) more stability the closer you get to your delivery date.
Additionally, you may see regular spikes in your code churn metrics that would indicate mini-waterfalls of work, where instead of team members committing early and often to your code repository they are holding onto features on their dev machine and checking in large sets of features at a time. This can be a problem when you need to run integration and merge activities since smaller changes are always easier to integrate than larger “big-bang” integrations.
There are other reasons for Code Churn that may not be as obvious. A developer may be going back and rewriting the same lines of code over and over again. This could be due to the developer not having clearly understood them at the time or a stake holder constantly changing the requirements because they cannot make up their mind about a particular feature. If this is the case, it becomes important for the team lead to step in and get it cleared up quick.
Lastly, a high rate of Code Churn may not indicate that there actually is a problem. You may notice a high rate because a developer is working on a particularly difficult problem, they are prototyping a solution, or they are polishing and removing technical debt from the codebase.
The important thing here is to recognize why and when you are seeing a high Code Churn rate and make sure that there is time to stabilize a release. While you may see small frequent commits in the final stages of a release, large changes to the code could mean you’re about to drop an unstable release.
