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.

Successful teams keep track of their performance through a set of chosen indicators called software engineering metrics. With these metrics, engineering leaders can visualize progress, identify bottlenecks, watch for anomalous trends, and predict when something’s off before a deadline is missed.

One such important but often overlooked metric in software development is code churn. In this guide, we’ll unpack what code churn is, why high levels of churn can be detrimental to a project, and what to do when you notice an unexpected spike in churn.

What is code churn?

Code churn, also known as code rework, is when a developer deletes or rewrites their own code shortly after it has been composed. Code churn is a normal part of software development and watching trends in 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 upon when and why it is taking place

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.

How to detect unproductive code churn?

Code churn varies depending on many factors. For instance, when engineers work on a fairly new problem, churn would most likely be higher than the benchmark, whereas when developers work on a familiar problem or a relatively easier problem, churn could most likely be lower. Churn could also vary depending on the stage of a project in the development lifecycle. Hence, it is important for engineering managers and leaders to develop a sense of the patterns or benchmarks of churn level for different teams and individuals across the organization.

While code churn, by itself, is neither good nor bad, there is a cause for concern only when churn levels digress from team or individual benchmarks for the particular project that is being worked on. When such digression occurs, it is important to identify the factors contributing to unproductive code churn.

What can high code churn indicate?

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 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.

Conclusion

For far too long, engineering leaders have relied on limited signals and their own intuition to assess the performance of and adequately help their teams. The aim of tracking code churn and other metrics is to enable fact and data-driven decision-making. Data-driven feedback loops assist in identifying process improvement possibilities and tuning engineering routines in real-time.

Code churn is frequently ignored and underutilised by several software organizations. However, tracking and managing churn can lead to teams discovering severe issues not just inside their codebases but also in their developer education and in engineering routines. Measuring code churn will certainly help engineering leaders to manage and optimize their team’s performance and productivity.

💡 One of the primary reasons engineering teams have not been able to leverage these essential metrics is because measuring code churn has been complex and expensive. But now, Hatica’s engineering analytics platform makes it quick and simple to track this metric for your teams. Just connect your Github, Gitlab or any other code hosting platform you use and let Hatica 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.