Code Churn: The Good, The Bad and the... Perfect

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

Run-through

Code churn is regarded by many software engineers as the best indicator of a code’s quality and defect density. Most engineers will also agree that code churn is good or bad relative to when and why it is taking place. As it’s relative, it can be confusing. It’s not a metric that you can look at and say, “Hey, I need to reduce my team’s code churn.” Maybe, maybe not. It could be that a lot of your team’s code churn is tied to circumstances beyond their control. That moves the ball into your court. Leastwise, code churn is worth understanding in detail because it is 100x less costly to catch a defect during the design phase than catching it during maintenance.

Relative Cost to Fix a Defect Based on Where It’s Caught

Design Implementation Testing Maintenance
Defect Discovery Cost MultiplierAWS Code Deploy 1x 6.5x 15x 100x

Source: IBM Systems Sciences Institute

What is Code Churn?

As we discussed in Five Code Churn Tips for Engineering Managers, code churn is an important metric for gauging code quality that is often misunderstood. To summarize, code churn is the amount of change that takes place in a volume of code in a short period of time.

Code churn is automatically tracked by version control systems like Git, and calculated as:

Code Churn = Lines Added + Lines Deleted + Lines Modified

The more frequently code changes, the more likely it is to have defects (defect density). The more time spent changing existing code means less new code and functionality is being produced.

Reasons for Code Churn

For a quick game of “Red Light – Green Light” there are several causes for code churn. While code churn, by itself, is neither good or bad – many of the reasons behind code churn are functionally negative.

  • Prototyping and complex tasks
  • Change requests from external stakeholders
  • Ambiguous project and task requirements
  • Developer knowledge of programming languages
  • Questing for perfect code
  • Burnout and retention/turnover issues

We’ll take a look at each of these in some depth, their impact, how to spot them, and how to prevent, solve, or improve conditions contributing to unproductive code churn.

Prototyping and Complex Problems

Case: Prototyping new projects and solving complex problems are a lot like writing the first draft of an essay in school. It can take a few tries just to come up with a good topic or the logic to support it.

Impact and Visibility: A significant amount of work or code ends up in the trash bin because, for whatever reason, the developer found it wouldn’t work or meet project requirements. Prototyping code churn is a natural and healthy part of the development process and can be seen in the work of all developers in the early stages of a project. Code churn should decrease over time as more and more of it is stabilized, passes tests, and goes through code reviews.

One of the rules of software development is to leave code better off than you found it. In many cases, that involves code churn. Focused renovation may involve refactoring code. Generally, it’s to be expected for code churn on a project to start high. Without other intervening issues, as long as code churn progressively decreases, you’re in good shape.

Solutions: Beyond reducing ambiguity, the main issue with prototyping is making sure developers are not creating custom solutions for problems solved by existing resources unless it’s specified in the project requirements. Every software development team benefits from a mature set of guidelines and work processes:

  • Maintain and enforce coding standards like style guides for each language.
  • Document and share the resources (libraries, frameworks, tools, third-party services, etc.) you want developers to utilize.
  • Have a clear standard for Code that is Good Enough.

Custom created solutions are prone to be characterized by high code churn over a longer period instead of a steady decline. This may be an isolated occurrence where a developer is simply unaware of an existing solution. But some developers are driven by being able to show their creative potential and it’ll be reflected as a trend.

Code Churn Due to Other Stakeholders

Case: Your client came to you with an MVP-style project. Three months into development, the client wants to add a couple of additional features.

Impact and Visibility: Adding features midstream involves a lot of additional unplanned work.
Changes to existing work are followed by a spike in code churn. Changes requests can theoretically come in any stage, but many can be pre-empted. Arguing with clients and executives is not a good idea, but you can present them the additional costs in time and money their changes will involve. And, if they’re okay with that, cool beans, no problem!

Solutions: A lot of change requests are avoidable, but it requires extra effort by the Project Manager and/or Account Manager. You need to verify that the “client” and their specialists are educated about their options. Those options are constantly changing in terms of devices, other third-party software, and the data both can collect.

  • Examine the client’s software specification and use cases, alongside similar or competing software to assess if it’s missing anything obvious.
  • Perform quick research to see if there’s anything in the news (new technology, regulations, key technology partners going out of business) that may impact the project.
  • Talk with specialists to see if the specifications satisfy their needs. But also ask them about items you discovered to be of interest, particularly as relates to data collection.
  • Share any relevant findings with your client and their specialists before starting development to evaluate whether, how, or when to include additional requirements.

Avoid Technical Debt Like You’re Borg goes into further depth, but good examples include 5G, Google Play and the App Store discontinuing support for 32-bit mobile apps, the activation of the EU’s General Data Protection Regulation, Apple ditching Intel chips, and so on. Managers of non-tech companies may not know all of the data they can access. If they discover possibilities later, they may want to include it.

Code Churn Due to Ambiguous Requirements

Case: You asked for an app capable of handling large file uploads. You received an app that handles uploads of up to 20 Mb. But, by large, you meant 50 or even 500 Mb.

Impact and Visibility: When ambiguity is an issue, it is likely to reflect in elevated code churn in all phases of development with your team’s present and past projects. Software development inherently involves high levels of ambiguity. Ambiguity can be an issue depending on how tasks are defined in your project management software..

Solutions: Each team has its own tolerance for ambiguity. Mature teams experienced working together may have their own telepathic sixth sense or innate logic of the implied requirements of a vague task. Teams with many new members need tighter guidance.

Code churn due to ambiguity is not productive, but can be mitigated by:

  • Properly defining project and task requirements is the solution to addressing ambiguity.
  • All team members can benefit from avoiding the words that make things ambiguous – this, that, faster, soon, large, should, may, might… and dangling participles…
  • Be explicit, short and concise. Reference software specifications, branding guide, regulations, or other documents, when additional detail is required.
  • Verify everyone is trained with your project management software or where tasks are defined. Not everyone takes to project management software (PMS) with the same zeal.
  • Use standup meetings to verify with developers that they understand or have questions about the task requirements and specifications.
  • Consider pairing up your Scrum Master and/or Business Analyst with a senior developer to help in defining tasks ahead of each sprint.

If you’re curious, identify a few tasks or files with high code churn and compare with their descriptions in your PMS. Are the tasks vaguely defined? Ask you developers if they feel the tasks are sufficiently defined. Track progress after efforts to make task assignments more explicit.

Programming Language Expertise

Case: A developer who usually writes iOS apps is tasked to work on an Android app; or any scenario involving a mis-match in expertise.

Impact and Visibility: There are about 700 programming languages out there. Most developers are only fully fluent with a handful of them. High performance in one programming language does not infer they will perform similarly in others. When a developer is assigned a task involving a language they know but use less frequently, their code churn is likely to increase or their velocity will substantially decrease. Maybe both.

This case, iOS/Android, is interesting as mobile developers often, but don’t always know both languages or have equal proficiency in the tools and resources of each. They may be reluctant to volunteer that fact, suffice that performance metrics will pick it up.

Solutions: Software development analytics enables data-driven decisions when matching developers to projects and tasks based on programming language and code complexity. The same information is useful for pairing developers and assigning mentors. It’s ideal when you can get a strong iOS developer to work with a strong Android developer when you’re striving to improve your team’s cross-functionality and skills sets.

Perfectionism ≠ Good Coding Habit

Case: The quest for perfection makes for a great philosophical debate but, “By the time you find perfection, your standards for it will have changed.” Each time the developer places the final touch to make their code perfect, they find another flaw and must extinguish it from existence. But in the process, and the process is everything… and everything is IN the process, new flaws emerge… and they must be eviscerated, too. And with it, the deadline came and passed as just another inconsequential moment in the eternal battle against evil imperfections.

Impact and Visibility: Code churn due to perfectionism is seen when a developer makes lots of changes in the mid-to-late stages of a sprint without adding new functionality. Perfectionism will, in the majority of cases, show up as a fairly consistent trend with specific developers. It’s easy to spot in their code churn history and may also be reflected in a pattern of delays with their assigned tasks. In software development, perfect code is not financially viable while often causing delays and missed deadlines. Plus, eventually, the code will be changed due to technical debt, tech churn, or new developers.

Solutions: Perfectionism can be a hard habit to break for some developers and requires delicately training them away from it. First steps in this direction involve talking with the developer about the big picture and reiterating what you mean by code that is good enough. The client may have millions of dollars and thousands of jobs riding upon launching on schedule with software that works “good enough.”

Clearly, I’ve never obsessed about anything. Nope. Not once. But a friend of mine said that what worked for him was a deep discussion about the nature of time. Time may not even exist.Even if it does, we never know how much time we have. Regardless how much time we have, it’s never enough. But, this discussion is probably better left… for another time when we have more time.

Code Churn from Burnout

Case: The performance of one of your best and most experienced developers is steadily declining, code churn increasing, seems more detached, and less engaged.

Impact and Visibility: Burnout tends to show up as a gradual, but steady decline over weeks and months across several performance metrics. These include code churn, code efficiency, responsiveness, review coverage, possibly test coverage, active hours, and more. As it progresses, burnout may become more directly noticeable – in dress, behavior, attitude, social engagement, more sick days, etc. If these indicators aren’t acted upon, developers can become apathetic, not show up for work, contemplate career changes, and well, it can get worse.

Burnout is an occupational hazard for software developers (See: How To Notice And Prevent Software Developer Burnout). Everyone handles stress differently, but the cumulative long-term impact has several consistencies. Among them is the tendency for burnout to build incrementally and in a linear way and then go exponential, like a hockey stick.

Solutions: It’s common for managers to rely more heavily on their best developers for handling the most urgent or complex tasks. Be mindful of their workload, as excessive utilization ties directly into decreased performance with code churn and other metrics. Recognize burnout as something that most developers will experience to some degree. Burnout can be quickly reversed when caught early, so try the following to help keep all of your developers fresh:

  • Take time to interact with your team members, listen to what they have to say.
  • Provide developers regular feedback and thank them for their work.
  • Use performance metrics to keep informed team and project health.
  • Keep retrospectives as a safe zone where developers can openly voice their concerns.
  • Outsource or rotate undesired jobs so no one feels stuck with a task they hate.
  • Maintain clear paths forward with career paths and continuing education programs.
  • Break up the monotony when needed and let developers attend seminars or conferences.

More Reading About Code Churn:

Do you want to read more about code churn to keep your team on track? Check out:

Automate Your Software Development Metrics

Gitential helps you to improve the performance of your software development team based on their Git activities with actionable insights. It’ll help you automate the gathering of software developer and engineer performance metrics, interaction analytics, frequency of commits, volume of code churn, and more! With this data, you can begin measuring the benefits of teamwork in software development, identify what’s holding your team back, improve cycle time, and more. Try Gitential now for free – no credit card needed!

Did you like our content?

Spread the word

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

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

Share on facebook
Share on twitter
Share on linkedin
Share on reddit

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.