Broken windows theory: why code quality and simplistic design are non-negotiable

A friend once told me about an experiment where someone left a new car in the street — it remained there untouched for a week.

They repeated the experiment again, but this time they made a deliberate crack in the windscreen of the car, and within a few days, the car was completely burnt out.

The broken windows theory is a criminological theory that visible signs of crime, anti-social behavior, and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes. The theory suggests that policing methods that target minor crimes such as vandalism, public drinking, and fare evasion help to create an atmosphere of order and lawfulness, thereby preventing more serious crimes. — Wikipedia

Each person who damaged the car didn’t really change the state of it very much. The window was already cracked, so somebody just added another crack; no big deal. Compare this to making the first crack in an otherwise pristine car — the difference is significant.

Later, somebody else comes along and does some other small amount of damage to the already-damaged car, and so on until it is a wreck.

If we think about the Broken windows theory when it comes to code and software design, it’s clear that there is great value in the cost of maintaining quality.

If you work on a project that has flaky tests, then you’re more likely to add more flaky tests. If there is a hacky design, you’re more likely to hack more in. If there is a package called utils, you’re more likely to stick more utilities in there. If one of your HTTP handlers uses a global variable for some state, why wouldn’t yours? If anything, we’re taught that our projects should be self-similar and consistent — so maybe we’re even doing the right thing?

Each person who contributes to this mess isn’t really changing the system much, but they are headed towards a fire.

Like in the criminology theory, policing the small stuff and taking the time to keep the quality of your projects high ought to be one the highest priorities of the team. This can include refactoring, developer documentation, good and clear Makefiles, simple package layout, good quality test code, and more. None of these things should be overdone, they should be as simple as they can be (but no simpler, right Einstein?).

Isn’t perfection the enemy of progress?

No project is going to be perfect, and there will always be things we’re not happy with as a team but that “just aren’t worth fixing.” It’s important to be honest (and positive) about this fact. Complaining might be good therapy for developers, but a team deciding to leave something the way it is for the sake of progress is a respectable position to take; and should be a positive experience and an excuse for learning.

Limiting scope is a great way to ensure teams have the time they need to get the important stuff right and this needs to be understood across the entire company (not just the dev team). Maybe our software doesn’t do everything, but what it does do, it does well.

Conclusion

Remember the Broken window theory when you next mark a ticket as ‘done’. Have you just made the first crack in an otherwise pristine window? If so, get some help from the team and take a little more time to refactor it until you’re happy that it meets your standards.

When reviewing code, police the small stuff. Pay attention to the implied decisions and make sure you’re happy with the decisions (overt or otherwise) that are being taken along the way.

References

• Broken windows theory on Wikipedia https://en.wikipedia.org/wiki/Broken_windows_theory
• https://blog.codinghorror.com/the-broken-window-theory/