Code that is rewritten within 21 days of its first merge is called Code Churn. Also referred to as code rework, code churn can help managers identify a host of issues like:
- Struggling engineers (usually a sign of inefficient effort allocation or hiring needs/inefficiencies),
- Areas in code that are problematic
- Inefficiencies in the product team,
- and more.
Code churn is highly contextual. It can be good during the initial states of the project that involves high levels of experimentation, and is natural to see high levels of code being churned.
Evolving product or continuous improvement of features mean some degree of code is expected to churn.
Thus, it becomes important to study the industry wide observed code churn levels, and observe code churn levels within the company and the teams in the context of the team, experience, and the state of the project. Once these factors are observed with the right context, a base line can be set and the teams can strive to keep code churn under these levels.
What can high levels of code churn indicate?
- Complicated tasks
- Unclear requirements or changing requests from external stakeholders
- An indicator of future quality problems
- Deadline is at risk
- What is code churn? Read our in depth explainer on code churn on our blog.
- Read all about what causes code churn, and possible counter measures on our blog post titled “Code churn: An analysis of troublesome workflows and possible countermeasures”.
- Learn how to leverage code churn metric in your code reviews.
Subscribe to Hatica's blog
Get bi-weekly emails with the latest from Hatica's blog