Always be Fixing Broken Windows

This article was originally posted on LinkedIn. I am re-publishing it here for a wider audience.

Broken windows theory says that if a single window in a building is kept broken for a long time, the remaining windows will be broken soon. This happens because those breaking subsequent windows get the impression that the broken window is fine and nobody cares if more windows are broken.

We can apply the same theory in other domains. Bad habits, if ignored when they are small will result in terrible lifestyles. In the programming world, if you apply some nasty hack, no matter how much you justify it, becomes the first broken window. Next time someone looks at your patch, they think broken windows are fine and they continue breaking one more window. This behavior keeps growing and we see more and more windows breaking until the whole codebase is ruined.

I've had the first-hand experience of seeing the team celebrating the re-write of the feature module. Unfortunately, after the team was split, there was no one to guard against hacks and terrible patchwork going into future releases. Not to mention, the code deteriorated within a year. I took a serious lesson from this experience.

When my team finished the rewrite of the critical app feature, we took the extra time to document our process, best practices, design decisions, and coding conventions. Besides this passive approach, we also enforced comprehensive testing and strict code reviews. The review process was designed to include our team any time the feature was changed and everyone familiar with the module invested a good chunk of time reviewing the change before it got shipped. We also educated other teams on writing safe and maintainable code so that they could learn from our lessons.

Refactoring a code or writing a brand new feature is only half the battle. Safeguarding it against bad practices and maintaining the quality in the long term is a challenging task.

How can you achieve the same thing? Next time you are tempted to add a hacky code or someone else pushes you to write unsafe code because the deadline is getting close, think about how it can bite you or someone else in the future. Think about hundreds of such hacks in the repository, potentially poor customer reviews, and dropped revenue. Think about long-term damage instead of a short-term hack.

If you aren't sure about the proper solution, take your time, talk to your colleagues and get their feedback. Enforce and follow strict code review guidelines. If someone suggests a better approach during the code review, think about how you can incorporate it into your code.

If you are still not convinced, think about spending all your energy, skills, time, and resources into making something better only to see it deteriorate over time for a lack of safeguards and concerns over the quality.