You can predict where bugs will show up before they do, and you don't need AI to do it. Microsoft researchers found that one of the strongest early signals of defect-prone code is churn: how much a file has been changing. Code that churns a lot is where bugs cluster, and their model spotted fault-prone files with nearly 90% accuracy.
Key Takeaways
- Nagappan & Ball (2005) found relative code churn strongly predicts defect density (Microsoft Research).
- Their churn model discriminated fault-prone from clean binaries with 89% accuracy on Windows Server 2003 (Microsoft Research).
- The key was relative churn (change relative to file size and time), not absolute lines changed.
- Churn tells you where to focus testing, review, and refactoring before the bugs appear.
What the Study Found
The research is Nagappan and Ball's 2005 paper, "Use of Relative Code Churn Measures to Predict System Defect Density," presented at the International Conference on Software Engineering (Microsoft Research). Code churn is the rate at which code changes: lines added, modified, deleted over time. Their finding had two parts. First, absolute churn (raw lines changed) is a poor predictor of bugs on its own. Second, relative churn, change measured against things like the file's size and how long the churn has been happening, is highly predictive. Their model, validated on Windows Server 2003, told fault-prone binaries apart from clean ones with 89% accuracy.
In plain terms: the files that keep changing a lot, relative to their size, are where your bugs are going to be. Heavy churn signals complexity, unclear requirements, or a piece of the system that's under constant pressure, and all of those breed bugs.
Why Churn Signals Risk
Heavy churn is a symptom. A file that everyone keeps editing is often one that's central and complex, or one whose requirements keep shifting, or a spot where people keep patching without fixing the root cause. All of those breed bugs. Each change is also a fresh chance to introduce a defect, so the more a file changes, the more shots at a bug it takes. That's why churn works as an early warning: it points at the hot spots before they fail (more on churn and defects).
| High-churn file | What it often means |
|---|---|
| Constantly edited | Central, complex, under pressure |
| Requirements keep shifting | Unstable, bug-prone |
| Repeatedly patched | Root cause never fixed |
| Many hands | More chances to introduce defects |
A Concrete Version
A team is deciding where to spend a limited testing and refactoring budget. Instead of guessing, they look at churn: which files have changed the most, relative to their size, over the last few months. A handful of files light up, the payment reconciliation module, one tangled API handler, a config loader everyone keeps tweaking. Those are exactly the files that produce most of the incidents. They focus review and tests there, and defect rates drop, because they aimed at the hot spots the data revealed instead of spreading effort evenly.
The Honest Counterpoint
High churn is a signal, not a verdict, and reading it naively causes its own problems. Some churn is perfectly healthy: a file under active, intentional development will churn a lot without being buggy, and punishing churn can discourage the very refactoring that reduces risk. The insight is relative and diagnostic. Use churn to ask "why does this keep changing, and is it well-tested?", rather than to freeze files or rank engineers by how much they edit. Paired with judgment, it's a map of where to look.
What This Means for Teams
Churn-based thinking is a cheap, powerful way to focus scarce senior attention where it pays off, the same targeting logic behind spending refactoring effort on high-churn code and watching for bus-factor risk in the files only one person touches. It's the kind of data-informed prioritization experienced engineers do naturally: fix the hot spots, not the whole codebase. See available engineers.
Frequently Asked Questions
Does code churn predict bugs?
Yes. Microsoft's Nagappan and Ball found that relative code churn strongly predicts defect density, discriminating fault-prone from clean binaries with about 89% accuracy on Windows Server 2003.
What is relative code churn?
Change measured against context, like a file's size and how long it's been churning, rather than raw lines changed. Absolute churn is a weak predictor; relative churn is a strong one.
How do I use churn?
Look at which files change most relative to their size, and focus testing, review, and refactoring there. High-churn files are usually your defect hot spots.
Is high churn always bad?
No. A file under active, intentional development churns a lot without being buggy. Churn is a diagnostic signal to investigate, not a rule to minimize change or rank engineers.
The Bottom Line
You can see where bugs will cluster before they arrive: the files that churn the most, relative to their size, are your defect hot spots. Microsoft's research made this concrete, predicting fault-prone code with 89% accuracy from churn alone. Use it to aim testing, review, and refactoring at the hot spots, and stop spreading scarce attention evenly across code that doesn't need it.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
