The Broken Window Theory

The Broken Window Theory is a theory that states that visible signs of disorderly behavior create an urban environment that encourages further disorders and misbehavior, and often lead to serious deterioration of safety and security in localities. This theory comes from studies in crime and was developed to explain the decay of neighborhoods but have been applied to model certain behaviors in work and educational environments as well.

Defined in 1982 by Wilson and Kelling, this theory argues that no matter how rich or poor a neighborhood, one broken window would soon lead to many more windows being broken: “One unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing.” They said. And similarly, an initiative to repair abandoned properties and transform vacant lots into community parks do see positive impact in reducing the rate of crime and disorderly behavior.

There are ample articles (Google Search returns 110 Million plus results!) available in the internet today, applying this theory in various fields ranging from sociology to economics and of course to software development.

I personally came across this in mid-2000’s and was very much moved, almost at an emotional level, by how parallels were drawn between a decaying neighborhood and decaying software systems – systems which over time become buggy, unstable, unreliable and inflexible.  Very much my following years in software engineering were shaped by some of the learnings that I took from this study.

One of the earliest blogs on this topic I read, is on a website called codinghorror.com and to pull out an excerpt as is, it says:

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

To elaborate more, here is a diagram (source: medium.com) that explains the perils of a broken window with examples we can relate to easily:

 

 

So, what can we do?

Like Kelling et. al. introduced in their book “Fixing Broken Windows”, taking small corrective actions in time can reduce the speed of decay, prevent bigger decays from manifesting eventually and may actually reverse the phenomenon in positive direction by many times. This is something we need to think about and practice. To summarize, I end with a quote from this blogpost:

… remember the Broken window theory when you next mark a ticket as ‘done’. Have you just made the first crack in an otherwise pristine window? If so, get some help from the team and take a little more time to refactor it until you’re happy that it meets your standards. When reviewing code, police the small stuff. Pay attention to the implied decisions and make sure you’re happy with the decisions (overt or otherwise) that are being taken along the way…

You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you'd better plan on getting a dumpster…. Show you care, so others will care.  

Don't let entropy win!

 

Acknowledgements and sources as mentioned above