Broken Windows in Your Code

This is going to be one of those posts that's not the least bit original, but is still a good, short read.

Not too long ago I was doing some research on workflow methodologies and came across the Agile manifesto. To describe it in a short way that does it no justice at all, the Agile workflow combines a bunch of smaller improvements in work methodology into one larger framework for a philosophy of production. Essentially, instead of having all specs for work come down from on high, with a set timescale, completely removed from the customer, the structure of work and task management is altered. If your organization is Agile, then work is broken up into smaller, more manageable, iterative chunks (on the order of a couple weeks per feature improvement). These tasks come from direct contact, or almost direct contact with the customer that requires them, and the code that is written is testable, efficient, and clean.

The testable, efficient, and clean part is where I came across the Broken Window theory. This theory is socioeconomic in nature, describing how the deterioration of a neighborhood can be sourced back to a pattern of sloppiness and neglect that infects the mindset of its residents. Note that neighborhood deterioration is certainly not SOLELY sourced from this, but damn if it doesn't help. This theory was adopted by the "pragmatic programming" work methodology to describe how sloppy, unmaintained code can spoil the whole application before too long.

With that said, here's the actual description of it which provides a far better explanation of the idea than I currently can. The book, The Pragmatic Programmer, of course expands upon this. However, what follows below is a good first step into understanding the theory.

In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict: a broken window.

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment -- a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it. and the sense of abandonment becomes reality.

The "Broken Window Theory" has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

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.