And no, it has nothing to do with Windows, the operating system. The “broken windows theory” came to popularity with criminologyist George L. Kelling’s 1996 book Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities.

The premise is fairly simple: in a building of a random neighbourhood, let’s call it Javaville, lies a broken window. The authorities at Javaville are too busy micromanaging and doing 7 standups a day to care about the window, but hey, it’s just a window, nothing major. So the window remains broken for a day, a week, a month, and while it’s addressed as a problem, nobody is doing anything about it yet. Someone with a habit of messing stuff up for fun sees the un-repaired window for enough time to realize that, if nobody cares enough to fix that lone window, then they won’t care to fix two of them. So what do they do? They go and break another window.

Eventually, the building gets all of its windows broken, and so people on their daily commutes begin avoiding it, as its abandoned state has invited the worst kinds of criminals to frequent it. The neighbourhood gets more isolated, since its inhabitants would rather stay inside than go near the building. This causes the building to come even closer to becoming unsalvageable.

The whole situation is a metaphor for how signs of abandonment in a city, a company or a project can provoke malicious agents to cause even more harm. If the window had been fixed from the start, presumed “window-breakers” would see that the building’s pristine state means that Javaville is well-maintained and therefore well-defended against attacks, and so they would leave their vandalism for another town.

So how does this translate to software development? Pretend the “window-breakers” are bugs, not critical bugs that halt production entirely and must be dealt with immediately, but rather “harmless” bugs that are left to deal with later, as soon as somebody gets free time. Even though bugs do not have a mind of their own and thus do not “mean” to cause harm, there can be harm caused by the programmer’s failure at fixing them. A project that is full of unresolved issues and bugs being reported for months on end, without updates, is saying to all the developers involved, “Don’t worry about fixing your bugs, this is already a huge mess anyway. Just keep coding”.

Because debugging is such a time-consuming process, developers that are being rushed for speedy releases by clueless management or insistent clients will certainly look at a project like that and keep piling up more and more work over the pile of bugs, which will keep growing until a point where it’s so big that it gets labeled as the “dirty work” which absolutely nobody wants to do. Whoever gets assigned to deal with it will certainly not be happy to, which translates to lesser productivity. Additionally, any given bug might seem irrelevant at first, then become a huge pain at the most unexpected moment, causing delays and inconveniences that could have been avoided.

How to avoid the broken windows

Do not leave small bugs unaddressed. This does not mean that the entire project should be left on standby until every bug is solved, but at least there should be updates on them. Any suspected causes must be written down and investigated. Internal comments are a must. Devs must feel that there’s constant work being done on solving every bug, so that nobody feels entitled to slacking off on the dirty work. It’s part of the game. 

Value teams that care about their code

At DevRoom, our main value is commitment to quality. Our developers know very well that not a single line of code is to be neglected, and the inevitable bugs, issues and warnings that arise over the lifetime of a project are carefully addressed and documented. From every completed project, we learn to deal with these universal problems so every new client gets better results each time.

Need help getting rid of bugs and spaghetti code? You are in the right place. Book a call with us today.