This isn’t about Microsoft Windows.
The Parable of the Broken Window describes
a shopkeeper whose window is broken by a little boy. Everyone sympathizes with the man whose window was broken, but pretty soon they start to suggest that the broken window makes work for the glazier, who will then buy bread, benefiting the baker, who will then buy shoes, benefiting the cobbler, etc. Finally, the onlookers conclude that the little boy was not guilty of vandalism; instead he was a public benefactor, creating economic benefits for everyone in town.
The Wikipedia article quotes the original parable by Frédéric Bastiat, refers to the law of unintended consequences, then goes on to discuss the parable’s fallacy, interpretations, and applications.
Something current economists and pundits should keep in mind, don’t ya think?
However, I didn’t discover the parable until after I’d already started working on this post, triggered by reading Bruce Schneier’s “The “Broken Windows” Theory of Crimefighting, which links to a Boston Globe article by Carolyn Y. Johnson: Breakthrough on ‘broken windows’:
The results, just now circulating [the study was in 2005] in law enforcement circles, are striking: A 20 percent plunge in calls to police from the parts of town that received extra attention. It is seen as strong scientific evidence that the long-debated “broken windows” theory really works – that disorderly conditions breed bad behavior, and that fixing them can help prevent crime.
Long-debated since the idea was introduced in The Atlantic’s March 1982 “Broken Windows” by George L. Kelling and James Q. Wilson, which led to the 1996 book Fixing Broken Windows: Restoring Order and Reducing Crime in Our Communities by George L. Kelling and Catherine Coles.
But, again, this post really wasn’t meant to be about crime or urban renewal. Whenever I hear “broken windows”, I’m always reminded of one of favorite short books on programming: The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas. In this extract they say:
Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented†message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.
We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood. Don’t let entropy win.
So. I’d intended to quickly jump from a passing reference to Schneier’s post into software development, but got sidetracked and now I’m out of time (or attention span, anyway).
I started out saying that this wasn’t about Microsoft Windows, but I just can’t help myself … perhaps if Microsoft had paid more attention to broken windows, then Windows wouldn’t be so broken.
