Broken Windows Theory in Software Development: Why Details Matter

While some problems in the software development world may seem inconsequential, they can have serious side effects and costs on people and society. This article offers a reflection and attempts to encourage change by having readers understand how their actions impact the environments they partake in and how even some little things end up costing fortunes.

Broken Windows

As a young lad, before my first computer, I was always on my bike. Across from my house, there was a little forest with a few narrow walking trails where I would cycle regularly.

I would often fantasise that my BMX bicycle was a Formula One and that I was competing with Nigel Mansell, Alain Prost or Ayrton Senna. Then, close to the finish line, I would perform supreme overtakings and take the narrow win.

At the further end of the forest, there was an old warehouse. It had small windows on the top close to the roof to allow the light in. Yet, those were high enough so that one could use them to peek inside.

I’ve never forgotten the first time I’ve paused to rest and contemplate the building. I recall thinking: “Odd! Why is it not near a road?... Someone threw stones and broke some windows… Why haven’t they been fixed? It looks mysterious, but gloomy. I better stay away, something feels off”. I would have then cycled away, and never ventured much into that area again.

Years went by and eventually the forest was cut through by a road and slowly, some new buildings sprouted alongside it. But for a while at least, the old warehouse endured. Yet, with each passing year, more windows were forced to give into the stones thrown at them.

To be fair, whomever broke the windows, wouldn’t have been haunted by remorse. Some were already broken and unfixed, so who would care about a few more? After all, the costs of replacement would be the same as they all needed mending.

As such, the old warehouse windows presented an opportunity to train one’s aim, and celebrate when the premature demolition assistance was successful (another window broke), as I have observed some older lads doing once.

For me and some other colleagues, the road allowed a shorter route to school. Nonetheless, we would all prefer the older and slightly longer route, because it was a known path and it allowed us to avoid the rundown building which made us feel oddly uneasy. It was something less to think or worry about.

I share this story, from a time before mobile phones, in an attempt to transport you to your own childhood, and try to scavenge out similar feelings you may have experienced as a child when observing a rundown building, or area, and to introduce the Broken Windows Theory.

In a nutshell, the broken windows theory suggests that environmental disorder encourages criminal, anti-social or civil disorder behaviour. No broken windows equal less likelihood for disorder, favouring peacefulness and lawfulness. As with the broken windows of the old warehouse, when there is already abundant disorder, it’s easier to pile more on.

I first came across the broken windows theory, many moons ago, while reading the Pragmatic Programmer. If you are new to the Software Development world, it’s a worthy read.

The broken windows theory wisdom often comes to my mind. Surely criminologists and behaviour experts would have a lot more to say regarding it, but for me, it’s an engraved illustration of how the environment influences human behaviour.

And while some more recent scholars claim that the theory no longer stands, even without reading their papers or claims, I would already challenge : “Apologies. I understand you are an expert, but in my experience it does stand”.

If you like the “Bing Bang” TV show, then you know that even experts can be wrong and get proven wrong even by friends.

I hope you understood that the broken windows in this old warehouse story, invited anti-social behaviour which would also lead passersby, as if guided by an automated premonition of trouble, to take steps away from it and to remove it from the mind.

Technology and crime

So that you don’t think I’m too old, permit me to use the TikTok Kia challenge as another example (which to be performed, may also include breaking the vehicle’s window).

If you aren’t familiar with it, it’s about a video shared on that platform that led to a series of motor vehicle thefts targeting Kia and Hyundai, mostly by teenagers, which resulted in damage to property, grief, loss of life and other nefarious consequences, all of which negative… excluding TikTok gains and further platform notoriety.

Being an intended or unfortunate design decision by those car manufacturers, it was nonetheless a system fragility, which was successfully exploited via a common USB cable.

The grown up, or at least the responsible thing to do, would have been to disclose said vulnerability to both brands and hope they would take steps to correct it. Of course, that would have meant that the authors of the video would very probably never become famous, nor would they have fun while doing it.

It is interesting to me that youth nowadays would rather be influencers, even if as ambassadors of evil, rather than firefighters, doctors or astronauts. Good job mass media! (my attempt at sarcasm for those that have a hard time getting sarcasm).

So in this example, we can acknowledge that even if unintentionally, a broken window (and a USB cable) can lead to more dramatic consequences than just shattered glass.

Both companies have since taken steps to attempt to minimise and tackle the criminal behaviour, or in other words, fix the broken window, but not before having suffered reputational damage and financial loss.

Software Development Design: The HTTP Referer Header Example

An example from the software world that has been a broken window for many years, is the HTTP Referer header, a misspelling of the word referrer. It has caused me problems, perhaps to you and to hundreds if not thousands of people also.

Like me, you probably jeered (make rude and mocking remarks, typically in a loud voice) at the authors too. You may also have searched for whose fault it was and potentially also concluded that, even after so many years, that the excuse of being too busy or that “I’ll eventually fix it”... is very human, as you have for sure heard similar reasoning before, for other broken windows.

Who cares about other people losing time when it is easy to teach that you need to do something wrong, because that’s the right way of doing it? Or, here’s a funny thought, why don’t we change the dictionary? Then it will no longer be a mistake.

A broken window, left unrepaired, leads to more broken windows, but if even the experts don’t care about those, why should the rest of us? Why not break more windows? Surely one day, all must be fixed.

Here’s a potential reason! It involves numbers, so easy to get wrong, but let’s give it a go.

Let’s use the average programmer salary in the USA in 2021 which was $93 000 according to this source. Let’s assume 40 hours a week and 52 working weeks to get the hourly value of $44.71 (Americans aren’t big on vacation breaks apparently).

Given that, In the USA alone, there are 4.3 million programmers according to this source. Even if we took only 5% of those (I've picked the value arbitrarily) we would get 215 000 programmers that have in some way or another, encountered the typo and had to take steps to understand and address it.

If each of those programmers would only lose an average of 1 hour, dealing with the side effects and understanding why it’s there in the first place, then the cost of their first encounter would have been 9.6 million dollars. If it was 30% (1 290 000 people) the value would be 57.7 million dollars. Again: USA only.

Even if you select another arbitrary percentage, the waste will still be immense.

And please mind that I’ve given no consideration that issues caught earlier in a development cycle cost significantly less than those caught in production. I’ve also not added inflation adjustments, nor considered different countries or students and professors that spend time addressing it, nor those of people that have websites and are not considered programmers, nor those that have retired, nor also, the ones that still have to learn it.

Now, extrapolate that value to include the world. How much money, how much value, how much life, do you believe has already been lost and will be lost?

I long for the day when a kind soul shares somewhere, “By the way, we fixed it and the old way will be deprecated in version X”. Because to me, unless the people responsible for the easy mistake are so despicable that they should be remembered for this typo, then the best time to fix it was yesterday. (Know someone at Apache Foundation or working with Nginx? Please! Nag them!)

“Begin with the end in mind”, that includes what you did or didn't do, for others.

Yet, this is just an example from the software world, not a unicorn, we have more.

Corporate Maturity and Broken Windows

It has been my experience that the higher the maturity, experience of stakeholders and the longevity of the software, the higher the likelihood of broken windows persisting for longer periods or never being addressed.

And no. I’m not standing behind nor even beside those that take satisfaction in releasing early and often, because it regularly translates into less quality and care. Knowing that you are releasing mostly broken windows, unthought complete features, is not about being Agile, it’s being sloppy.

And yes, I'm aware that many reasons will rise up and contradict the above statement, but I believe none of them will resist a change in the weather brought by a cyber adversary that decides to profit. More clearly: startup companies' codebases are regularly ripe for crime, in other words, are low hanging fruits for criminals to pick.

But regarding matured organisations, the strongest forces behind the reality of maturity hugging broken windows are the low return on investment and other pressing priorities dictating and enforcing the need for available resources' attention.

Also, established organisations are bound by regulations and compliance that restrict them from taking certain risks that if materialised, would have a broad societal impact. Which is also why those companies prefer to incubate startups, allowing them to attain certain niches, then wait until regulations and activities are more stable, before actually acquiring.

Society does not favour those that fail, we celebrate winners! So, it’s human to be defensive when doing mistakes or failing. We demand that everyone else, except us, never miss a penalty or a free kick for that matter. Also, programmers are definitely not kind to one another, but this is not a problem isolated to them.

So it’s not unexpected that a team, or an individual, responds with reasonings like: “it’s not really a bug”, “it’s not really a defect”, it was a design decision”, “we never thought it could be used like that”, “no one would ever do that”, “it doesn’t hurt anyone”, “it is working as intended”, etc.

And when broken windows don’t get fixed, at least any time soon anyway, in a humorous geeky fashion, programmers call them: “a feature”.

Sounds silly doesn’t it? Let’s see what may be going on.

If we sit back, comfortably, attempting to resist our own biases, perhaps more of us could observe the same: a bunch of humans that make a living problem solving, can surely and easily recognise broken windows. And because some won’t ever be fixed, individuals will look for ways to stop worrying and remove them from their minds’ backlog.

Because like so many other things in life that cannot be individually or directly controlled, those weigh on you if you continue to spend energy thinking about them.

Conclusion

When is it then, that this common behaviour that carries negativity and is undesirable becomes unacceptable? Is it only when people crash and death occurs?

If so, well, then there are some things that will never be fixed… let’s keep losing, or more accurately, let others continue to lose.

Between the shattering glass that affected only the warehouse owner, to vehicles owners, the people that robbed them, and lastly to other programmers, addressing the details, even if small, will make a difference.

I hope that the next time you do something wrong, you consider fixing it right away or allow the person that did it, to amend it.

And please stop littering because others do too.

And if those are experts, challenge them! They are human, they make mistakes and they may have not even noticed. If they react like dorks, respond: “you are welcome”.

If I had penalties to pay, for all the typos and other silly things I've done so far in my life…

But I always try to do one thing: fix them, once I'm aware of them. You should too!

Little things, they matter. And if not exactly them, what their presence signifies.