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:

Mark checked in the following java script code on Monday:

On Tuesday, he decided to tweak his code and checked in this change:

Notice that the last line changed. So Mark 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, Mark gets no credit for yesterday’s change and he loses credit for the original line of code he checked in on Monday. In effect, Mark has churned 100% of his code this week.

Simply put, Mark’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 Mark 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 Mark’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.

Did this answer your question?