The broken window theory originated in the field of criminology, but nonetheless is highly relevant to software developers. Software teams that keep this theory in mind will always produce better, higher quality code than those that don’t.
In essence, the broken window theory states that a broken window on a building that is left unrepaired gives people the impression that the building is abandoned. When people get the feeling that the owner doesn’t care about the building, it starts to get damaged in other ways. Perhaps other windows get broken, or graffiti appears, and it becomes a progression to more and more serious damage.
How It Applies
This is so important on software development projects because software often has its own “broken windows”, such as bits of bad code, or components that were poorly designed. The important thing to notice is that just a few of these problems can very quickly start the entire project rolling downhill. For developers on projects with these “broken windows”, it’s far too easy to fall into the mindset of “This project has so much crap code, it won’t hurt if I add a little more.”
This is a slippery slope, and can quickly lead to disaster. What will happen, and sooner than you might think, is that the “Psychology” of the project will be destroyed. Basically, this means that the developers’ mentality towards the project will become decidedly negative. This negative mindset combined with the poor-and-only-getting-worse code can lead to some really bad software systems.
How should you ensure this won’t happen on your projects? Fix the broken windows, and fix them now! The number of issues tends to increase exponentially, so by fixing them as soon as they’re noticed, a lot of trouble and headaches are saved down the road.
For details on this and more software development tips, I encourage you to read The Pragmatic Programmer.