Code churn

How it is measured

Lines added inside a recent window that get modified or deleted again before that window closes, by the same author, as a share of total lines written.

Both conditions do real work:

The window separates churn from maintenance. Without a time bound, every long-lived codebase reports enormous churn, and all it means is that the code is old and still in use.

Same author separates rework from collaboration. Somebody else improving your code is code review functioning correctly. You rewriting your own work from last week is a different signal.

Why it is worth watching

Churn is one of the few available signals about upstream clarity. Almost every engineering metric measures what happened after the work was understood — how big the change was, how long review took, whether it broke. Churn measures whether the work was understood at all.

High churn on a feature usually means one of:

• The requirements were unclear or moved after coding started
• The problem was genuinely novel and needed exploration, which is fine
• The design was settled in the editor rather than before it
• Someone was blocked on a decision and kept guessing

Only the second of those is healthy, and the difference between them is a conversation, not a number.

What it misses

It punishes exploration. Prototyping is churn by design. Any team that treats churn as waste will discourage exactly the throwaway work that makes hard problems tractable, and a low-churn team may simply be one that never attempts anything uncertain.

It is easily gamed by not committing. A developer who works for a week on an uncommitted branch and pushes once produces beautiful churn numbers and worse working habits. Metrics that measure commits reward hiding work in progress.

Formatters and renames wreck it. A repository-wide reformat, an automated migration or a rename sweep will register as enormous churn and mean nothing. Mechanical changes have to be classified out or the metric is noise.

It cannot see thinking. Code rewritten three times because the developer kept finding a better shape is churn. So is code rewritten three times because nobody knew what was being built. Same number, opposite situations.

How to read it well

Never use it at the individual level. Churn varies more between types of work than between people, so comparing developers mostly ranks who was assigned the vaguest problem. It is the one metric here most likely to do damage if it reaches a performance review.

Use it per project or per feature, and use it as a retrospective prompt. "This feature churned three times our usual rate — what did we not know when we started?" is a genuinely useful question, and the answer is almost always about the specification, not the engineering.

Read it with pull request size. High churn on small changes usually means unclear requirements. High churn on large changes usually means the change should have been broken up before it was started.