Code Churn is when an engineer rewrites or deletes their own code that is less than 3 weeks old. For example, a Churn rate of 9-14% for a senior engineer might be completely expected. Unusual spikes in Churn can be an indicator that an engineer is stuck. Or high Churn may also be an indication of another problem like inadequate specs. Knowing immediately as your team is experiences churn spikes helps you have timely conversations to surface any potential problems.
In this article
How is Churn calculated?
When determining code Churn, we look to the lines of code that are removed or changed, but we also look for a set of context lines to determine if multiple changes are within the same hunk of code or a separate hunk of code. The set of context lines is determined by the default “git dif” which is a block of 4 or more lines of unchanged code before and/or after changes. Before moving forward here are a few definitions to keep in mind:
- Hunk- A hunk is a continuous block of change. A hunk can include removed, added or unchanged lines of code.
- Block - A block of code is delineated by 4 or more lines of unchanged code. Also referred to as context lines.
All Churn no New Work
In the example below, although we are seeing new lines of code being added (lines 100-104 and 106-119) since there are only three lines of context (a block of unchanged lines of code) between the new code added and the deleted line on line 100, all this code will be reported as one hunk, and therefore all Churn.
Some Churn and some New Work
In the following example we are seeing four lines of context (a block of unchanged lines of code) between the first line of code deletion (line 68) and the second set of code removals (lines 77-79). Therefore, lines 72-73 will be considered New Work.
As long as there are 4 lines or more of unchanged lines of code between each of your code changes then each will be marked as a separate hunk and calculated as such. If you want more information about Churn, check out What is Churn and our blog post 6 Causes of code Churn and what you should do about them.
How does Churn impact productivity?
On Tuesday, he decided to tweak his code and checked in this change:
Notice that the last line changed. So Jason Churned one line of code. Or to put it another way, he gets no credit for the line of code he wrote yesterday.
On Wednesday he decided to tweak it again and checked the following code in:
Now he’s changed the last two lines of code. Again, Jason gets no credit for yesterday’s change and he loses credit for the original line of code he checked in on Monday. In effect, Jason has Churned 100% of his code this week.
Simply put, Jason’s contribution on Monday and Tuesday was… nothing. He may be working hard but he’s not creating value for those efforts.
In our simple example, the net result was that Jason took three days to get this feature right. Now in all fairness this may or may not be his fault. It could be the product manager wasn’t clear. It could be the spec changed. It could be he got the requirements wrong.
In any case, as Jason’s manager, you need to look a little deeper as to why he keeps rewriting the same lines of code over and over again. If you’re on the lookout for spikes in Churn, you can diagnose problems early and keep your team from getting discouraged.
If you need help, please email firstname.lastname@example.org for 24/7 assistance.