What code churn actually tells you about bug risk

Churn is a simple idea with an outsized payoff: it's how often a file changes over time. On its own that sounds mundane. Paired with complexity, it becomes one of the best early-warning signals you have for where the next bug will come from.

Why churn predicts defects

A file that changes every week is a file the team keeps reworking. Rework happens for a reason — the abstraction is wrong, the requirements are unclear, or the code is hard enough to get right that people keep coming back to fix it. Each of those reasons correlates with defects.

The research backs this up: change frequency has been shown to predict defects better than raw size or complexity in isolation. The mechanism is intuitive. Bugs are introduced by changes, and the files that get the most changes accumulate the most opportunities to break.

Churn × complexity: the hotspot

The signal gets sharper when you multiply churn by complexity. A file can be complex but stable (a mature parser nobody touches) or simple but churning (a config file). Neither is scary. The dangerous quadrant is *high churn and high complexity — code that's hard to reason about and* changes constantly. Those are your hotspots, and they deserve the first refactor, the best tests, and the most careful review.

What to do with it

• Rank, don't boil the ocean. You can't refactor everything. Sort by churn × complexity and fix the top of the list.
• Add tests where it hurts. A hotspot with thin test coverage is a incident waiting to happen. Coverage is cheapest to add before the rewrite, not after.
• Watch the trend. A file whose churn is climbing is telling you something is unstable right now.

Impact surfaces churn on every analysis and folds it into the temporal-risk pillar of your score, so the hotspots rank themselves. The point isn't the number — it's knowing where to look first.