Broken Windows
- Categories
- Complexity
- Sources
- The Pragmatic Programmer
Software rots the way a building does: one visible, unrepaired flaw, a "broken window", signals that no one cares, and invites more neglect until decay accelerates. The remedy is to fix small problems promptly rather than letting them accumulate into entropy.
Why it Matters
Quality erodes gradually and socially. Tolerated mess lowers the standard for everyone, and each new shortcut feels acceptable next to the existing ones. Keeping the system clean is mostly about not letting the first broken windows stand.
Signals
- "It's already messy here, so a bit more won't matter."
- Known smells, dead code, and hacks left in place for months.
- Standards quietly dropping as workarounds normalize.
Benefits
A codebase that stays habitable, a culture that holds its quality bar, and decay caught while it is still cheap to fix.
Risks
Treating every imperfection as an emergency (over-polishing) wastes effort; the point is to prevent visible, contagious neglect, not to chase perfection. Conversely, deferring all cleanup invites the spiral.
Tensions
Fixing windows competes with delivery pressure, the same tension as strategic versus tactical work: the cost is immediate and the payoff is a slower rate of decay, which is hard to see.
Examples
Cleaning up a hack as soon as it is noticed rather than after it has been copied ten times; a team that keeps the build green and the lint clean so the next shortcut stands out instead of blending in.