Preventing Broken Windows

09 January 2018

Photo: Unsplash

Broken windows can cause big issues to occur and ruin communities. The original theory has is rooted in academia and was proposed by James Q. Wilson and George Kelling in 1982. The theory used broken windows as a metaphor for disorder within neighbourhoods. It links disorder and incivility within a community to occurrences of serious crime.

It stated that when a window in a building is broken it impacts peoples view of the building. When left for a long period of time it impacts the way community thought and cared about the building. It reflected a sense of abandonment. This would be reflected by another window being broken or structural damage occurring. Over time the building would fall in to complete disarray. It would lead to it eventually being abandoned.

The Pragmatic Programmer book is a classic within software development. Within the book, it highlighted the similarity with software entropy. They likened the avoidance of fixing small issues within a project to that of broken windows. They highlighted the psychological impact that ignoring small issues had. It affected both on the codebase and the culture of the project team. As they said:

neglect accelerates the rot faster than any other factor.

I was discussing this theory with our new Head of Product at Open Energy Market. In refining our development process he suggested that we have a day a month where we fix the broken windows.

I disagreed. I suggested that it was a bad idea for the following reasons:

• We push out 2 releases a month a present. That means we are happy for a Broken Window to be on show for 6 weeks on average. From a users point of view, that’s not acceptable.

• The development team culture would change. Developers would be happy to take shortcuts based on time constraints. They would know they could fix any issues on the Broken Window day. This would change the culture of the team and breed laziness and low standards. It could also impact the standard of code reviews.

• Broken Window day will not always happen. Experience tells me that out of a possible 12 Broken Window days in a year, 8 - 10 will be missed. This is not on purpose or because the development team do not want to take part in them. It is because they will get pushed due to targets and commitments. Even if we did complete 12 days there is a high chance of not all developers having the capacity to take part.

• Would we have the capacity to complete all the identified Broken Windows each month? If not do we roll the issues over to the next month or increase the number of days assigned to these issues?

There is another theory/rule in software development that can prevent broken windows. It is the Boy Scout rule which is outlined here.

(Note, I am quoting the original fairly dated rule. Boy Scout should be replaced with Girl Guide where appropriate.)

The rule states that you should “Leave Things BETTER than you found them”. That as you work on code you should perform maintenance and opportunistic refactoring as you go. This means that if you notice badly written code, missing tests or architectural design flaws you correct them. You may not have written the code but you fix it as part of your responsibility as a developer on the project. Every time you commit, you leave the code that was there in a better state But, the approach to be taken is towards betterment not to perfection.

This is an important definition for a team to make and include in their process. What are maintenance and opportunistic refactoring’s which can be done as part of a story? When does it move into a larger piece of work and how do you track it? These are important questions that should be decided by your team. The key thing is to ensure that any non-trivial Boy Scout tasks are added to your backlog and prioritised as tasks. If you do not have time to fix an issue as part of day to day work do not ignore it. Log it, prioritise it and resolve it.

Technical debt and small issues will always appear in any project. Instilling the Boy Scout rule as a core part of your development team’s culture will help to prevent Broken Windows.

If you have any comments or would like to discuss this topic further then please message me via twitter or email.