One of my favorite metaphors in regards to software development is that of Broken Windows. I first read about the theory of Broken Windows three years ago in the book the Pragmatic Programmer. The theory comes from research done in inner-city neighborhoods where a psychologist noted that when broken windows were not quickly fixed in buildings a sense of abandonment and general culture of disregard for the building took hold. Soon graffiti, trash, and more vandalism became common place. The solution: don’t allow broken windows in the first place, but more importantly, fix them immediately. When the windows were fixed quickly the exact opposite culture set in. A culture of respect and perceived quality soon meant that fewer windows, if any at all, would be broken in the future.
This parallels software development if you consider things like quick hacks, poor error handling, missing abstractions, lack of standards, etc as broken windows. When they are tolerated the same theory suggests that the culture we are instilling only perpetuates more trash and development-vandalism in our project. This is one truism about development that I believe very strongly.
If only software development broken windows were so obvious, so definite. Recently I mentioned to another developer that a metaphorical window was broken, he suggested it was merely scratched. Later I proved that a missing abstraction broken window led to breaking a standard we had all agreed to and I was concerned about what else these broken windows would lead to. The other developer claimed I was essentially using a slippery slope argument to claim one thing will lead to another. But that’s just it, that’s the point of the broken windows theory. He also suggested that he could track the windows and step in before it got too out of hand. I’m not so sure you can easily change the development culture surrounding an application after so long.
In a previous blog entry I mentioned the benefits of trying to give more than you take in terms of design choices when working with another developer. I believe in the above examples the developer who was allowing the broken windows was doing so in an effort to give wherever he could, an admirable thing to do. To keep the metaphor going, one might argue that he had to give up a few broken windows so he could gain a few steel doors. Is there risk that the broken windows will lead to more problems? Yes, I think it was even proven. However, as I have often stated before, it is also nearly definite that the hardest thing about software development is “other people”. Sometimes a few broken windows are required to maintain goodwill and a productive development culture among those people.