The broken window principle applied to software
“Broken Windows” is one of the most cited articles in the history of criminology. The theory was first suggested in the early 1980s by a social scientist, George L. Kelling, in his article in the Atlantic.
It follows an experiment conducted by Standford’s psychologist Philip Zimbardo in 1969. Kelling explained the theory as follows:
“Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.
Or, in a more lightweight version:
“Consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.”
If you like the topic there is an entire literature on this subject; take a look at “Fixing Broken Windows”.
A 2019 study on this topic, revealed that the survey can be unreliable because people’s perception of the disorder in their neighborhoods may be intertwined with their assessments of crime as well as how they describe their own mental or physical health.
In fact, he says that policing and public health strategies shouldn’t be based on the idea that disorder causes people to break the law or participate in dangerous or unhealthy behavior.
However, that disorder, if studied in a more precise way, can provide valuable insight into what’s happening in neighborhoods and inform public policy.
An insanely detail-oriented activity
Software Design is an insanely detail-oriented activity; while a broken window does not necessarily mean stolen wheels in a nearby car, the relationship between different components in software can be much much tighter.
When your team is not on top of the details, the general perception is that things are out of control, and it’s only a matter of time before your project spins out of control and everyone stops caring about maintenance & evolution.
If you’ve been following me for some time, you will know already that I do not believe in perfectionism, especially in software design. No project is going to be perfect: in a highly mutable environment with constantly changing constraints you just can’t define a bullet points list with must-have conditions for perfection. Nick Gracilla explained this concept with a beautiful quote:
Great software architecture is like great plumbing — but for a house, that’s constantly changing
Great software architecture is adaptable; it can handle the constant change businesses place on software and is ready for future iterations and the problem definition changes.
OK, wait, wait. Let’s just back off for one second. What’s the “broken windows” theory in software design?
No one starts with bad intents
No one starts a project with the intent of making a bad job. In the beginning, principles, practices, and laws are of primary interest, even if putting them into practice might prove difficult (it also depend on team skills)
Suddenly a “window” is broken.
It may happen to high pressure to deliver or just a lack of knowledge.
People often make mistakes, even senior people. Especially senior people (“Your ego is your soul’s worst enemy” ~ Rusty Eric). But Broken windows are not just a matter of mistakes; requirements often change and you may need to make small or big changes to follow the intents at the bests.
It’s only normal.
Here there is a sliding door.
If no measures are taken technical debt starts spreading and more “windows get broken”: issues propagate in the code through imitation (“I’ve just copied that” approach), repetition (a broken assumption), or just a copy+paste.
The resulting system manifests rigidity, fragility, immobility, and lower resilience over changes. Each new change comes with a high cost, an increment of changed parts, and therefore a high risk of failure.
What Broken Window Theory Suggests
When bad behavior is not corrected immediately, it just shows people that there is no downside to breaking the rules, practices, or standards.
The absence of any negative outcome spreads the intrinsic perception of the disorder; cutting the corners becomes acceptable and quality starts decreasing.
While the problem might be complex to approach the solutions are simple:
- Carry the healthy approach in your team — Senior people wanna desperately demonstrate their strengths (I’m a f*ing 10x engineer baby!), junior people how much they can do. Rarely one, two, or three days more than the estimate means something. Instead, a calm and focused approach is what can save you and your team.
- Nothing comes for free — Everyone can rewrite software from the stretch; constant maintenance and evolution are far more difficult and show how you and your team are good at software design. Refactoring — like debugging — is an insightful activity to show the strengths of any developer.