The Broken Windows theory was developed in 1982 in the US in the area of crime prevention. The theory describes norm-setting effects of urban disorder. Simply put, it means that if the windows of a building are broken the likelihood of further broken windows increases. This is a metaphor to stress that environmental and cultural settings have a huge impact on the behavior and norms of people.
For instance, if one window is already broken and nobody cares about it, it seems to be acceptable to break other windows as well. Broken windows encourage people to break windows. If all the windows of a building are intact, the inhibition threshold to break windows is much higher. Although the theory was developed in the domain of criminology, it can also be applied in software development projects. I am sure everyone working in IT already knows about broken windows.
Examples of broken windows on a technical level are:
- Unfixed bugs, e.g. a wrong calculation
- Violating integrity rules, e.g. microservice design principles
- Not using ubiquitous language but lots of synonyms and technical slang instead, making it hard to understand the codebase
As broken windows produce more broken windows over time the software might become harder and harder to maintain which sometimes requires a complete rewrite after a few years.
How can broken windows at the technical level be fixed and avoided?
One way is to understand that not just functional misbehavior in applications, e.g. the inability to save customer data, is treated as an error. Violating design principles and coding conventions should also be treated as errors which have to be fixed as soon as possible. These errors are usually not detected by functional testers but by developers themselves and their colleagues. If a developer spots a violation, he/she should create an issue in the bug tracking system. Over time the code quality increases and broken windows are repaired. A culture of constructive criticism helps to foster this.
At the level of agile methods examples are:
- People not attending standup meetings
- Teams not delivering what they promised during sprint planning
- Team members working on unplanned things
Over time the development process might deteriorate and create fewer and fewer predictable outcomes.
What can we do to prevent that?
It is important to address misbehavior when it happens. Do not wait until it becomes normal and is replicated by other team members. Just like a scrum master teaches the team the value of the scrum principles and artefacts and guides them on their way to an agile mindset. Mature agile teams are able to address broken windows for instance during their retrospectives.
People in software development teams are prone to the broken window effect as they do not work in isolation. They align their behavior to the accepted principles of the group. If the group includes bad role models and shows misbehavior or a bad coding style (both are broken windows) the team is likely to follow. After a while the code smells and bad habits become normal (although it doesn’t smell anymore ;-)). Broken windows produce more broken windows even when they don’t produce any immediate problems. Therefore, it is important to fix them as soon as possible. If not, the likelihood of code- or team-erosion increases. If broken windows are fixed on time, the teams and codebase can maintain a high level of quality which is required to deliver software quickly and reliably.