The Link Between Software And Broken Windows
The most significant accelerator of software degradation is the team’s working culture. Even minor flaws in a project’s code base can cause the working culture to deteriorate and hence drive software degradation.
This blog post is about the link between software and broken windows (no, not the operating system – literally a window, you know, the sort of window you can look out of) and what this link means for us as software developers.
- Software Degradation
- Broken Windows And Their Effects
- Changes In Working Culture
- It’s Good To Fight Degradation, But…
- … Do So Reasonably!
- Broken Windows And The Boy Scout Rule
- Wrap-Up: Degradation Is Bad, Mkay?
Software Degradation
The thing about software is that it usually degrades over time, and you’ve probably seen this happen yourself. There are multiple factors contributing to this, and not all of them are in the developers’ circle of influence: arbitrary management deadlines, shifting requirements, feature creep, and the occasional broken coffee machine are things we normally can’t control. Fortunately, though, the most important factor driving software degradation is one we as developers can actually influence: the working culture within the project.
Some projects are laid out very nicely, they have great support from management, there’s a good and regular feedback loop to the clients, the team is awesome (and has plentiful coffee supply), and yet, interestingly, the project still fails. On the other hand, there are projects that, despite tremendous challenges along the way, end up being successful. The thing that separates the former from the latter is the project’s working culture. What precisely is a project’s working culture influenced by?
Broken Windows And Their Effects
In 1969, a chap called Philip Zimbardo conducted an experiment where he left two cars with torn registration plates and open bonnets in the streets of two neighborhoods, one in the Bronx in New York (which, at the time, was a rather poor, run-down neighborhood with high crime rates) and the other one in Palo Alto, California (pretty much the contrary of the Bronx in terms of wealth and crime rates). The car left in the Bronx was further vandalized and stripped of reusable parts within minutes. In Palo Alto, the car was left untouched for a week (except a worried citizen came and closed the bonnet) and it was only after Zimbardo himself had smashed one of the car’s windows that it had to suffer the same fate as its Bronx-located counterpart. Based on those observations, James Q. Wilson and George Kelling proposed a theory in 1982 hypothesizing that serious crime is the result of a chain of minor crimes. Remarkably, as shown by the 1969 experiment, the process of decay can be triggered by a relatively minor thing regardless of the community surrounding it – even respectable and law-abiding citizens will eventually be affected by the sense of abandonment even a small thing like a broken car window creates. How do those findings relate to software projects?
Changes In Working Culture
Imagine you’re being onboarded to a new project and you see its source code for the very first time. You discover its pristinely written and has been nicely structured into smart abstraction layers – no broken windows in sight anywhere. This creates a sense of order, and consequently, you pay extra attention not to mess anything up. Working on that code base will eventually create a feeling of ownership and responsibility, further contributing to your commitment to keep everything nice and clean (and look out for others to do the same). This process will repeat with new colleagues being onboarded to the project, resulting in a team of developers who really look out for their code.
This can also work in the other direction: If there’s one “broken window” in the code – a badly designed algorithm, an untested function, some clunky abstraction layers –, it will create a sense of disorder and abandonment. This is where the process of degradation starts, and very soon, another broken window will appear, and then another one, and the feeling of abandonment will spread in the entire team. Soon, after a few bugs have manifested themselves as a logical consequence of all the broken windows, developers will find themselves in the Just keep this thing alive mode. The working culture has decayed to the point where no one on the team cares about doing things the right way anymore.
The nasty thing is that this downturn in working culture could happen in any team of developers and on any project, no matter how good and beautiful the code was until this point. All it takes is a single broken window.
It’s Good To Fight Degradation, But…
This has very real implications for us as developers. To prevent broken windows, we have to constantly monitor ourselves and make sure every change we commit to the code is reasonable, well-designed, backed up by good tests and fits nicely into existing abstraction layers. If there’s already a couple of broken windows in there, we have to fix them as soon as possible – maybe even ask management for a certain time frame explicitly dedicated to that purpose –, and if there’s no time fixing them, then at least tape them up (comment out the offending pieces of code, deliver a Not Implemented message to clients, fill in some dummy data instead of querying the service that would otherwise provide the data, and so on). The important thing is we take at least some action to make our neighborhood just a tad nicer and cleaner.
… Do So Reasonably!
Fixing one broken window should never break another, and applying a fix should never result in any collateral damage. If the only way to fix a broken window is to apply some really ugly hack because there’s maybe a deadline approaching fast, then it’s probably not the right time to fix that window – the collateral damage is not worth it. In this case, maybe it’s sufficient to just tape it up and create a new ticket in the team’s backlog so the broken window is not forgotten.
Broken Windows And The Boy Scout Rule
In software engineering, the boy scout rule simply states that you should always leave your code better than you found it. Both this rule and our thoughts on broken windows dictate that something be done about a broken window immediately. But the boy scout rule is more than that: While fixing a broken window means a bad piece of code gets replaced by a better one, the boy scout rule can mean replacing a piece of code that was already pretty good with an even better one. Therefore, it serves as an enabler for a positive evolution of a project’s code base. This means even in a pristinely beautiful code base, the boy scout rule should be continuously applied to make it even better.
Wrap-Up: Degradation Is Bad, Mkay?
In urban areas, a single element of disorder, such as a broken window, instills in its inhabitants a feeling of abandonment, causing them to stop caring about the neighborhood and starting a downward spiral of degradation. The very same effect applies to us as developers – our neighborhood being the code base we work on –, so we have to do everything we can to prevent this degradation.
Don’t ever let a single window break, and if you discover a window being already broken, then do something about it immediately, but without causing collateral damage. As soon as the code base is free of broken windows, keep applying the boy scout rule to engage in a positive evolution of the code base. Don’t let degradation win!
