Five Code Churn Tips for Engineering Managers



Code churn and its impact on productivity is a frequent concern of many software engineering managers. We recently noted that the best things in life start with a C – like Chocolate Chip Cookie Dough (CCCD) ice cream. Everyone may not see it this way, but code churn is to software development like CCCD is to Ben & Jerry’s. We’ll even prove it (sort of) and provide you several tips to help you manage your team’s code churn rates.

What is code churn and how do you calculate it?

Code churn is the amount of change that takes place in a volume of code in a relatively short period of time. If you write a piece of code with 100 lines but then change 25 lines within the next 2 weeks, you have a churn rate of 25%. It happens when a developer rewrites, modifies, or deletes code they’ve written recently. Code churn is automatically tracked by version control systems like git. It can be easily extracted from a system’s change history.

Code churn is a concern for software engineering managers for a few reasons. First off, code churn is helpful in predicting defect density. Secondly, less time modifying (churning) old code means more time producing new code. Finally, excessive code churn can indicate a developer is having difficulties.

Is code churn good or bad, and what’s this about ice cream?

Code churn is a normal and natural part of the coding process. Unto itself, code churn is not good or bad except in relation to when and why it happens. Generally speaking, expect code churn to be high in the early stages of a project. It should decrease as the project gets closer to release.

For an analogy, every software project has some code churn like even the best ice cream has some overrun. Ice cream comes in different qualities – defined by how much “overrun” is added to the mix. Overrun is actually air. It decreases value and quality. Bargain-brand ice cream has 100% overrun. Ben & Jerry’s ice cream has less than 50% overrun and 50% more butterfat. It has better ingredients to give it a richer, denser, creamier taste sensation.

Code churn, like overrun, is work that provides no added value, at the expense of work that does add value. And besides, 3 of the top 4 Ben & Jerry’s flavors in 2018 start with a C – like CCCD. The analogy may not be perfect, but it’s good enough. Code churn is your best indicator of code quality.

Code churn in context

Writing code is not entirely different from writing an article like this one. It used to be that writers would start with a first (rough) draft – and refine it with extra drafts. When it was as good as they could make, they’d submit it for review or publishing. It follows that it is natural and normal for developers to refine their code.

The key difference is that code churn involves code that presumably has already been tested and committed. Uncontrolled changes can conflict with other code, resulting in defects and bugs. Again, high code churn often correlates to high defect density.

How software engineering managers can control code churn

Software engineer managers have more control over code churn than they realize. With that comes the responsibility to track, manage, and improve code churn rates at all levels. Don’t get me wrong, individual developers must also be mindful of their own code churn rate. But, software engineering managers have a vested interest in code quality and the continued development of all members of their team. There are several ways you can manage your team’s code churn.

Tip 1. Thorough project requirements help reduce code churn

As we detailed in Simplifying Software Project Management Challenges, most problems originate from not taking the time to fully define a project’s requirements. The better defined the project’s requirements are upfront the less likely there’ll be changes later. It necessitates discussing the project with all stakeholders. It may also involve you or your sales team educating your customer. They may not know their software options and possibilities. A good example is the different data they can collect for B2B purposes.

That might be a big ask, but…

  • The better you define the project requirements, the less code churn there will be owing to mid-stream changes.
  • Educating customers about their possibilities is an opportunity to upsell the project. It’s also a chance to explain how changes increase their costs and slow delivery.
  • Better educated customers are more likely to be more successful, appreciative, and likely to contract with you longer.

That’s quite a cascade effect. If your project requirements change midstream, expect code churn rates to increase.

Tip 2. Coding standards and style guides help prevent code churn

More time is spent reading code than writing it. This advocates making it easy for everyone to read. But, every developer has their own education and project background. They also have their own language preferences and writing style. Yeah… Standardize. Establish a coding standard for your team. Choose coding style guides. Make it clear to everyone that you expect their code to follow these standards. You can expect some productivity and efficiency metrics to take a small dip in the short-term. In the long-term, reading code will be easier and faster for everyone. Standardization will also apply to less code churn across all your projects. Here’s a short list of links to good style guides: And here’s a much longer list of style guides. Though it’s not practical to tell your developers what to write, you can tell them how to write it. Coding standards and style guides serve as a Standard Operating Procedure (SOP). They provide you an opportunity to define for your team “What is good enough” when it comes to coding. Don’t let “good enough” be nebulous or a matter of debate. You can always update these documents.

Tip 3. Managing perfectionists

Developers who are perfectionists can generate large amounts of code churn. It’s a great trait, but not a great practice. Managing perfectionists presents a challenge. You want them to continuously strive to produce better code. But, they must also understand “the software development process.” Fixating on perfect code risks a cascading impact on the rest of the team plus the project’s cost and schedule.

Perfection is a process – more than a result. By the time one achieves perfection, one’s standards for it will have changed. Besides, it’s not up to the developer to decide what perfection is. Perfection is decided in part by the customer (and end-users). It must meet requirements, launch on time and on budget.

The software development process is to continuously and consistently produce a new release. Continuous Product Development (and similar methodologies) has it right. Let’s get something good out fast now, we can improve it later, in a controlled manner. Help your perfectionists understand the big picture.

Tip 4. Stop reinventing the wheel

Some developers may feel the urge to create new solutions to problems for which there are already plenty of time-tested, stable solutions. Experimentation is fun – but it leads to considerable amounts of code churn. Here, your standards for what’s “good enough” come in again. Clarify for your developers the resources they are encouraged to use.

Software libraries are created, in part, to make programming easier. Software libraries make it so developers don’t have to constantly reinvent the wheel. Over 180,000 open source projects under 1,400 different licenses are available if you meet their licensing terms. Nothing prevents developers from reviewing and applying logic from other projects to fit their task.

Third-party products and services may also be an option. Just have a clear process for how to handle third-party solutions. How are they to be reviewed, tested, and approved? What are the financial constraints?

Tip 5. Team management with automated analytics

Programs like Gitential make it easy to track software developer performance across a wide range of metrics on the fly. Gitential gives you the pulse of the key drivers of software development. At a glance, you can see the speed, quality, efficiency, and collaboration on your project. Code churn, for example, is a top indicator of code quality and defect density. It should be evaluated alongside other metrics like defect ratio, error count, test volume, and code complexity.

If you follow our first four tips, you should see a dramatic and rapid reduction in code churn. But, remember Pareto Principle’s assertion – a majority of causes are responsible for a minority of effects. Developers are responsible for nearly all the other reasons for code churn. With automated analytics, you can respond faster when a developer appears challenged:

  • Their current assignment uses a language they’re not as proficient with.
  • Switching from the office to telecommuting may be suffering due to distractions.
  • The developer may be trying to code too fast or isn’t taking regular breaks.
  • A developer may have too much work assigned or is starting to burn out.
  • A developer may not be testing enough or skipping other processes.
  • Their assignment is more complex than usual.
  • Life stress, poor sleeping schedule, relationship issues, etc.

There are many potential factors that can contribute to code churn. Whatever the reason, it is a sign of a great software manager to facilitate your team’s success. Sometimes, that means making an extra effort to show you are available if a developer needs to talk.

In Summary

At first glance, code churn may seem like a fairly straightforward issue. It’s easy to track and measure. It’s a great indicator for predicting defect density and code quality. The reasons for it are numerous and complex. Software engineering managers can do several things to get a handle on it. It may sound like a lot of upfront work. Many resources are available to get you started by adopting coding standards and style guides. It’s a short-term investment that will provide immediate and long-term dividends:

  • Mid-stream changes can be minimized to reduce mid-and-late stage code churn.
  • A clear standard for writing and submitting code will reduce code churn from the get go.
  • Uniformity will make reading everyone’s code easier and faster.
  • Avoid code churn due to unnecessary experimentation and fixation on perfect code.
  • Monitor developer performance to respond faster to developer challenges.

A final note on common sense and context is warranted.

Your team may specialize in mobile apps. On mobile projects, they may have a code churn rate of 20-25%. Say you get a new client wanting companion software for an IoT device. What if their code churn spikes to 35-40%? Is that a cause for alarm? Probably not.

Some IoT projects involve backend and companion software development in parallel with the device. This reinforces a very modular approach. Changes in hardware can require changes in software. That will cause code churn to spike, too. That’s also not a cause for alarm. Some changes are inevitable – and that can be a good thing.

November 2022 Release Notes

Here’s what’s new in our November 2022 Release Notes:

* Improved data exports for our custom solutions;
* Stabilized backend environment for smoother workspace data refreshes;
* Flexible pagination;

Read More »

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.