I’ve been reading the Pragmatic Programmer. Like, two pages at a time. Because, it’s dense. Just several pages in, I was captivated by the use of a theory I encountered during my experience working in the built environment.
The broken windows theory is a criminological theory that states that visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes.
Source: Wikipedia: https://en.wikipedia.org/wiki/Broken_windows_theory
Abstract this theory into non-physical structures, systems, and processes, and the analogies are easily found. I’ve seen this and experienced it in systems, processes, and relationships.
Small acts of disorder cause decay.
Of course, this theory has been widely discussed and widely used. And, of course, there are issues with this theory and criticisms of the research methodology.
The intent of this post is to present this theory in the context of its usefulness and applicability for software engineering; I do not not intend to analyze the validity of the original research and I do not discuss the theory’s use in policing.
So what does the Pragmatic Programmer have to say about broken windows and software engineering?
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. 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, or moving to another neighborhood.
Hunt, Andrew. The Pragmatic Programmer . Pearson Education. Kindle Edition.
This theory has already impacted my own coding practices. Each time I feel impatient and want to skip over a potential issue in an effort to get on to shiny new things, I remember that each piece of code could become a broken window or part of a broken window.
Read more:
Chloe Tucker 