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.
…
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.
…
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.
From this interview with the authors of the above book.
Bill Venners: What is the broken window theory?
Andy Hunt: … We use the broken window theory as a metaphor for managing technical debt on a project.
Bill Venners: What is technical debt?
Andy Hunt: … 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.
…
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.
…
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."
Dave Thomas: It comes down to showing that you care. Take for example some code that is kind of shared among the team, but primarily is mine. There's some code in there that is obviously bad, but it doesn't look like I care about it. I'm just leaving it bad. Anybody else coming into that module might say, "Well, Dave doesn't care about it. It's his module. Why should I care about it?" In fact, if you come into my module and do something else that's bad, you can say, "Well, Dave doesn't care. Why should I care?" That kind of decay happens to modules as well as apartment buildings.
On the other hand, suppose I notice an edge condition that doesn't work in my code. I know it's a bug, but the bug is not critical to the application today and I don't have time to fix it. I could at least put a comment in there. Or, even better, I could put assertion in there, so that if the edge condition ever hits, something's going to happen that shows I'm on top of it. By doing that, first of all I make it easier to identify the problem. But I also show other people that I care about that enough that they will fix problems too when they encounter them.
Andy Hunt: If you walk into a project that's in shambles—with bugs all over, a build that doesn't quite work—you're not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug?