Fixing Broken Windows: Restoring Order and Reducing Defects in Our Software

We know the principle, from the original 1982 article “Broken Windows” where James Q. Wilson and George L. Kelling explain:

“Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.”

We see the same examples on a smaller scale. The more untidy my bedroom gets, the more likely I won’t put the laundry away – I’ll just dump it on the dresser.

This week I was talking to one of our software leads about why we were not fixing a known issue with one of our major new components – lack of documentation. He explained to me that it was to be expected, because his largest and most major subsystem that every engineer uses didn’t have any documentation either.


This reminded me of an earlier conversation about the fact that we had core dumps when a service received XML in the wrong format. “Nobody checks return values” he said. Well I always checked return values when I wrote code and I’m pretty sure that’s what they teach you at college. I think it’s just symptomatic of the larger issue.

So, what’s to be done. The broken windows theory receives plenty of criticism but I think the zero tolerance implementation is a good one. If we take some time to bring up the quality through better unit testing, engineers will follow the pattern. With a zero tolerance attitude to bad software practices we can get out of the cycle and engineers should instinctivly be embarassed to check in this kind of code. Managers should understand that documentation and code reviews are critical tasks in the project and schedule time in the plan.

Am I right?


3 responses to this post.

  1. Posted by blandine on June 13, 2009 at 9:18 pm

    I’m on the other side, and already know that we’re bound to have problems with the new software the programers are working on : so far, zero documentation (if I heard right… :> ).


  2. Yeah, well – software is usually shipped when it’s “good enough” – in our case, we fix our “Priority 1” and “Priority 2” bugs, but nothing else holds up the release.

    There are two issues really: 1.. are we getting the same kinds of defects again and again, indicating that they should be preventable or 2.. it’s more and more difficult to enhance or even maintain the system as nobody knows how it works – and over time it may get flakier if the quality of the error handling is poor.

    I guess it depends on how high your personal standards are – or as our CTO said a couple of weeks ago, “Good enough is no longer good enough.” Go Ari!


  3. Joe pointed out that he likes drinking in sleazy places, all broken windows and post-apocalyptic chic.. To be honest I kind of agree, it’s fun to be hanging out on the edge, but there’s a difference between wanting to hang out there and wanting to live there.

    We might put up with broken windows downtown, but we don’t want them on our own house.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: