6 Causes of Code Churn & What to Do About It | Pluralsight

Think of code churn as the proverbial canary in the coal mine.

When code churn is suddenly higher than expected, it can be an early indicator that something is off with your team. Detecting code churn early means you can help diagnose what’s going on and have a conversation at exactly the right time.

Here are six causes of elevated code churn:

1. Unclear requirements
2. Indecisive stakeholder
3. Difficult problem
4. Prototyping
5. Polishing
6. Under-engagement

Below we will break down these causes of code churn, and give action steps for each.

1. 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 you can 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 (which they always do), they can help speed up the process by providing clear specs.

2. Indecisive stakeholder

A wavering product owner can send an engineer running in circles, with little or no forward progress. While they may see it as harmless, an indecisive stakeholder can cause real damage to your team in morale and progress in other areas. Your engineer may be frustrated.

What you can do:

• Step in to protect the engineer from political overhead.
• If a stakeholder is changing their mind, show them the percentage of engineering burn being spent on rebuilding and remind them of the zero-sum nature of engineering attention.
• Isolate the specific engineers that have been working on the feature and put a time and dollar amount because that’s what brings meaning into the conversation: “These three engineers have been working this feature for months which means it cost . Are you okay with the time and cost that changing your mind would mean? Do you want to change your mind and spend another to get back to where we are now?”
• Make it clear that the waste is happening because of their choices. Bring data to de-personalize the accusations and take the heat out of the conversation.

3. Difficult problem

With a particularly challenging problem, you may expect a higher percentage of exploring and backtracking. It would not be uncommon for churn rates to exceed 60-80%. The key is to get a feel for if the problem has gone on for too long.

What you can do:

• Develop a sense for when a challenge has gone on too long and be proactive.
• Be compassionate. Engineers are some of the smartest people in the world, which comes with pride in their craft. Unless they are copy/pasting in from StackOverflow, most engineering work is solving unique problems. The last thing you want to do is call them out for being in over their head.
• 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.

4. Prototyping

High churn can be expected from an engineer that’s pioneering a new feature. You would expect them to explore multiple implementation paths before finding the right one. When combined with lots of exploratory coding, churn rates in the 60-80% range may not be unusual.

What you can do:

• 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.
• Do nothing, as long as that meets expectations.
• Set a discreet reminder for yourself to follow up at a specific date (e.g. In 2 days I expect for them to be through most of the R&D phase based on where they are now).

5. Polishing

In the final stages before and after a release, small frequent commits with elevated churn indicate engineers troubleshooting remaining problems. These could also be changes incorporated during code review.

What you can do:

• Make a distinction: was the code quality in line with team standards when it was checked in the first time? Is this a little bit of code getting cleaned up in code review? (Great!) Or is it someone checking in code that’s not ready? (Not great!)
• If you have a significant amount of work being checked in that’s not actually done yet, then it’s up to you to be clear what ‘done’ is. Otherwise it will snowball into cultural problems in engineering. Demonstrate the delta between the original requirements and what was delivered.
• Be wary. Huge volumes of churn leading up to a release could mean you’re about to drop a release.

6. Under-engagement

When an engineer has high churn but low throughput, this could also be a sign of burnout. If they’re under-challenged, bored, or working on something they don’t really love, they could be at risk of getting poached from your team.

What you can do:

• A culture of under-engagement is a leadership problem, outside of the scope for this article.
• If you’re still reading, you probably care enough to help fix it. Recommended reading 12: The Elements of Great Managing by Rodd Wagner. This comment provides a great summary of the book—you may recognize that you’re dropping a few from the list.

Do you notice other causes of elevated code churn? We’d love to hear from you!

If you want to see your team’s code churn as it’s happens, request a demo.