Have you ever spent days or weeks working on code and feel like you’re writing and writing lines of code but by the end of it very little has changed? Your project might have high code churn.
What is code churn?
Code churn is a natural part of the development cycle.
High code churn can mean lots of things have changed and need testing or reviewing. Ideally you see lower code churn the closer you get to a release date.
Code churn can mean different things to different people, the two most common definitions are:
- Code churn is when a developer changes code during a specified period
- Code churn is how often a file has evolved over a specified period
They sound similar but tell you two slightly different things.
When thinking about changes developers make to code, you could give the churn a percentage.
For example, in the last two weeks, you added 100 lines of code. But you also removed or changed 20 of those lines, you have code churn of 20%. 20% of the code written provided no benefit to users.
Alternately, when you’re looking at files, it is often better to look at the number of times a file has changed.
In the last two weeks,
home.html was changed 50 times, and
website_controller.rb was changed 20 times. These stats show you:
- parts of the system that may need more tests because they are often changed
- parts of the system that are getting all of the development resources
How to measure code churn
Some of the tools you’re already using will have similar metrics.
GitHub has a code frequency graph, which shows added and removed code per week.
If you are using
git you can use this git-churn script to see how many times you have changed a file.
Each tool will have its own way of measuring code churn, but all the tools will be checking that for a given period, how many lines of code have changed (been modified, added, or removed) in the system.
What to do about code churn
Several factors could lead to high code churn in your project, some of the more common are:
Continually changing requirements
If the work is underspecified, or the requirements change midway through the work, then you would expect higher code churn. To fix this, you need to make sure that projects are properly planned out and requirements adequately specified before development work starts on them.
Prototyping / Spiking
Some development work is exploratory by design. The code is intended only to learn something new and then be thrown away, this is called a code spike. If spiked code is impacting how you report on code churn, the fix is to make sure these code spikes happen in places you don’t report — code branches not on the main branch, for example.
The developers on your team might be torn between several ways of doing things, waffling back and forth on what the best way is. When this happens, it’s usually best to take a step back and spike out a solution before committing it to the main branch.