Broken windows

In software engineering, we can apply a lot of the psychology findings to their digital counter part. If we consider the broken window theory, it doesn't apply to the operating system, but to the state of code.

Let's go back to the source. From an article originating from 1982 ("Broken Windows") in The Atlantic by James Wilson and George Kelling.

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 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.

So what does it mean if we apply this to software? It's all about maintenance and sanitation, just as with the brick and mortar counterparts.

It you're working on software, I encourage you to use linters, formatters and have guidelines in place about the minimum level of acceptable quality. These measures in general help with maintainability of code. Especially maintenance over time. And that last bit, over time, is where the broken window theory can be applied.

Consider your codebase. We can safely say that it will continue to grow and expand over time. This usually follows the growth of a business or the role that IT takes in a business model.

We've all been there, finishing a user story just before a deadline. Applying a quick fix to solve an immediate issue. While it may be tempting sometimes to throw in a patch to revolve an immediate requirement or soothe a tenacious product owner. That first patch is your first broken window. You need to fix it, because it spells rapid deterioration of quality, according to the broken window theory.

If you've introduced that first step, it may be tempting to, when in a hurry, apply a similar method. If you haven't taken the effort to fix your first window, you are now introducing more and more broken windows. Bear in mind that these windows are not visible to anyone else but people touching the code.

That's what makes them dangerous. For stakeholders it may not be clear what the state is and whether windows need patching. If you're responsible for the code, you're responsible for maintenance and you should allocate budget to fix your windows as soon as they break.

The automated linting, formatting, coverage and complexity rules help you with maintenance. Ideally they shouldn't allow a broken window to happen. In practice though, you need to break a window yourself in order to gain entry quickly. That's okay! It happens. But, as in real life, you should immediately take action to fix that window as soon as possible.

I've found that the broken window analogy translates really well to non technical stakeholders, because it's very easy to understand.

Maintenance is important and takes time and effort for the physical as well as the digital space. Let's make sure to keep those windows whole!