Introduction to Code Churn: Causes & Fixes | Pluralsight

When engineering leaders can clearly visualize progress, identify bottlenecks, and watch trends across multiple teams, they can notice when something’s off before a deadline is missed. They can experiment with meeting structure and timing, provide actionable feedback, and stay out of the details that should be handled at other levels. Then, they can measure the impact of those decisions.

Among the metrics that managers can use to understand a team’s progress is code churn. Churn is when a developer re-writes their own code within 30 days of it being committed. It’s typically a natural part of an engineer’s workflow as they explore, test, and refine their work—but unusually high levels of churn or unexpected fluctuations in the metric can be used as a signal that something’s off.

Watching trends in code churn can help managers notice when a deadline is at risk, when an engineer is stuck or struggling, or when there are issues concerning external stakeholders.

In this guide, we’ll unpack what code churn is, what it isn’t, and what to do when you notice an unexpected spike in the metric.

Code churn, or code that is rewritten or deleted shortly after being written, is a normal part of the development process. Engineers often test, rework, and explore various solutions to a problem —especially towards the beginning of a project when the problem doesn’t have a clear solution yet.

Churn levels will vary between teams, individuals, types of projects and where those projects are in the development lifecycle. Different individuals and teams will have different “normal” levels of churn depending on their workflows and the types of projects they’re working on (i.e., a new problem, familiar problem, quick fix, etc.). So for managers, it’s helpful to get a feel for what “normal” looks like in the context of their teams so they can identify when something is amiss.

It’s only when the level of code churn unexpectedly moves materially above or below the individual’s or team’s ‘normal’ that there is cause for concern. It’s especially important to be able to identify this when nearing a deadline as the project may be at risk.

Code Churn is a seemingly straightforward concept that’s also commonly misunderstood. One of the misconceptions we often come across is that teams should optimize for low levels of Code Churn, or that it’s a signal of an unhealthy workflow. Neither of these are true. Considering the metric is a particularly useful signal for engineering managers and it can be used to benefit the team as a whole, it may be helpful to unpack the term here.

Testing and rework are natural parts of the software development process, and you’ll notice varying levels of churn across individuals and teams. Some level of churn is to be expected, especially towards the beginning of projects or when the problems at hand are new and challenging.

It’s when Code Churn levels deviate significantly higher or lower than expected norms — particularly in the latter parts of a sprint or when nearing a deadline — that it can represent smoke that is an indicator of a potential fire.

In benchmarking the code contribution patterns of over 85,000 software engineers, GitPrime’s data science team found that code churn levels frequently run between 13-30% of all code committed (i.e., 70-87% Efficiency), while a typical team can expect to operate in the neighborhood of 25% code churn (75% Efficiency). A baseline level of churn is to be expected — unusually low levels of churn can indicate that an engineer is sacrificing speed for precision.

Because one team’s average level of code churn will be different from the next, becoming familiar with your team’s normal way of working may help you identify when someone is hung up or needs assistance, or otherwise to stay out of the way when they’re in a healthy flow.

Code Churn levels may vary over a project lifespan. A healthy project may have elevated Churn at the beginning of a project (sometimes called “exploratory” churn, as an engineer explores various solutions to a problem) and lower Churn towards the end, as a solution is identified and then refined.

When you notice an unexpected change in code churn, particularly when nearing a deadline, consider this as a signal to drill down further. Are you seeing a spike in churn levels late in the sprint, sprint over sprint, with the same team? Perhaps this team’s product owner is giving them unclear specs. Or, is an engineer in the habit of refining their work beyond what the business would consider as good enough? Consider coaching them on what ‘good enough’ is, or encourage them to review another developer’s work and highlight the behaviors that you’d like to see.

Unusually high code churn levels often point to contributing factors outside the normal development process. Addressing these factors will help remove friction from the development process, so the team can spend less time waiting on others or dealing with ambiguous specs and more time working on the core problems at hand.

Here are some of the common workflows and dynamics that can cause unusually high levels of code churn, and what to do when you identify them.

High levels of churn are normal when an engineer is pioneering a new feature as they explore and test multiple solutions to a problem. Prototyping is commonly seen at the top of a project — especially when that project is new or unfamiliar. (In fact, an unusually low Churn level at the top of a project could be an early indicator that a project is not progressing as planned.)

When a developer is steeped in exploratory projects, sacrifices are often made in code standards for a quicker proof of concept — only to be refined later once the right solution has been identified. Although this yields higher levels of code churn in the short term, this work pattern is productive as the engineer is proving out new ideas sooner. Redesigns, prototypes, and POC’s are all examples of where you would expect to see large chunks of code rewritten.

When you notice that an engineer is prototyping, don’t interrupt them. If they have an upcoming meeting on their calendar that isn’t absolutely necessary, consider pushing the meeting back — or let them know that you’re aware they’re heads-down on this project, and they don’t need to join unless they want to.

If, however, the time and effort spent prototyping far surpasses the engineer’s ‘normal’ or what you would expect for the task at hand, it may be worth checking in to get a better understanding of the engineer’s thought process. Perhaps the problem is more difficult than most they’ve experienced. They might admit that they don’t fully understand certain aspects of the problem — or, everything might be going well, but they’re going above-and-beyond with what they’re building.

Prototyping is a common and healthy pattern. The key is in understanding when it’s gone on for an unusually long amount of time or has otherwise surpassed what you would expect. Make sure that the level of time prototyping is in line with the appropriate level of business risk and the amount of value you expect from the feature.

Perfectionism occurs when an engineers’ standard of “good enough" is not aligned with the company’s standard. Consistently returning to the code to refine or rewrite it, while not adding much functionality or value to the existing code, can begin to have diminishing returns. Usually the engineer’s time would be better spent elsewhere.

Perfectionism is characterized by high levels of churn in the mid-late stages of the sprint or project after the work was already fit for production. The engineer is rewriting major sections of the work without adding substantial functionality or value to the original code. Often, an engineer will exhibit this pattern sprint over sprint. So when you think you’re seeing Perfectionism in the data, look at their historical trend to ensure that this isn’t just a one-off situation.

“Polishing” — where in the final stages before and after a release, an engineer is troubleshooting remaining problems (which are sometimes pointed out in the review process) and showing small frequent commits with elevated churn — can sometimes evolve into Perfectionism. The distinction: making improvements far beyond what’s needed from a business perspective without adding real substantial value.

What to do

• Make a distinction: was the work in line with team standards when it was checked in the first time? Is this additional work a result of feedback from the review process, or otherwise of substantial benefit to the original code? (If it is, that’s great! If people are consistently taking feedback from the review process and improving their code, that’s something to praise.)
• Be clear on what “done” is. Demonstrate the delta between the original requirements and what was delivered. If an engineer begins reworking or rewriting their code for an extended period of time, or far beyond what’s needed to get the project done, consider asking a more senior engineer to assess what “good enough” is in the context of this project.
• Huge volumes of churn leading up to a release could mean a release is at risk. Reworking code at excessive levels right before a deadline could be a sign that the release should be pushed back.

Unusually high levels of churn commonly arise as the result of unclear or indecisive stakeholders. While it may seem harmless, a wavering stakeholder can cause real damage to a team — both in morale and progress, and can lead to frustration in the team over time.

If the miscommunication between what was to be delivered and what actually was delivered resulted in missing functionality or components, you’ll likely notice a sharp uptick in New Work after the new requirements came in. If the miscommunication resulted in code that needs to be reworked, you’ll notice a sharp uptick in Code Churn. In either case, a sharp uptick in activity in the back third of a sprint (that wasn’t caused by code review) should be used as a signal that the deadline may be at risk.

When this pattern is seen sprint over sprint with the same team, it’s worth checking in with team members to see whether this work pattern is a result of late-arriving requests.

Generally speaking, the problem a team is solving should be getting smaller over time as solutions are identified, built, and refined. A sudden spike in activity, particularly in the later stages of a project, tends to be a signal that something new came in.

What to do

• If a stakeholder is frequently changing their mind after development has begun, show them the percentage of engineering effort being spent on rebuilding (ideally including time and dollar amounts to make clear the impact of this work behavior).
• Understand that changing requirements from a Product Owner can be a sign that they’re stretched thin — they have too much to work on, so things don’t get their full attention until it’s too late. It’s helpful, for that reason, to be empathetic and have a discussion with their manager. Bringing data to the discussion can eliminate skepticism around what’s happening and help cut straight to the discussion about how to resolve the situation moving forward.

With a particularly challenging problem, a higher percentage of exploring and backtracking is to be expected. The key is to get a feel for if the problem has gone on for too long.

Sometimes unusually high churn levels with can be a result of an engineer thinking they had correctly solved the problem — perhaps even sending it off for review — and then discovering that major sections of it need to be rewritten. Perhaps the spec left a lot of room for interpretation, or the engineer otherwise didn’t fully understand the problem or how to solve it.

What to do

• Develop a sense for when a challenge has gone on too long and be proactive.
• It is usually preferable to be coached by a fellow engineer or team lead instead of a manager. Ask a more senior engineer (who tends to help others or enjoys doing so) to pair program.
• Find time to meet that works for them and is non-interruptive to their flow. Determine if they have the resources they need, and which additional ones would be helpful for you to deliver.

When an engineer works from fuzzy requirements, they will rely on their best guess to interpret and fill in any gaps. Undoubtedly some of those assumptions will be wrong and lead to increased churn. If the specs are poorly written or incomplete, they may even be working on something that’s unbuildable.

What to do

• Review the requirements to determine if additional clarification is needed and if edge cases have been properly addressed.
• Meet with the product team and show them the cost of unclear requirements. If you use GitPrime, bring a chart from the project timeline to show them what engineering throughput looks like for a clean implementation versus a messy one.
• Provide an example of what good requirements look like. Let them know if they want things delivered faster, they can help speed up the process by providing clear specs.

When an engineer has high churn but low throughput for an extended period of time, this could be a sign of burnout or boredom. Sometimes this is a result of a work pattern called “Bit Twiddling”, where an engineer is unwaveringly focused on a single area of the codebase for a very long time, making only slight changes here and there. It’s like working on a jigsaw puzzle to the point where everything looks the same and you’re not making any progress anymore — and it often happens because the engineer doesn’t fully understand the problem or the context for making the change.

Look for high rates of churn in the same area of the code. The key is to couple repetition and refactoring with ambivalence or indifference in code review over an extended period. This is an indicator that the engineer is losing steam and motivation, or is at risk for doing so.

What to do

• Look for ways to reenergize the engineer with a new project. Find a ticket, even a small one, that will lead into new and interesting areas of the code — even if it comes at the expense of the team’s productivity in the short-term.

When we rely solely on data about our teams’ outputs (usage metrics, bug rates — the products and features that are out there being experienced by customers), we miss the opportunity of understanding how our teams are working, from idea to production, as they create these outputs.

GitPrime provides a suite of reports that look at the development process, from idea to production, so engineering leaders can identify bottlenecks, issues caused by external stakeholders, and engineers working hard on less-flashy items. They use GitPrime to understand dynamics, like unusually high levels of code churn late in a sprint, that may have otherwise gone unnoticed or caused delays.

The goal of measuring Code Churn and other health indicators like it is to supplement your intuition engine with concrete data.