Just stumbled across an article called "Don't Live with Broken Windows: A Conversation with Andy Hunt and Dave Thomas," by Bill Venners. The summary says "Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about software craftsmanship and the importance of fixing the small problems in your code, the 'broken windows,' so they don't grow into large problems." But there's a lot more to it than that. Here's a great passage from near the beginning of the article.
Bill Venners: What is the broken window theory?Andy Hunt: Researchers studying urban decay wanted to find out why some neighborhoods escape the ravages of the inner city, and others right next door—with the same demographics and economic makeup—would become a hell hole where the cops were scared to go in. They wanted to figure out what made the difference.
The researchers did a test. They took a nice car, like a Jaguar, and parked it in the South Bronx in New York. They retreated back to a duck blind, and watched to see what would happen. They left the car parked there for something like four days, and nothing happened. It wasn't touched. So they went up and broke a little window on the side, and went back to the blind. In something like four hours, the car was turned upside down, torched, and stripped—the whole works.
They did more studies and developed a "Broken Window Theory." A window gets broken at an apartment building, but no one fixes it. It's left broken. Then something else gets broken. Maybe it's an accident, maybe not, but it isn't fixed either. Graffiti starts to appear. More and more damage accumulates. Very quickly you get an exponential ramp. The whole building decays. Tenants move out. Crime moves in. And you've lost the game. It's all over.
We use the broken window theory as a metaphor for managing technical debt on a project.
Bill Venners: What is technical debt?
Andy Hunt: That's a term from Ward's Wiki. (See Resources.) Every time you postpone a fix, you incur a debt. You may know something is broken, but you don't have time to fix it right now. Boom. That goes in the ledger. You're in debt. There's something you've got to fix. Like real debt, that may be fine if you manage it. If you've got a couple of those--even a lot of those--if you're on top of it, that's fine. You do a release get it out on time. Then you go back and patch a few things up. But just like real debt, it doesn't take much to get to the point where you can never pay it back, where you have so many problems you can never go back and address them.
I've been in organizational debt for a long time now. It will take me a while to climb out of the hole, but I'm determined to do it--at home and at work. This week I've had a taste of what debt-free living could feel like, and it's awfully nice.
A "duck blind"? Like for watching (shooting) animals in the wilderness?
Back to Sensitivity Training 101 for Mr. Hunt.
Ouch. Didn't notice that, Matt...
The so-called "broken window" theory has been heavily criticized, both as a theory and as a practical policy. Cf for instance the work of Berkeley sociologist Loic Wacquant.
Even though I understand what they mean by a "technical debt", I think they are doing themselves a disservice by using the broken "window metaphor", which has a pretty right-wing ring (among sociologists at least).
Actually, this has deeper roots in psychology. I recall in 1st year university my professor was discussing violence, and how, once a car window is broken, everyone else feels it is 'ok' to destroy the car because 'someone else started it.' Very similar to our IT students' perspectives on downloading and sharing music/movies/audiobooks. "Everyone ELSE does it...." Uh huh.
Duck blinds aren't used just by hunters. Bird watchers and wildlife photographers also use them extensively.
This is a terrible analogy. This is like applying drawinism everywhere even if it doesn't really fit (sociology).
Programmers often can't tell the difference between a window that is truly broken, and one that is simply dirty.
The worst programmers assume code they don't understand is "broken." They often waste tons of resources trying to "fix" this broken code.
If you don't believe this, then you haven't worked with enough developers on enough projects.
I think developers should be tought in SE classes that all modifications are expensive. Developers better really, really understand what they are doing, before you willy nilly fix "broken windows."
I can't say I am fond of the technical debt idea. No code will ever be perfect, and much time can be wasted tracking down a minor little glitch that doesn't really affect anybody. Take the whole process I have been going through to validate my weblog. When it wasn't perfectly valid I wasn't in debt, since it displayed just fine by and large. Validation wasn't something owed the blog, it was something that would enhance the blog. Validation allows me to add the feature of mathematics, so it increases the richness. I think one wants to use a financial analogy it would be better to talk about the value of a piece of code. Well crafted code is more valuable than poorly crafted code, and by removing glitches you increase its value.