Sponsored Link •
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.
Dave Thomas: My current metaphor for that is my email inbox. Because I have this habit every now and then of not answering email for a while. And then it gets to the point round about the 250 message mark, where I suddenly realize, I'm never going to answer these messages. And it is the same with pending changes in software.
Bill Venners: How does technical debt relate to the broken window theory?
Andy Hunt: You don't want to let technical debt get out of hand. You want to stop the small problems before they grow into big problems. Mayor Guiliani used this approach very successfully in New York City. By being very tough on minor quality of life infractions like jaywalking, graffiti, pan handling—crimes you wouldn't think mattered—he cut the major crime rates of murder, burglary, and robbery by about half over four or five years.
In the realm of psychology, this actually works. If you do something to keep on top of the small problems, they don't grow and become big problems. They don't inflict collateral damage. Bad code can cause a tremendous amount of collateral damage unrelated to its own function. It will start hurting other things in the system, if you're not on top of it. So you don't want to allow broken windows on your project.
As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can't fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn't trust it, shouldn't go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. "Well, that's broken. Oh I just broke that. Oh well."