What is the "broken windows" theory applied to software quality, and what concrete signals would tell you a codebase is suffering from it?

## Origin **Wilson & Kelling, "Broken Windows" (*The Atlantic*, 1982)** argued that visible signs of disorder in a neighbourhood — an unrepaired broken window, graffiti, litter — signal that nobody is monitoring or cares, which invites further disorder. (The criminology claim is contested; that debate is irrelevant to the software analogy, and it's fine to say so.) **Andrew Hunt & David Thomas, *The Pragmatic Programmer* (1999)** carried it into software: *"Don't live with broken windows."* Fix bad designs, wrong decisions and poor code **as soon as you see them**; if you truly can't fix it now, board it up — comment it out, mark it, put up a `NOT IMPLEMENTED` — so it's visible that the mess is known and abnormal, not endorsed. ## The mechanism is social, not technical This is the part interviewers want. The code does not rot on its own; **people calibrate their standard to what they observe.** 1. A developer opens an unfamiliar file to make a change. 2. They read the surrounding code to infer "how we do things here" — this is a legitimate and necessary heuristic, since the local conventions usually *are* the authority. 3. If what they observe is duplication, magic numbers and dead code, they infer that the effort bar is low. 4. They match the local bar (also rationally — writing pristine code in a swamp looks inconsistent and costs more). 5. The mess is now slightly worse, and the signal to the next person slightly stronger. That feedback loop makes decay **non-linear**: near-clean codebases stay clean cheaply; once neglect is visible, quality falls off a cliff. It also explains why the Boy Scout Rule pays off asymmetrically — reversing the signal early is far cheaper than reversing it late. A second mechanism is **normalization of deviance** (Diane Vaughan's term from the *Challenger* accident analysis): a warning that never corresponds to a real failure gradually stops being treated as a warning at all. That is precisely what happens to a build emitting 800 compiler warnings. ## Concrete diagnostic signals The honest test is: *what has the team stopped reacting to?* | Signal | What it tells you | |---|---| | Build emits hundreds of warnings and nobody reads them | Warning channel is dead; a genuinely important warning will be missed | | Tests permanently disabled/skipped/quarantined, or a "known-flaky" list that only grows | The test suite no longer gates anything; green means nothing | | Static-analysis baseline (grandfathered existing issues) grows every release | The ratchet has been reversed; the gate is decorative | | `TODO` / `FIXME` / `HACK` markers years old with no ticket or owner | Debt is recorded but never scheduled; markers have become noise | | Commented-out code kept "just in case" | Team doesn't trust version control; deletion feels dangerous | | "Copy this module and edit it" as the standard way to add a feature | No shared abstraction; every bug must be fixed N times | | Wide dead zones nobody dares delete | Loss of system knowledge; fear-driven development | | Comments contradicting the code | Nobody is reading either; documentation channel is dead | | Commit messages that are all `fix`, `wip`, `.` | History has stopped being a communication medium | | Long-lived branches that can't be merged | Integration pain has exceeded the pain threshold | | Onboarding time trending up; "only Dana can touch billing" | Comprehension cost, the real interest payment on debt | Note that several of these are **process** windows, not code windows — a permanently red CI pipeline is the loudest broken window a team can have. ## Countermeasures - **Zero-tolerance thresholds beat quality goals.** "Zero warnings" is enforceable and self-sustaining because any new warning is instantly visible. "Fewer than 200 warnings" is unenforceable — no individual warning is ever the problem. The same argument favours treating warnings as errors in CI. - **Ratchet, don't reset.** Baselines/suppression files for legacy issues are fine, but the count must be allowed only to shrink. "Clean as you code" gates — fail the build only on newly changed lines — mechanize the Boy Scout Rule. - **Fix or delete, never disable-and-forget.** A skipped test must carry a ticket and an expiry. Better still, delete it: a test that doesn't run is worse than no test, because it advertises coverage that doesn't exist. - **Board it up if you can't fix it.** Explicitly mark known-bad regions (a `HACK(TICKET-123):` note, an architecture decision record) so the next reader knows the state is recognized and abnormal. - **Repair visibly and early.** Because the mechanism is signalling, a small conspicuous repair — deleting the dead module, clearing the warnings, greening the build — changes behaviour out of proportion to its size. - **Direct effort with data.** Hotspot analysis (files with both high change-frequency and high complexity, popularized by Adam Tornhill) tells you *which* windows actually cost money, so repair effort isn't spent on cold code. ## Honest caveats - The original criminology research is disputed and its policing applications were harmful; the software use is an **analogy about signalling**, and it's a mark of maturity to say that rather than cite it as proven science. - Not all mess is a broken window. Code that is stable, isolated, working and rarely touched is cheap to leave alone — ugly is not the same as costly. The interest rate on debt is proportional to how often you must touch it. - Zero-tolerance taken too far becomes its own pathology: teams that block delivery on cosmetic rules train people to route around the gates entirely. ## How to answer Give the origin in one line, then spend your time on **the social mechanism** (people calibrate to observed standards → non-linear decay) and **observable signals** (what has the team stopped reacting to). Close with the countermeasure pairing: Boy Scout Rule for continuous repair plus zero-tolerance/ratcheting gates so the signal can't drift back.