Practice1.No Broken Windows

Practice 1. No "Broken Windows"

This practice could also be thought of as "no hacks or ugly workarounds." It is possible to think of many metaphors for this practice. The authors of The Pragmatic Programmer [Hunt and Thomas 2000] use the metaphor of a house for software development, where once a house has a broken window, the occupants of the house will tend to be careless and more prone to leaving broken windows themselves. Another metaphor for this practice is counter space in your kitchen: All it takes is for someone to leave an unopened letter on a section of your counter, and before you know it, there will be more there. Software has all the same properties as a house or kitchen countertop: It's exceedingly easy to make changes in a sloppy, haphazard way. Once one sloppy change has been made, others will follow; this is unfortunately human nature. Therefore, never start the decay, and if you find some bad code, clean it up immediately. If the programmer who left the mess behind is still working on the code, make sure he or she knows about the cleanups you have made and why you made them; peer pressure to write good code is a good thing.

In software, once decay has started, the decay will continue and get worse over time. It is really hard to care about leaving the code in a good state when there are obvious signs of neglect. This is unfortunately human nature, and the best way to combat human nature is to always leave the code in a better state than when you started. Don't leave a mess behind for someone else to clean up! Ugly workarounds cause problems and are a symptom that the product is most likely not in a working state.

Imagine That Your Customer Can See Your Broken Windows

I learned the importance of having no broken windows early in my career. The company I was working for at the time depended on a software product that had been written by another company that went bankrupt. Luckily, we were able to get the source code so that we didn't have to develop a similar product ourselves. I was given the responsibility of keeping this software working.

This source code was littered with comments like:

// Ugly workaround to fix the case where the index // is negative. Be sure to fix this in version 3!! //

At first, I found it frustrating to read these comments and to fix problems that had never been properly resolved in the first place. But after a while, I developed a sense of empathy for the original developers. No doubt they had been under a great deal of time pressure, and I suspect they would have been embarrassed if they knew that one of their customers had to deal with this code.

This experience taught me that while being under extreme time pressure may be a valid reason for leaving a broken window, there are no valid reasons to leave it there for anything more than a few days.