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.
What is the code churn rate?
Code churn rate is the number of times changes are made to the code during the development cycle. Code churn is a natural part of the coding process and can fluctuate based on various factors. Code churn rates can be segregated into good and bad and be normalized across developers, teams, modules, and projects as well.
Why are Code Churn Rates crucial for developers?
Code churn rate metrics are crucial to understanding the entire development process and the people involved - both the developer and the client.
It can indicate internal and external hurdles such as constant change by the teams to achieve perfection or changes made to accommodate unclear requirements. Measuring the code churn rate helps managers navigate through the entire development process and meet the deadlines without any hold-ups.
Reasons for code churn -
- Code churn rates can help identify the nature of the feature under development. For instance, a new feature may demand multiple iterations to become fit for release, resulting in a spike in the code churn rate.
- Can be an early indicator of scope creep as the higher rates can sometimes be the result of new features or requirements that were not initially agreed upon.
- A higher code churn rate after feedback or a stand-up discussion translates to the feedback being implemented to the initial code base.
- Code churn rates also signal a red flag in the clarity of the deliverables, as unclear objectives may require the developer to work on the same task multiple times.
- Code churn rates can also indicate blockers in the development process and help the developer to get extra pairs of eyes and hands.
- It also provides insights into the workload distribution and helps optimize resource allocation by identifying the areas of the code which are often changed and require more testing.
- Tracking code churn rates help understand if the development process needs more testing or a push in the deadline and saves the team from last-minute surprises.
- The churn rate should reduce or stabilize towards the deadline. Else, the code can be very volatile, or bug-prone after production.
The iterative code churns cycles can be interpreted in two ways - the evolution of the developer working on the code or the evolution of the file during the development process.
How to calculate the code churn rate?
As mentioned earlier, code churn occurs when the developer deletes, updates, modifies, or rewrites sections or the entire code within 21 days of writing it. This code churns can be an indicator of something good, like code refactoring, or bad, like a non-linear development approach. However, the verdict can only be passed after the code churn rate calculation, which can be performed in two ways.
- One way for code churn rate calculation is to consider it as an aggregate of the number of lines of code added, deleted, and modified. For instance, if you have written over 1000 lines and deleted about 350 for whatever reason, the code churn rate is 35%.
- The other is file-based, where n number of updates/modifications happen to a file over a particular time, and the code churn rate calculation returns a value of n.