Disorder Invites Disorder
In 1982, social scientists James Q. Wilson and George L. Kelling published an article in The Atlantic proposing what became known as the Broken Window Theory. The core idea: if a building has one broken window and it goes unrepaired, vandals will soon break the rest. The single broken window sends a signal — "No one is watching. No one cares." — that lowers the psychological barrier to further damage.
In software, broken windows are everywhere:
| Broken Window | The Signal It Sends |
|---|---|
| A 200-line function with no comments | "Readability doesn't matter here" |
| A commented-out unit test | "Tests are optional" |
A TODO: fix this later from 3 years ago |
"We don't follow through" |
A variable named temp2 |
"Naming conventions are aspirational" |
An empty catch (Exception e) {} block |
"Error handling is someone else's problem" |
| A hardcoded password in source code | "Security is not enforced" |
The mechanism is psychological, not technical. When a developer opens a file and sees disorder, their internal standard for what's "acceptable" in that file drops. They think: "This file is already messy. My hack won't make it noticeably worse." And they're right — individually. But multiplied across a team of 10 engineers over 18 months, each small concession compounds into a codebase that no one wants to work in.
The compounding effect is the danger. A single broken window is trivial to fix. But broken windows breed. Once a module has three hacks, the fourth is psychologically free. Once a service has no tests, writing the first test feels like an impossible task ("Where would I even start?"). The cost of repair grows faster than linearly with delay — in practice, it often grows exponentially, because each new layer of disorder makes the underlying disorder harder to reach.
The practical countermeasure is simple but requires discipline: fix broken windows immediately, or at minimum, board them up. If you can't refactor a messy function right now, add a comment explaining why it's messy and create a tracked ticket. The signal changes from "no one cares" to "we know this is broken and we have a plan." That distinction matters enormously to the next developer who opens the file.
Interviewers sometimes ask: "How do you maintain code quality on a team with mixed experience levels?" A strong answer references the Broken Window Theory explicitly: "We treat code quality as a team norm enforced at the CI level, not a personal virtue. Linters, formatters, and complexity checks run on every PR so that the standard is visible and consistent regardless of who wrote the code. This prevents the psychological drift where junior engineers assume that whatever they see in the codebase is acceptable."
Key Point: The Broken Window Theory explains why codebases don't degrade linearly — they degrade exponentially. The first broken window is cheap to fix and expensive to ignore. Senior engineers understand that maintaining standards in small things (naming, formatting, dead code removal) is not pedantry — it's structural defense against cascading decay.