
Broken Windows Theory
The broken windows theory states that visible small deficiencies lead to bigger problems. Originally rooted in criminology, it is now also used in software development and AI systems as an image for creeping quality decline.
A house stands empty, a windowpane is smashed. If nobody repairs it, soon all the panes are broken. This is how social researchers James Q. Wilson and George L. Kelling described a connection they had observed in city neighborhoods in 1982. Their thesis: visible neglect signals that no one here feels responsible. Whoever sees this adheres less to rules themselves. Over time, a small thing thus becomes a larger decay.
From the street corner to software development
The theory was originally formulated for police work and remains controversial there to this day. In the 1990s, New York used it as justification for tough action against minor offenses. Whether the declining crime rate was really due to this is still disputed among researchers. Critics point out that crime fell at the time even in cities without this strategy.
In the tech industry, the term has had a second career. Programmers use it as an image for the state of program code. A well-known technical book, “The Pragmatic Programmer,” transferred the idea to software in 1999: if a team tolerates a sloppy spot in the code, the threshold for the next one drops. After a year, a clean project has turned into a messy tangle.
For you as a reader of tech news, this is relevant because the term often appears as an explanation for company problems. When a product slowly gets worse or security vulnerabilities pile up, neglected small issues are readily cited. The expression is a description here, not proof.
The mechanism behind the decay
The core of the theory is not the damage itself, but the signal. A broken pane costs little. But it tells every passerby that violations here have no consequences. People strongly align their behavior with what they consider normal in their surroundings. It is precisely this expectation that shifts when deficiencies remain visible.
With code it works similarly, just without an audience on the street. A developer opens a file and already sees three makeshift quick fixes there. Their own quick solution then barely stands out and seems justifiable. Because software is worked on by many people over years, these decisions add up. Experts speak of technical debt: effort that is postponed into the future and later paid back with interest.
The practical recommendation is therefore to clean up early and consistently. Small repairs are cheap, a complete overhaul is expensive. A common mistake, however, is treating the theory as a proven law of nature. It describes a plausible tendency, not a fixed cause-and-effect relationship.
Broken panes in AI systems
Today the term comes up particularly often in connection with training data. AI models learn from vast amounts of text from the internet. Anyone who fails to filter out bad, false, or biased examples there will later find them reflected in the model’s behavior. A single flawed source barely stands out, but thousands of them noticeably change the result.
The image is also used for AI-generated code. Assistance systems suggest code that fits the existing project. If this project is already unclean, the AI reinforces exactly this pattern. A broken pane then very quickly becomes many, because a machine takes over the copying.
In everyday life, you also encounter the idea outside of technology. Schools, train stations, and residential complexes use it to justify why graffiti is removed immediately. In business news, it serves as an explanation for why companies see further scandals follow after initial small ones. The expression is thus above all a mental shorthand for a very general connection.