Churn Baby, Churn
TL;DR
- Churn is the amount of code that gets rewritten out of the total amount of written code
- Code churn can be good when developers prototype quickly or improve their code
- High code churn, however, can reflect code quality or code testing issues
- Understanding typical churn rates for different types of development and different levels of complexity can help developers be more productive and write quality code
Developers write code. Then rewrite code. Then rewrite some more code.
And so the world turns, like John Travolta in Saturday Night Fever.
It's like an email you write after an emotional event.
First you write the email. Then you read it again and decide to delete a few choice words. Then you put it aside. When you come back, you delete some more. Finally, you send a well reviewed, higher quality version.
It's natural to have code churn. It can be healthy to have code churn.
But what can we learn from tracking code churn? How can analyzing code churn make us better developers?
Code Churn Defined
Churn is the amount of code that gets rewritten out of the total amount of written code (gross code).
Gross code can be broken down into three categories: characters added, characters deleted, and characters pasted (e.g. integrated from open source). Gross code can be calculated by keystrokes and characters, the smallest atomic unit of data, or it can be calculated using lines of code, which can be influenced by coding style, text editor, etc.
What's left over is your net code—the amount of code that is your total contribution to a production release.
Churn can be calculated as the ratio of gross code to net code.
Sources of Code Churn
So what are the causes of churn?
There are certainly bad causes of code churn. There's a change in the market that makes a product obsolete. Product managers often get requirements wrong. We find a critical flaw in architecture or design. Or we find bugs in our code that need to be fixed.
And there are good causes of code churn. Great developers often prototype quickly in order to understand the full scope of what they are building, in order to learn. In fact, a bias for action is a key component adopting Code First as a principle.
In a world of open source and widely available sample code, developers often integrate and paste bodies of code and then whittle it down during integration—another example of good churn.
In addition, when we improve code—eliminating redundancies, improving performance, increasing readability—we create code churn.
And the cost of code churn changes over time. When it comes to fixing defects or bugs, the cost escalates dramatically as you progress along the software development lifecycle. The cost to fix a bug in production can be 100 times more expensive than to fix it in design.
The earliest and least costly code churn we can analyze is pre-commit churn, churn that occurs in text editors and IDEs before changes are committed to source code repositories.
Learning From Churning
Looking at the data for code churn can reveal a great deal about a program or product.
High rates of churn during the later stages of the software development lifecycle can indicate quality and productivity issues.
In addition, if you visualize code churn across all the active files in a code base, you can get a sense of where your development efforts are being spent. You can even see at a glance if you have a successful microservices architecture.
For individual developers, understanding your personal churn ratio and how it compares to developers like you can give you a sense if there's room for improvement.
For instance, a 10:1 ratio can be typical for certain types of development or developers, but 10:1 churn rates shortly after a product release would clearly be too much.
Go Slow to Go Faster
Understanding typical churn rates for different types of development and different levels of complexity can help developers be more mindful of code quality, code reviews, and unit testing.
For instance, development teams that see a high number of bugs at late stages like integration testing or performance testing can benefit from higher quality testing and more bug fixing earlier in the development lifecycle, when it can be faster and cheaper to fix bugs.
Some of the best ways to combat code churn and improve developer productivity include better, more consistent unit testing and a disciplined code review process.
