In today’s post, we answer a seemingly simple question: what is code churn?
Code churn is an important but somewhat overlooked metric in software development. This is an interesting metric in that its value is twofold. I’ll explain: a high code churn value can be both a symptom of unhealthy trends happening in a codebase and a cause of further quality problems. Thus, by measuring their code churn and keeping it at bay, software organizations profit twice.
We’ll open the post with a simple definition. Before moving into deeper waters, we’ll explain what code churn actually is so we can start on the same page. After that, we’ll cover the reasons why it’s a metric worth your attention—and there are many reasons for that. You’ll understand why you probably want to keep this metric at acceptable low levels. Finally, we’ll explain the steps you can take to keep this metric as low as possible.
Let’s get to it.
What Is Code Churn?
Code churn (also interchangeably known as rework) is a metric that indicates how often a given piece of code—e.g., a file, a class, a function—gets edited. As you’ll soon see, if a given piece of code receives changes too often, that’s usually a bad sign.
But how often is “too often”?
It’s not that valuable to have a metric—which is supposed to be an objective measurement of something—be based upon something subjective. So here goes an objective definition: code churn, or rework, is when some code gets rewritten up until three weeks from when it was first merged.
What Causes Code Churn?
Typically, rework, or code churn, happens because the engineer is struggling to write that given piece of code.
The reasons behind this struggle can be several. Lack of skill or knowledge is a common one. Poor communication between the team and client is another common reason. This results in the team not understanding the requirements of the project, causing the feature to be rewritten several times.
Why Is Code Churn a Problem?
First of all, it’s important we understand that code churn isn’t necessarily a problem. It’s virtually impossible your app will achieve zero code rewrites, no matter how skilled your developers are or how clearly the customer’s requirements are understood and communicated. So a low rate of rework is healthy and expected.
When rework surpasses 20%, that’s a sign you should worry about it. But why exactly? That’s what we’ll see next.
Code Churn Indicates Something Might Be Wrong With Your Process
As we mentioned in the intro, code churn might be an indicator that things aren’t right and a creator of future problems. Let’s discuss the first statement.
You’ve seen that code churn usually happens when developers struggle while writing code for a given feature. We’ve mentioned that such difficulty is often due to a lack of skills or incomplete understanding of the requirements. Unskilled developers and poor communication with clients are certainly serious problems for any software project. Acquiring an excess of technical debt might also cause rework. Your teams might be rushing the development process by commencing development before the domain is well understood, thus creating the need for rework.
Code churn might also be the result of less-than-stellar review and testing practices. If your organization has a review process in place but many defects still go unnoticed, that’s a sign the review process is in need of improvement. The same reasoning applies to your testing strategies.
There’s more to it than that, though.
Code Churn Might Be a Symptom of Problems in the Application
Code churn might also be a symptom of deeper problems with the design and architecture of the application. Important software design principles, such as the Open-Closed Principle (part of SOLID), dictate that a good class design is one that encourages new code to be written instead of changes being made to existing code. The Single-Responsibility Principle (the “S” in SOLID) says that each class should do only one thing. Changes made to an already-existing class might be a sign that the class is doing too much.
Complex code with poor readability might also lead to code churn. The developer could have misunderstood existing code and created new code that interacted with it in the wrong ways, leading to bugs. Such bugs then need to be fixed, which causes code to be rewritten.
Code Churn Can Create Future Quality Problems
Besides being an indicator of possible existing problems, code churn can also create some new problems of its own. Why is that?
Statistically speaking, there are more chances of introducing defects to a piece of code that gets edited a lot than one that nobody touches.
Code is not created equal. It can vary in regards to many factors, including how critical it is and, of course, how often it gets edited. So code churn can be a predictor of high-risk code. That is to say, code that’s more complex or critical and that has a high value of rework is at a higher risk of being damaged.
How to Keep Code Churn Under Control
You now know what code churn is. Also, you understand why it might represent a problem for your codebase. The next step is to learn how to reduce rework in your applications. As it turns out, you can do this by following a simple three-step process.
First, you track your code churn value. Then, you alert the relevant stakeholder if the values get too high so that measures can be taken to lower them. Finally, you attack the underlying conditions of rework. Let’s see each of those steps in more detail.
Step #1: Measuring
It’s impossible to improve what you don’t measure. So the first step in keeping code churn at bay is measuring it. By carefully tracking the metric, you can make sure you’re ready to hit back when it starts to get out of control.
At LinearB, we not only measure rework for you, but benchmark it against industry standards. Learn more about what’s considered a high or low rework rate in our Engineering Metrics Benchmarks study.
Step #2: Alerting
Tracking the metric is important, but it’s just the first step. The second step is actually spreading the word. You need to make sure the tool you’re using to measure the code churn value can integrate with the communication tool your organization uses—e.g., Slack—and send alerts to the relevant people. That way, they can take some action and prevent rework from creating bigger problems.
Step #3: Addressing the Root Cause
Monitoring and alerting are tactics that, even though they work, really amount to putting out fires. Wouldn’t it be nice to stop the fires from starting altogether?
That’s why our third and last step to address code churn is actually the most important one. We’re talking about handling the underlying causes of rework.
- The design and architecture of the applications should be evaluated and improved if needed.
- Developers should receive training so they don’t lack the skills to develop the features the application needs.
- The process of communicating and obtaining requirements from the customer should be reviewed. This is to ensure the developers get the correct and updated requirements so they can write the apps correctly, avoiding rework.
How to Improve Your Code Churn
Software developers, teams, and organizations are always looking for tools they can use to not only evaluate but improve the current quality of their apps. The thing is that software engineering often feels more like an art than a science. There’s a lot of subjectivity and intuition going on. However, there’s one sure way to get objective assessments on many facets of the software development process. We’re talking about metrics.
In this post, we’ve talked about code churn, an important metric that all software organizations should at least be aware of. Unfortunately, this metric is easily overlooked and rarely tracked. Which is a shame. As you’ve seen in this post, measuring and controlling this metric could lead organizations to uncover serious problems not only within their codebases but also in the education of their developers and in their communication processes with their clients.
Finding out about a problem is the first step in fixing it. Code churn and other software metrics can certainly help with that, as long as you’re willing to adopt and track them. The next step is to actually start tracking the metric, and you need a tool for that. We invite you to check out LinearB, a software development analytics tool that not only tracks code churn—via its “rework” metric—but also has a clear improvement strategy for improving code churn.
