Software Development and the Broken Windows Theory

There is a theory called the “Broken Windows Theory“. This theory states that if there is a disorder in a neighbourhood for a substantial period of time, the mess will only get worse. The authors give the example of a broken window in an abandoned building. If it isn’t replaced within some time, the chances are that vandals will break another window. And another. Gradually making the mess worse, and therefore making the issue bigger.

How the broken windows theory relates to software development

This theory applies to quality in software development as well. Over time the quality of our software may decrease for a variety of reasons. For instance, when under the pressure of a deadline we tend to do concessions to the quality of our software. Or when some tests fail, and no-one acts, it doesn’t motivate to write good tests and more tests will fail over time. Effectively making the testsuite useless. This disorder is also known as technical debt.

How it works

The mechanic about this effect is that you unconsciously and gradually lower the norm of quality of your software. This is of course not what you want for your customer. But also for your team.
Not responding to the “broken windows” in your project will effectively change the mindset about quality, and it leads to passive/reactive behaviour. Do you know that feeling that you’re constantly running into problems with existing code? Then you might have had some broken windows for too long!

Fix the windows!

The broken windows theory in full effect
©2012 iStockphoto

The solution that the broken windows theory describes is to actively monitor and report any disorder like a broken window, litter, holes in the road, or graffiti. In software development their equals would be poor code, bugs, failing tests, or bad design implementations.

The key to success is to maintain a zero tolerance policy on technical debt. And to clean up the list of disorders within a timely fashion.
Of course, you and your team have to decide on what you consider technical debt within the project. This will usually be affected by customer expectations and/or budget. But make sure you all agree on what the quality standard is. Otherwise maintaining a zero tolerance policy will be ineffective, and may cause frustration.

It’s in your hands

Implementing this strategy is something you can start doing today. If you start pointing out and act to the so-called technical debt, you will soon start a movement within your team. You will create awareness and team members will follow your example. Social control on the subject will grow, which encourages to stick to the set quality standards.

Ultimately leading to a better product, happy teams, and happy customers!

  • Lineke

    Great addition to my article on Quality Management and how to implement that in your organisation. Really good read, Richard!

    • Thank you Lineke! I’d like to read your article about Quality Management, where can i find it?

      • Lineke

        Sorry, forgot to mention that it is a phparchitect article.

        • Lineke

          In the 2012 may issue

          • Thanks for pointing out! I am not sure how i missed that one.. Putting it on the to-read list!

  • Pingback: Broken-Windows-Theorie « Lars Reineke()

  • Tobias Blickle

    Good point you made. I totally agree! This is a philosphy I try to follow for years and also put together some of my thoughts on broken windows and beyond: