Broken windows in software

The broken-windows idea comes from urban criminology in the 1980s. The claim is that visible disorder (a smashed pane, graffiti left up) signals that nobody is tending the place, and that signal lowers the cost of the next bit of damage. Jeff Atwood sketches the original argument and a famous car experiment in The Broken Window Theory.

Software borrows the image on purpose. A flaky build, a module everyone treats as a junk drawer, a warning you scroll past every day. Each reads as “this is how we work here.” The metaphor is not that your repo is a crime scene. It is that perception of neglect feeds more neglect.

One failure mode is the read that nobody owns the standard on shared ground. Dave Thomas describes a module that looks abandoned by its owner, so the next person infers permission to match that level. In the Artima interview Don’t Live with Broken Windows he puts it bluntly. “It comes down to showing that you care.”

When you can fix a small break in the same stroke as your task, do it (the scout rule in spirit). When you cannot, make the hazard legible so the group sees intent instead of apathy. Comment the edge case, fence the dead path, file the ticket and link it in the README. Andy Hunt makes the same move in that conversation. Treat “broken” as a state to acknowledge or clear, not as background noise.

Signals of care are cheap compared to the spiral they prevent. Left alone, that spiral is the human face of technical debt.