What is Code Churn?

As an engineering leader, one of your top priorities is improving the effectiveness and productivity of the developers on your team. The first step to managing and improving your engineering team is adopting a metric-driven approach to identifying the problem areas that threaten your team’s performance.

Importance of metric-driven approach

• Visualize progress

• Identify bottlenecks

• Watch for anomalous trends

• To take action before a deadline is missed.

What is code churn? 

Code churn, also known as code rework, is when a developer deletes or rewrites their code shortly after it has been composed. 

Code churn is a normal part of software development and identifying code churn can help managers notice when a deadline is at risk, when an engineer is stuck or struggling, problematic code areas, or when issues concerning external stakeholders come up.

It is common for newly composed code to go through multiple changes. The volume and frequency of code changes in a given period of time can vary due to several factors and code churn can be good or bad depending upon when and why it is taking place. 

For example, engineers frequently test, rewrite, and examine several solutions to an issue particularly at the beginning of a new project or task when they are experimenting with solutions to the task at hand. In this case, code churn is good, because it is a result of creative problem-solving. 

Code churn can be good or bad depending on when and why it occurs. 

Code churn metric breakdown

Refactor

Code that is modified after 21 days of committing is called refactored code. Refactored code is usually an acceptable change that is needed for maintenance hence, is distinct from code churn so as not to raise any red flags.

New Work

Code that is newly added and that is not replacing or rewriting existing code.

Help others

Code that is replaced by engineers other than the author of the original code within 21 days of authoring. This helps you measure to what extent developers are helping their teammates to improve code quality and delivery.

Watching trends across this spectrum of metrics during a development lifecycle creates a better ground for effectively debugging the root cause and gaining potential insights such as: 

- Which team members are spending more time helping others, than perhaps working on their own work?

- The percentage of time engineers spend on new features (new work) vs. application maintenance (refactoring)

Anomaly alerts when any or all of these indicators trend out of the anticipated range can equip managers to combat challenges, preempt risks to delivery, and gain visibility into critical processes that might require an improvement.

What is the code churn rate?

Code churn rate is the number of times changes are made to the code during the development cycle. Code churn is a natural part of the coding process and can fluctuate based on various factors. Code churn rates can be segregated into good and bad and be normalized across developers, teams, modules, and projects as well.

Why are Code Churn Rates crucial for developers?

Code churn rate metrics are crucial to understanding the entire development process and the people involved - both the developer and the client. 

It can indicate internal and external hurdles such as constant change by the teams to achieve perfection or changes made to accommodate unclear requirements. Measuring the code churn rate helps managers navigate through the entire development process and meet the deadlines without any hold-ups. 

Reasons for code churn - 

• Code churn rates can help identify the nature of the feature under development. For instance, a new feature may demand multiple iterations to become fit for release, resulting in a spike in the code churn rate.

• Can be an early indicator of scope creep as the higher rates can sometimes be the result of new features or requirements that were not initially agreed upon.

• A higher code churn rate after feedback or a stand-up discussion translates to the feedback being implemented to the initial code base. 

• Code churn rates also signal a red flag in the clarity of the deliverables, as unclear objectives may require the developer to work on the same task multiple times. 

• Code churn rates can also indicate blockers in the development process and help the developer to get extra pairs of eyes and hands.

• It also provides insights into the workload distribution and helps optimize resource allocation by identifying the areas of the code which are often changed and require more testing.

• Tracking code churn rates help understand if the development process needs more testing or a push in the deadline and saves the team from last-minute surprises.

• The churn rate should reduce or stabilize towards the deadline. Else, the code can be very volatile, or bug-prone after production. 

The iterative code churns cycles can be interpreted in two ways - the evolution of the developer working on the code or the evolution of the file during the development process. 

How to calculate the code churn rate? 

As mentioned earlier, code churn occurs when the developer deletes, updates, modifies, or rewrites sections or the entire code within 21 days of writing it. This code churns can be an indicator of something good, like code refactoring, or bad, like a non-linear development approach. However, the verdict can only be passed after the code churn rate calculation, which can be performed in two ways. 

- One way for code churn rate calculation is to consider it as an aggregate of the number of lines of code added, deleted, and modified. For instance, if you have written over 1000 lines and deleted about 350 for whatever reason, the code churn rate is 35%. 

- The other is file-based, where n number of updates/modifications happen to a file over a particular time, and the code churn rate calculation returns a value of n.

Using this calculation managers should be able to track the pattern in code churn rates throughout the development cycle and identify at which stage of the process the number is higher. Ideally, they should also be able to classify higher code churns as good or bad by analyzing and understanding the cause and impact of it. Hence, managers should be equipped to differentiate between a normal code churn rate and an alarming one to steep in and take the necessary next steps.

Code Churn Rate - The Good, The Bad, or Ugly

Interpreting the nature of code churn is subject to various internal and external factors. If leveraged properly, code churn rate is a metric that is beneficial to both the managers and the developers as it enables them to assess and monitor the evolution of the code. It provides a real-time view into the development process and helps draws inferences on the progress, identify bottlenecks and take countermeasures earlier.

However, code change rates are not consistent. It varies across individuals, teams, projects, and even stakeholders. However, tracking code churn rates consistently can help managers classify and even arrive at normalized values across all departments. So, what makes a code churn rate good, and what gives it the tag of bad?

The Good Side of High Code Churn Rates

A higher code churn rate can be alarming at first glance. But, it does not always signal a problem. Understanding the root behind the staggering number can sometimes help decode the proactive reasons listed below.

Experimentation

New modules sometimes demand a novel approach from the developer. During a time like this, the developer needs to work on a prototype code that can be different from earlier, resulting in higher code churn rates. This anomaly in the code churn is harmless or maybe productive. But, even a good reason like this can be problematic if it takes too much time right at the start of the development cycle and stretches the deadline beyond the allocated window. Hence managers should be vigilant while tracking code churn rates at different stages of the development cycle. 

Optimization

Skilled developers can draw up the logic behind the feature or the module in a relatively shorter time. Sometimes they complete the code and even achieve the desired output. So they formulate a way to make the run-time shorter by coming up with improvements and changes. This could increase the rate of code churn, but this optimization-oriented approach signals proactivity and does not affect the development process. This again can backfire if the developer spends too much time optimizing a single feature jeopardizing the rest of the allocated module or features.

Collaboration

Developers tend to help their colleagues whenever they feel stuck. During this collaboration, the new developer who has come onboard could suggest big and small changes that could result in multiple revisions to the existing code. The new changes can result in higher code change numbers that don’t signal an alarm. Even this new code churn rate should be monitored and ensured that only the necessary changes are made rather than committing to changing the entire blocks of code. This can result in resource leakage.

The Bad Side Of High Code Churn Rates  

Higher code churn that spells disaster can be nullified if managers track the churn trend from the beginning of the project. Organizations can further classify the reason for a higher code churn rate into internal and external.

Internal 

• Overachievement: Organizations tend to focus on building the MVP version faster to get an idea of staying ahead. Sometimes, the fast-paced method can cause an overlook of the core functionalities or requirements which can result in higher churn rates in the future.

• Perfectionism: Developers tend to rework the same blocks, only to make them perfect. This excessive attention to detail with no returns on the functionality can negatively impact the deadlines. 

• Employee Burnout: Having high churn rates in the same areas of the codebase for an extended period can mean the developer is stuck. Not paying heed to the situation can cause the developer to develop boredom, a sense of not being competent, and ultimately, burnout. Managers can identify this by tracking code churn at regular intervals and taking corrective measures. 
  Here's how organizations can weed out software engineer burnout. 

External

• Tough feature: Sometimes, the clients can demand features or modules that are difficult to implement in a shorter period. Unprecedented requirements cause a spike in the code churn rates.

• Added changes after release: External stakeholders may slip in new change requirements not mentioned in the Product Requirements Document during stand-ups or reviews. This can cause unnecessary reworks and code churns.

• Unclear requirements: Miscommunication among the team and the clients can cause chaos sprint after sprint, causing a chink in the armor of an optimal churn rate. Requirements should be made clear at the beginning of the development cycle and verified after every update. 

Factors Contributing To Unproductive Code Churn

Complicated Tasks

A higher level of churn is to be expected when an engineer is exploring and backtracking with a particularly challenging problem at hand. It is when the exploration has gone on for too long that it is a call for concern. 

An unusual high churn level might indicate that an engineer did not completely understand the assignment, or neglected to fully comprehend the issue, or didn’t have the expertise to address the assignment. In many cases, engineers feel that they have successfully handled the issue, perhaps even sending it off for code review, and then finding that significant areas of it needed to be changed. 

Unclear requirements or changing requests from external stakeholders

Factors outside the normal development process such as a poor PRD (product requirements document) or unclear or indecisive stakeholders can also lead to high code churn. A sudden increase in churn or a sudden spike in new work, especially in the final phases of a project, is usually an indication that a miscommunication between the stakeholders or new requirements led to the final code undergoing changes. When this pattern is seen sprint over sprint with the same team it can damage both morale and progress and can lead to frustration in the team over time.

An indicator of future quality problems

Measuring code churn equips managers with foresight to predict and preempt potential future problems. The most problematic code is the one that is complicated to grasp and altered frequently. A high level of churn exposes potential code hotspots, and if these frequent changes are performed on complicated and critical code, the code tends to be more error prone. Hence, code churn can be a predictor of high-risk code.
These code hotspots, if not recognized early during refactoring efforts, can result in developers accumulating huge amounts of technical debt. This debt grows as more opportunities for code refactoring are missed and, as a result, new development becomes difficult, especially when features are built upon legacy code.

Deadline is at risk

A higher percentage of reworking and code deletion resulting from experimentation is commonly seen at the beginning of a project — especially when a project is new or unfamiliar. A similar trend, sometimes called “exploratory churn”, is expected in the case of particularly challenging problems. Although code churn resulting from creative problem solving is a positive outcome, it becomes a risk to meeting project deadlines when such experimental coding continues for a long period of time, risking the timeline of the development cycle.

Similarly, churn should stabilize as a project nears the release timeline. An early indication that the delivery ought to be pushed back is when you start seeing a high volume of churn leading up to a release. 

How to prevent high code churn?

When faced with high unproductive code churn, here are some potential actions managers can implement.

Better Planning

Managers should assign developers to projects and tasks based on programming language and code complexity. Using data-driven and factual insights for planning team and task allocation can improve instances of unproductive code churn.

High rates of churn in particular code hotspots can likely be an instance where an engineer, for a prolonged period of time, remains unwaveringly focused on a particular region of the codebase, making just little tweaks here and there. This could be an early sign of a burnout. Data-driven planning provides managers the opportunity to assign a new set of tasks or projects to such engineers which would help them navigate to new areas of the codebase. 

Training 

Leaders should ensure that their developers receive the right training and learning so that they have the right skillset to create the features that the application requires. A widely used and successful training method pairs programming sessions with senior engineers who naturally tend to help others. Such pair-learning exercises also help in boosting the morale and effectiveness of the team.

Clear Requirements 

If the specs are poorly defined or inadequate, the developer is forced to work with hazy requirements, forcing them to rely on their best reasonable guess to decode and fill in any gaps. To avoid this, managers have to ensure that their developers get the most up-to-date requirements so that they can create appropriate solutions and avoid rework.

How to ensure the good churn rate? 

Developers should create a mockup of the development flow with the output and get affirmation of the same from the client. This can ensure everyone is on the same page about the deliverable and the deadlines, thus eliminating code churn rates due to external factors. Having a plan that depicts the goal, deliverables and deadlines can loosen the noose of higher code churn rates.

Cracking the Churn Code

By reading the blog now we know that code churn and code churn rate are crucial metrics to boost developers productivity that provide insights into the stability and maintainability of software development projects. Identify areas of high activity and potential problem areas that require attention. High churn rates may indicate excessive rework, complexity, or inefficiencies in the development process, whereas low churn rates could suggest stagnation or lack of progress.

How can Hatica help track code churn?

One of the primary reasons engineering teams have not been able to leverage essential code churn metrics is that measuring code churn has been complex and expensive. 

With Hatica’s engineering analytics platform, engineering managers and leaders can easily track this metric for their teams. Hatica seamlessly connects with Github, Gitlab, or any other code hosting platform to deliver code churn dashboards in minutes. 

Request a demo here to know more about Hatica and how it equips engineering leaders and teams with data-driven insights into their engineering development process.