Code Churn is when an engineer rewrites their own code in a short period of time.
Think of it as writing a postcard and then tearing it up and writing it again, and then again. Yes, you technically wrote three postcards, but in the end only one was shipped so we’re really talking about one postcard worth of ‘accomplishment’ from all that effort.
The same is true with code.
Let’s look a specific example and see at how Churn impacts 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.
📝 Check out 6 causes of code Churn and what to do about them.
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.