In my previous post, I told you that I encountered some non-optimal code. (Yes, really!) You might wonder what I did about that. Well, I fixed it, of course.

Should I have left it alone? After all, I was in the process of implementing this super-critical feature that this super-important client needed super-urgently. Did I waste time on something not-so-important?

Well, yes and no. Yes in the short term, for sure. But I like to think no in the long term. And I’m in for the long haul. I work on a software product, not a project, so I can actually afford to take a long term view.

I’m not alone on this one. The excellent book The Pragmatic Programmer talks about this as well. The authors call it fixing broken windows after a landmark sociology study:

Consider a building with a few broken windows. If the windows are not repaired, the tendency
is for vandals to break a few more windows. Eventually, they may even break into the building,
and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually,
people even start leaving bags of trash from take-out restaurants there or breaking into cars.

But fixing the one broken window prevents other windows from getting broken, claim the authors.

There has been considerable criticism on the broken window hypothesis by other sociologists. And I know of no scientific evidence for the effects of fixing broken windows in software. But the hypothesis makes intuitive sense to me. And so I keep fixing broken windows whenever I encounter them as much as possible.

By the way, if you haven’t read The Pragmatic Programmer yet, then stop wasting your time reading silly blogs, and go buy this book. You will want to keep it along with other classics such as Design Patterns, Refactoring, and The Mythical Man-Month.