Broken Windows

Four years ago I wrote a short piece about broken windows in software. I’ve been thinking about it again lately, because AI changes the equation in ways I didn’t anticipate back then. Some of it is encouraging. A lot of it is not.

Let me start from the beginning.

In 1982, criminologists James Wilson and George Kelling published an article in The Atlantic called “Broken Windows.” The core observation was simple: a building with one unrepaired broken window tends to accumulate more broken windows. Disorder signals that nobody is watching, nobody cares, and the cost of further damage is low. The metaphor extended naturally to urban decay, and it became one of the most cited, and contested, ideas in social science.

In software, the same psychology applies, just without the graffiti.

A quick patch applied under deadline pressure. A TODO comment that has survived three major releases. A component named NewHeader2_FINAL_v3_DEF.tsx.

These are your broken windows.

They signal to anyone touching the codebase that cutting corners is acceptable here. And once that norm is established, it compounds.

The windows aren’t visible to your stakeholders. That’s what makes them so insidious. The product owner sees a working feature. The manager sees a shipped sprint. The developer sees the ugly truth.

When I wrote the original piece, I was mostly thinking about individual developers making individual decisions. But the broken window problem is really a leadership problem. It’s a culture problem. And if you’re holding any kind of architectural or technical leadership responsibility (whether you’re a tech lead, a CTO, or a fractional advisor coming in from the outside) this is squarely in your domain.

Here’s what I’ve observed in practice: the reason broken windows appear isn’t because developers don’t know better. It’s because the system they work in doesn’t make fixing them the path of least resistance.

Tight sprint cycles, an ever-growing backlog, pressure to ship rather than maintain: these are all structural forces that manufacture broken windows at scale. When I step into a new engagement, this state of the codebase tells me more about how the team is managed than it does about how the developers write code.

A messy codebase is almost always a symptom of a messy process upstream.

The fix isn’t purely technical. It’s a conversation you need to have with the people holding the roadmap. “Maintenance budget” shouldn’t be a dirty phrase. It’s the cost of keeping your investment viable.