What are broken windows? and what have they got to do with the software we write? The Broken Window Theory as described by Andy Hunt and Dave Thomas in The Pragmatic Programmer describes how software projects can devolve into a state of derelict by allowing seemingly small indiscretions work their way into a codebase.
The theory originates from criminology researchers who established that visible signs of crime, create an environment that fosters further crime. An example of this is a simple single broken window in a building that is left un-repaired before long there are further signs of vandalism, and eventually, the building is in a complete state of derelict beyond repair. By targeting and preventing small, seemingly inconsequential crimes, an environment such as this can be avoided.
How does this relate to the software that we write? Think of the seemingly small indiscretions that slide their way into a codebase over time, inefficient code, typos, poorly named functions and variables, not following the idioms of the language being used, inconsistent code styling or naming conventions, and ignoring errors or warnings are but a few examples. Anything where you think, this is not ideal, but it will do as a once-off.
This encourages an environment that portrays a lack of care in a system, this leads to a situation where one after another minute problem is allowed to enter the codebase, long-term resulting in a system that is unmaintainable and not welcoming to developers attempting to work on it.
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.
Now, in the real world, everyone will eventually encounter a situation where something has to be shipped to fix some critical bug in production, broken windows and all. The important thing in these situations is to not just ship it, leave it as is, and forget all about the broken windows we had no choice but to leave. Fixing the proverbial broken window must be undertaken at the earliest available opportunity. Create a task in your issue tracking system, and commit some time asap to resolving any problems left behind.
This illustrates how seemingly insignificant things, left untreated over time can place a system in a state of complete chaos, beyond an individual, or teams ability to rectify it.
Next time you are faced with the temptation to let something slide as a once-off, remember the broken window theory and lend some thought to what the state of your project will be in the future. The obvious and preferable option should always be to deal with it then and there and not allow indiscretions to go untreated.