Recently, I started reading a book that had been on my reading list for a while: The Pragmatic Programmer: From Journeyman to Master. In the very first chapter, I came across a simple yet powerful concept: the Broken Windows Theory.

The idea doesn’t come from technology, but from criminology. Basically, when an environment shows signs of neglect, for example, a broken window that hasn’t been fixed, it sends a signal that no one cares, increasing the likelihood of bigger problems.

In software, this is more common than it seems.

• A forgotten // TODO
• An outdated comment
• Code written “just for now” that is never revisited
• Tests without proper coverage
• A library that hasn’t been updated since the start of the project
• A vulnerability swept under the rug

These are our broken windows.

The problem isn’t the isolated issue, it’s the cumulative effect.

When small flaws are ignored, they send a silent message to the team: “it’s okay to leave it as it is.” Little by little, the code begins to deteriorate. Quality drops, confidence decreases, and maintenance becomes increasingly difficult.

Software doesn’t break all at once, it wears down gradually. And it almost always starts with small compromises.

Perhaps the greatest lesson here isn’t about code, but about discipline: fixing what’s wrong while it’s still small. Because later, it’s never just a window.

Software doesn’t break all at once, it wears down gradually. And it almost always starts with small compromises.

That’s all for now. See you in the next post. 👋🏻📚🧑🏻‍💻