The Broken Windows Theory: The Key to Tackling Software Entropy
This year marks the 25th anniversary of one of my favorite development books, The Pragmatic Programmer. To commemorate the occasion, I thought I would share summaries of some of my favorite pragmatisms throughout the year, starting with this one: the “broken windows” theory.
Software development is a unique field where the laws of physics might not apply, but the concept of entropy still looms large. In physics, entropy refers to the degree of disorder in a system, and in software, this disorder is often referred to as “software decay.” I talked about software decay this past year at Community Summit NA, but this blog will delve into the idea of software entropy, inspired by the broken windows theory, and discuss how understanding and managing this entropy can be the key to maintaining the health and longevity of software projects.
About the broken windows theory—and how it applies to software development
The broken windows theory, originally rooted in the field of crime and urban decay, is a powerful analogy that can be applied to software development. The theory suggests that the presence of a single broken window in a building, left unrepaired for an extended period, triggers a sense of abandonment among inhabitants.
This feeling of neglect then encourages further vandalism, littering, and serious structural damage. Inevitably, the building reaches a point where its owner is no longer willing to invest in repairs, and the building is left to decay.
This same principle can be applied to software development, where a single “broken window”—which can be a bad design, a poor code choice, or a flawed decision—can instill a sense of neglect among the development team. Over time, this neglect leads to a degradation of the software’s quality and maintainability.
Don’t leave windows broken, don’t leave software issues unaddressed
The most crucial lesson from the broken window theory in the context of software development is simple: don’t leave broken windows unrepaired. Whenever you encounter an issue, be it a bad design, incorrect decision, or poor code, address it immediately.
If time constraints prevent a full repair, take action to prevent further damage; board the window up. This could be anything from commenting out the code to throwing an error when it is used. The key is to show that you’re attentive to the situation and committed to maintaining software quality.
Maintain a high standard
Neglect is the most significant accelerator of software decay. Clean, functional systems can deteriorate rapidly once broken windows start accumulating. While there might be other factors contributing to software entropy, neglect takes the lead in speeding up the decline of software projects.
Developers should aim for a high standard. In projects with well-designed, clean, elegant code, the team is more likely to be cautious and strive to maintain the existing quality. However, if you find yourself in a project with several broken windows, it’s easy to fall into the mindset of “All the rest of this code is bad, but it’s better to be consistent, so I’ll follow suit.” To prevent this mindset from taking root, prioritize addressing broken windows and maintaining a high standard of code quality. A self-code review every time you merge your code is the best place to start, as long as you’re honest with yourself about what you’re looking at.
Tackling software entropy is difficult when building custom applications. While customers may have the same quality expectations from those applications as they would from ones created by an ISV, it can be difficult to absorb the cost of such efforts. A true software product can distribute costs over hundreds or thousands of customers, while the cost of a custom application is born by just one. This is why it is so important to set proper quality expectations on both sides at the beginning of any customer/partner relationship.
Fixing windows: Small choices and actions that keep entropy at bay
Software entropy is a real challenge in software development, and the broken window theory offers valuable insights into how to manage it. By promptly fixing broken windows and maintaining high standards of code quality, software projects can defy the natural tendency toward disorder and decay. In the end, the small actions and choices make a significant difference in a software project’s long-term health and success. So, don’t let entropy win; prioritize maintaining a clean, functional codebase!
Join a team that never leaves a broken window
At ArcherPoint, our Core Values reflect this commitment to quality. Two of our values speak directly to how we treat our code and solutions: We Delight Clients with Amazing Work that they are happy to pay for and rave about to others, and we are Learning and Always Challenging ourselves to build a better business and helping our clients to do the same.
If this sounds like you and you are looking for a career with a company you can be proud to work for check out our job opportunities. Don’t see an opening for your skillset? Contact us anyway–we always want to talk to good talent!