Definition
Broken windows theory holds that a single visible, unrepaired sign of disorder — a smashed pane, an unfixed bug, a tolerated hack — signals that no one in charge cares, which accelerates further decay far beyond what the original damage warranted.
The theory was introduced by criminologists James Q. Wilson and George Kelling in their 1982 essay "Broken Windows," where they argued that communities tolerating visible minor disorder send an invitation to serious crime. Software engineers Thomas and Hunt transplanted the same mechanism into codebases in The Pragmatic Programmer: one sloppy commit left unchallenged tells every subsequent developer that quality is negotiable here. In both domains, the broken window is less about the physical damage and more about the social signal it broadcasts.
Why it matters
How it works
The original theory — urban disorder and crime prevention
Wilson and Kelling's 1982 argument was both empirical and normative. The empirical claim: a study of New Jersey foot-patrol officers showed that officers who engaged with minor disorder — public drinking, loitering, vandalism — produced calmer neighbourhoods even without measurable effect on reported crime rates. The normative claim: communities have a right to order, and policing should maintain that order, not merely react to crime after the fact.
The mechanism they proposed was social signalling. Disorder signals that residents lack the collective will or capacity to enforce norms. That signal attracts further disorder; marginal bad actors, who would restrain themselves in an ordered environment, read the signal as permission. The broken window, in their telling, is not a cause of crime but a precondition that changes the social calculus for everyone present.
Zero tolerance as the policy derivative
Zero tolerance policing — most visibly implemented in New York City under William Bratton in the mid-1990s — operationalised broken-windows theory as an enforcement mandate: officers were expected to act on all infractions, not just serious ones. Crime fell sharply in 1990s New York, and the policy was credited. The empirical picture is messier: crime fell simultaneously in cities with entirely different policing approaches, and no clean causal link between order maintenance and crime reduction has held up under rigorous scrutiny.
More durable are the critiques of how zero tolerance operates in practice. The criminologist Barbara Hudson coined "net-widening" and "mesh-thinning" to describe how the policy erodes the distinction between crime and nuisance, pulling more people — disproportionately young men of colour — into the criminal-justice system. A further irony noted in criminological analysis: zero tolerance defines up visible street disorder while defining down suite crime. Order maintenance falls on low-status, visible offending; corporate fraud, tax evasion, and occupational safety violations escape the logic entirely. The slogan is intolerance of disorder, but the institutional practice is intolerance of visible disorder by low-status people.
Software entropy — the programmer's broken window
Thomas and Hunt borrowed the metaphor directly in The Pragmatic Programmer, applying it to the entropy that accumulates in codebases. Their observation is that projects rarely fail because of an unsolvable engineering problem. They fail because nobody fixed the small broken window — the misleading variable name, the disabled test, the copy-pasted block nobody wanted to refactor, the architecture decision that was always supposed to be temporary. Each tolerated decay implicitly tells the next developer: the standard here is 'good enough for now,' and that standard compounds.
The entropy mechanism in software is the same social signalling Wilson and Kelling described. A pristine codebase creates mild social friction against degradation — a developer adding slop to a clean system feels the incongruity. In a degraded codebase, that friction disappears, and each addition feels like one more brick in an already-crumbling wall.
Boarding up — the pragmatic remedy
The Pragmatic Programmer remedy is not the heroic rewrite. It is constant, low-key repair: fix broken windows as soon as you see them. When immediate repair is genuinely impossible — under deadline, in someone else's module — board it up: comment out the offending code with a dated note, write a failing test that documents the defect by name, or mark it explicitly as technical debt. The act of naming and flagging is what interrupts the normalization cycle. The window is not the problem; the silent acceptance of it is.
This discipline scales to teams in the same way. A pragmatic team does not have one appointed quality guardian — it has a shared norm that everyone fixes what they find, and everyone calls out what they cannot fix. A single unaddressed broken window is a signal to every team member about what the team actually values versus what it says it values.
The asymmetry between decay and repair
One under-appreciated feature of broken-windows dynamics is the asymmetry in direction. Decay is faster than repair and requires less effort per unit. A single bad commit degrades a module's reputation; restoring that reputation requires demonstrating sustained attention over many commits. A single un-prosecuted violation of a community norm requires many successful interventions to counterbalance. This asymmetry explains why the theory emphasises early intervention — the first broken window is the cheapest to fix, and it is also the one that has the largest downstream effect if left unaddressed.
Practical application
In a codebase
When you encounter a broken window you cannot fix immediately, do not leave it silent. The silence is the problem. Options in ascending order of effort:
- Add a comment with a date:
// FIXME 2026-05-26: this bypasses auth check, tracked in issue #1234 - Write a failing test that names the defect exactly — even a test that asserts
falsewith a clear message counts as boarding up. - Open a tracked issue and paste the link next to the offending code. The link is the acknowledgement.
- If the defect is architectural, schedule a dedicated slot and treat the scheduling as part of the repair.
The goal is always the same: make it unmistakable that the damage is seen and not accepted as the new normal.
In a team
A single individual consistently repairing broken windows has limited effect if the team culture passively re-opens them. The leverage point is making repair a default expectation, not a heroic exception. In practice this means: code reviews that flag broken windows as blockers rather than suggestions; retrospectives that ask "what are we currently tolerating that we wouldn't have accepted three months ago?"; and explicit team norms about what constitutes a broken window versus an acceptable tradeoff.
In policy and community settings
The criminological lesson is more cautionary. The signal-mechanism is real — visible disorder does affect how people in a space calibrate their behaviour — but policy responses that target all visible disorder without distinguishing between harm levels and without attending to who bears the cost of enforcement will replicate zero tolerance's failures. The diagnostic question is not "is there disorder here?" but "whose disorder is being addressed, at what cost to whom, and does the aggregate harm calculation support this intervention over alternatives?"