I was still studying software engineering when I got in contact with the Broken Window Theory. Although I can’t remember when I heard about it for the first time, it made a lasting impression on me. The theory comes from an experiment that was executed in the late 60s, of which you will find all about in a great article that NPR put together.
In short, researchers placed two cars, stripped from their license plates, in two different areas: the first one in a problematic neighborhood of New York, and the second one in a rich neighborhood of the state of California. The first car was vandalized within a few minutes after being abandoned, while the second one was left alone for a few days. The researchers then decided to break a window in the second car. A few minutes later, someone started stealing the car’s parts, and it quickly became as destroyed as the first one.
Recently, I shared this story with a colleague of mine during a coffee break. A few days later, he told me that he’s now applying this philosophy to his coding and code review style. This was music to my ears, as this is something that I’m always trying to pass to the teams that I work with.
Let's take a look at the following piece of code, found in a codebase that I've picked up and currently am working with.
The goal is not to look into the reasons of how and why we ended up with such an overcomplicated solution, but rather to put ourselves in the shoes of the developer that was asked to change something in it.
Now, ask yourself the following questions:
An honest answer will point to no on both questions. Overcomplex code is something that we, developers, are used to find. We know by heart that it takes time to understand and change the code.
Now let's look at a refactored version of the previous code, and ask the same two questions.
Changing this piece of code is, by far, easier than changing the previous one. And contrary to what usually runs through a developer's mind, when deadlines are tight, keeping the codebase small and well-organized helps.
We often don't think about how keeping the code in good shape sets the bar for others working on the project. But a project with a well-written code will motivate everyone to mimic the behavior, follow the conventions and deliver code with similar quality. If there are no broken windows on the project, people will be less tempted to break one.
The good thing about nurturing an unbroken window behavior is that, ultimately, it will propagate through the entire software development team, and impact all projects in the company. Hopefully, this will also work as a sign to other departments, and the philosophy gets adopted outside the realm of the company’s codebase.
The broken window experience comes to my mind every now and then, as it exemplifies the importance that minor behaviors have on avoiding problems from scaling and ultimately systems from falling into chaos. It is one of the rules that it's worth living by.
Found this article interesting? You might like these ones too!
CEO @ Imaginary Cloud and co-author of the Product Design Process book. I enjoy food, wine, and Krav Maga (not necessarily in this order).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
