Code Churn

What is Code Churn and How to Reduce it

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

Several tools can measure code churn for you, Azure DevOps Server has an in-built mechanism for working it out, and SaaS offerings exist, such as GitPrime.

Some of the tools you’re already using will have similar metrics.

a graph showing code churn
Github’s code frequency graph

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.

Indecisive developers

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.

Share This Post