Pragmatic Programming

I mentioned in a previous post that I recommended Andrew Hunt of pragmatic programmer fame to speak at our group offsite. He happens to live in the area, which makes it very cost effective. I have to admit I didn't know much about these guys until I ran across their How To Keep Your Job presentation last year when I was searching for information on the offshoring trend. It's definitely the best single treatment of the offshoring topic, so I was very happy to have Andy give the presentation and elaborate on some of the specifics in person.

While he was here, I also had him autograph my copy of The Pragmatic Programmer:

It's because of developers like you that off-shoring works! :) Andy

The Pragmatic Programmer is a great book, and will definitely work its way into my recommended reading list. It's just so damn.. pragmatic. Here's an excerpt from the book on the Broken Window Theory. I observe this every day at work, and I never recognized what it was until I read about it in Andy and Dave's book:

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.

If you enjoyed that, you may also enjoy

• The DRY Principle
• Good Enough Software
• Abstraction and Detail
• Building Adapable Systems
• Programming Close to the Domain
• Programming is Gardening, not Engineering
• Tracer Bullets and Prototypes
• Programming Defensively
• Plain Text and XML

Update: I mirrored the original 1982 Atlantic Monthly "Broken Windows" article that the Broken Window theory is derived from.