Theory Thursday: Broken Windows

The Principle

Originally stemming from a criminology and urban management concept, the “broken windows” theory suggests that visible signs of neglect (such as broken window panes that go unrepaired), encourages further neglect.

The underlying principle here is that people’s behaviour often aligns with the environment around them. If the environment is neglected or falls below a certain standard, the individuals are more inclined to lower their own standards and contribute further to the decay they are witnessing.

Moving this analogy quickly into a software development context, one can easily translate this into something like “a hacked together solution will encourage further hacks without care for quality architecture and engineering practices”. As such, engineers will feel less compelled to maintain their meticulous attention to detail when they see code that has been cobbled together, dead code, incorrect comments and obvious bugs. In contrast, a clean, well-maintained solution will encourage engineers to continue with a sense of ownership that fosters well-structured, clean solutions.

Therefore leaving small bugs in place, having messy code or leaving code smells unaddressed will only lead to a gradual decline in the overall quality of the codebase. I see it similar to someone who might own a cheap runaround car that is full of chipped paint and dents to the bodywork - they are less inclined to treat it with the same level of respect as they would with a brand new one.

Where technical debt fits in

If you don’t know what I mean by technical debt, take a look at my article where I explore what technical debt is, as well as how it can be used to provide competitive advantage.

Continuing with the idea of the “broken window”, the decay and lack of willingness to improve the situation only leads to further issues. This is exactly what happens with technical debt - it gains interest (in a metaphorical sense) which only compounds over time and makes things harder and more costly to change.

Fixing the broken window

To prevent further decay and other broken panes of glass, it’s important to level-up the standards and encourage others to do the same. Within a software context, this can be achieved through a number of different means which are entirely dependent on the shape, size and maturity of the teams you work within. However, there should be at least one thing you can take from this list and ensure the standards are raised and there’s no more broken glass:

Code Reviews

Not all team perform code reviews, especially when pair or mob programming is in place, but it can still be a useful tool. The review sessions make it easier to prevent smaller issues slipping through the net, helping maintain standards as everybody understands their responsibility to write clean code, as well as help others do so as well.

Linters & Automated Checks

Linters and other automated tools can significantly remove the overhead when it comes to formatting problems, style consistencies and security issues. Such checks provide continuous evaluation of the codebase and help keep the windows “unbroken”.

If you are enjoying reading this post, please head over to my Substack article where you can take off right where you left.