Not all code is created equal. To illustrate, let’s say that Katie, Jason, and Sam are engineers on your team. If you review the volume of raw code they checked in last month, it might look something like this:

To the untrained eye, it might look like Jason carried the team by writing the most code. But a savvy engineering manager knows it’s not that simple. Raw lines of code—or any other proxy for effort—is an incomplete way to think about software engineering. Any functional picture of engineering work needs to dig a bit deeper.

Seeing Code Churn

Code churn is when an engineer rewrites their own code in a short period of time. Think of it as writing a postcard and then tearing it up and writing it again, and then again. Yes, you technically wrote three postcards, but in the end, only one was shipped so we’re really talking about one postcard worth of ‘accomplishment’ from all that effort. The same is true with code. Let’s take a look at that example again, taking churn into account:

Here we see a different picture. While Jason definitely wrote a lot of code, much of that was tossed shortly thereafter, and thinking about his total net change to the codebase yields pretty different picture. That is code churn. The amount of productive code Jason delivered is significantly less than it might seem from a naive view of LoC written. Once that’s factored in, Katie actually made the biggest impact. Further, we might say that Sam was the most ‘efficient’ since he had the lowest ratio of churned code to code that actually stuck around.

Let’s look at a specific example

Jason checked in the following Javascript code on Monday:

1 //Populate the welcome text
2 $("#welcome").text("Hello Customer");

On Tuesday, he decided to make a tweak and checked in this change:

1 //Populate the welcome text
2 var name = "Hello Customer";
3 $("#welcome").text

Notice that the last line changed. So Jason churned one line of code. Or to put it another way, he gets no credit for the line of code he wrote yesterday. On Wednesday he decided to tweak it again and checked in the following code:

1 //Populate the welcome text
2 var is_new = false;
3 var name = (is_new ? "Hello New Customer" : "Hello Customer")
4 $("#welcome").text(name);

Now he’s changed the last two lines of code. Again, Jason gets no credit for yesterday’s change and he loses credit for the original line of code he checked in on Monday. In effect, Jason has churned 100% of his code this week. Simply put, Jason’s contribution on Monday and Tuesday was… nothing. He may be working hard but he’s not creating value for those efforts.

Keeping an eye on Churn

In our simple example, the net result was that Jason took three days to get this feature right. Now in all fairness, this may or may not be his fault. It could be the product manager wasn’t clear. It could be the spec changed. It could be he got the requirements wrong. In any case, as Jason’s manager, you need to look a little deeper as to why he keeps rewriting the same lines of code over and over again.

If you’re on the lookout for spikes in churn, you can diagnose problems early and keep your team from getting discouraged (Check out 6 causes of code churn and what to do about them). Mature software teams know that business value delivered is the true sign of their effectiveness.

Tracking code churn is a way to think about the percentage of code that sticks around to deliver business value. GitPrime can help you see your team’s code churn as it happens. Head over here to request a demo.