Fix bad designs, wrong decisions, and poor code when you see them.
There was a car in an abandoned parking lot. The car was completely intact and shiny new, as if it just rolled out of the factory. A few weeks already it stood there on his own, noticed by some people who passed by, but didn’t care too much.
Then, during one hell of a hailstorm, one hailstone decided to find its way to one of the car’s windows, leaving a crack. The car that was once new and shiny got its first sign of deterioration. A few days later, after weeks of being untouched, people stripped it completely. From its seats to its steering wheel and from its wheels to its rearview mirror, nothing remained intact. And if it was its funeral, the last thing the car saw were bright flames circling all around him.
This is the “Broken Window Theory” in full glory. Leave a dent in your code and it will soon grow into an unmanageable piece of software. The amount of entropy tends towards a maximum, in the physical world as well as in the “soft world”. Developers who work with beautiful code try to avoid being the first ones littering it. On the other hand, developers who encounter code smells are less careful, thinking the code is already broken anyway. Their own bad addition to it doesn’t matter that much, does it?
“All the rest of this code is crap, I’ll just follow suit.”
For that reason, fix each “broken window” in your code as soon as you find it. And if there is insufficient time, board it up and promise that you will fix it later.
This post is part of a series about the Pragmatic Programmer.Share on: