It’s just one quick fix.
Every developer has said it. And it’s true—it is just one. But that one hack is the start of something bigger. In the same way one broken window invites more vandalism, one sloppy shortcut invites more sloppy shortcuts. Before you know it, your project is a run-down building everyone’s afraid to enter. Turnover rises because nobody wants to work on a legacy codebase. The few who do—those eager to restore it to its former glory—are told, “That’s not the priority… for now.”
The Broken Windows Theory
In 1982, social scientists James Q. Wilson and George L. Kelling proposed something called the Broken Windows Theory . The idea is simple: if a building has a broken window and it isn’t fixed, people walking by will assume no one cares. Soon, more windows will get broken. The same logic applies to litter, graffiti, and other signs of neglect—small acts of disorder signal that bigger acts of disorder are acceptable.
It’s not really about glass. It’s about the message. A single unrepaired broken window tells the world: “Rules aren’t enforced here. Standards don’t matter here”. Once people believe that, deterioration accelerates. What starts as one broken pane becomes an entire building in disrepair.
Broken Windows in Software Development
In software, the “broken window” isn’t shattered glass—it’s that “just for now”
hack you slipped into the codebase. It’s the //TODO you never came back to. It’s the
function named doStuff() that now mysteriously takes nine arguments. It’s those
static methods on classes added for “ease of use”. It’s the overloaded interfaces that do
too much. It’s the tightly coupled services that permeate the entire project, tangled up
in circular dependencies.
You tell yourself it’s temporary. The problem is: every hack is a signal to your team—and to every future developer who touches that code—this is how we work here. Standards aren’t enforced. Shortcuts are fine. And just like in the real-world, once one “window” is broken, more will follow.
A Quick Story
A few years ago, a developer—we’ll call him John—was racing to meet a deadline. A configuration bug was blocking deployment, so John hardcoded the value—just to “get it out the door.”
No one said anything.
Two months later, a new developer copied John’s trick in another part of the code. Six months after that, the hardcoded value was in five different places. A year later, the team spent a full week chasing down why staging and production behaved differently.
The original hack was just one broken window. But it quietly told the whole team: “It’s okay to break the glass here”. Once they believed that, the cracks spread until the building was hard to live in.
The Takeaway
The first broken window is your chance to set the tone. Mark it in the code, create a task to fix it, and actually do it—urgently. Don’t let it rot in the backlog. Prioritise it. Show your team that code quality matters—not as an abstract ideal, but as a practical safeguard for the project’s future.
Because in software, just like in neighborhoods, a single unrepaired window isn’t harmless—it’s an invitation. And once the glass starts shattering, it’s a lot harder to put it back together.