Back To All

Code Churn

June 11th, 2018
Topics
Engineering Productivity
Share Article
Real-time information about the development process is key to predicting the output of a team. 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. Code Churn is when a developer re-writes their own code shortly after it has been checked in (typically within three weeks). 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.

What Code Churn Isn’t

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.

Code Churn Isn’t “bad”

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.

Code Churn Doesn’t Stay Consistent Across a Project’s Lifecycle

Code Churn levels may vary over a project’s 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.

Causes of Code Churn

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.

1. Prototyping

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.

2. Perfectionism

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

3. Issues Concerning External Stakeholders

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

4. Difficult Problem

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

5. Unclear Requirements

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

6. Nearing Burnout

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

Measuring Code Churn

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. Waydev 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 Waydev 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. If you what to track your git analytics with Waydev, you can sign up here for a 30 days trial and if you want to find out more about how Waydev can help you, schedule a demo.
Demo

Ready to improve your teams' performance?

Request a Free Trial

DORA Metrics Playbook

DORA Metrics Playbook

Download Now!