Codebases rarely rot all at once. They rot the way a building does: one broken window nobody fixes, then another, then the whole place looks abandoned and people stop caring. Andy Hunt and Dave Thomas borrowed that metaphor for The Pragmatic Programmer, and it remains the clearest explanation of why small messes matter far more than their size suggests.
Key Takeaways
- The broken windows metaphor, from The Pragmatic Programmer, says one unfixed mess invites more (broken windows in software).
- Software entropy is contagious: neglect signals that quality doesn't matter here (software entropy).
- The real damage is to developer mindset and team culture, more than to any single file.
- Fixing small things fast is cheaper than the standards drift it prevents.
The Metaphor
Hunt and Thomas introduced the idea in The Pragmatic Programmer in 1999 (software entropy). A building with one broken window left unrepaired signals that nobody is watching and nobody cares, which invites more damage. A codebase works the same way. One hacked-together function nobody cleans up, one failing test everyone ignores, one TODO that's been there two years, and the message to the next engineer is that this is a place where standards slide.
The consequence is that entropy compounds. The next person adding code to a messy file writes to the standard of the file rather than the standard of the team, because matching the surroundings feels natural and fixing them feels like someone else's job. Repeat, and the decay accelerates (broken windows and code quality).
The Real Damage Is Cultural
The interesting claim is about what one messy function does to people, rather than what it costs on its own. A broken window changes how developers think about quality on that codebase: it lowers the bar they hold themselves to, makes cutting a corner feel acceptable, and quietly redefines "good enough" downward. Neglect turns out to be one of the strongest accelerators of software decay, faster than complexity or age alone.
That also means the fix is cheap relative to the damage. Repairing a broken window early costs minutes and resets the signal. Leaving it costs you the standard.
| One broken window | The pattern it starts |
|---|---|
| A hacked function nobody cleans | Next person hacks too |
| A test that's been failing for weeks | Tests stop meaning anything |
| A two-year-old TODO | TODOs become decoration |
| "We'll fix it later" | Later never arrives |
A Concrete Version
A team's CI has one flaky test that fails maybe one run in five. Nobody fixes it, so everyone learns to re-run the build. Within two months, a genuinely broken test gets re-run three times and merged anyway, because "the tests are always flaky." The single unfixed window didn't just cost one test; it destroyed the signal value of the entire suite, and a real bug walked through the hole. Fixing the flake in week one would have taken an afternoon.
The Honest Counterpoint
Worth being straight about this: the original criminology broken-windows theory is genuinely contested, and later research questioned how well the policing evidence held up. So treat this as a metaphor that resonates with engineering experience rather than as a proven empirical law about code. There's also a failure mode in the other direction, where "fix every broken window immediately" becomes an excuse to gold-plate, endlessly refactor, and never ship. The useful version is proportional: fix small messes when they're small, especially the ones that signal standards (failing tests, dead code, obvious hacks), and let deliberate, tracked technical debt exist where it's a real trade.
What This Means for Teams
Broken windows explain why quality is a culture problem more than a tooling one, and why the standard a team holds gets set by what it tolerates rather than what it documents. Senior engineers tend to fix small things as they pass, leaving code a little better than they found it, which keeps the signal intact. It connects directly to the technical debt quadrant (deliberate debt is fine; neglect is not) and to where refactoring pays off. See available engineers.
Frequently Asked Questions
What is the broken windows theory in software?
A metaphor from The Pragmatic Programmer: one unfixed mess in a codebase signals that nobody cares about quality, which invites more messes. Software entropy spreads through neglect.
Why does one small mess matter?
Because of what it does to people. The next engineer matches the standard of the surrounding code, so a single tolerated hack lowers the bar for everyone who touches that area afterward.
Is the theory proven?
The original criminology theory is contested, so treat this as a metaphor that matches engineering experience rather than an empirical law. The mechanism, standards drifting toward what's tolerated, is widely recognized by practitioners.
Doesn't this justify endless refactoring?
It can be taken too far. The proportional version is to fix small messes while they're small, especially ones that signal standards like failing tests, while allowing deliberate, tracked technical debt where it's a genuine trade.
The Bottom Line
Codebases decay through tolerated small messes, because each one tells the next engineer what the real standard is. Fixing a broken window early costs minutes; leaving it costs you the standard and, eventually, the signal value of your tests and reviews. Treat small cleanups as culture maintenance, and keep deliberate debt separate from plain neglect.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
