What’s your first impression when you look at this elevator control panel? To be honest, I find it confusing. What was the rush? I mean they could have waited for the new control panel buttons or the new software update to change everything at once. Who knows how long this patch will stay in place because it’s deemed to be “good enough”…
Personally, I see this all the time. Think about your projects, past and present, do any of them feel like this elevator control panel? It happens to all of us at some point. Typically, it happens when we’re rushed and think that temporarily commenting out a piece of code isn’t going to hurt anyone.
Well, even if we’re well intentioned, these are the kinds of actions that contribute to the deterioration of the code. Remember, code rot starts with a single careless act. It’s as simple as not following the project’s coding standards or leaving misleading comments behind. Nevertheless, over time these “temporary” patches accumulate and become the new norm. When new employees join the project and start working on codebase, they instinctively follow the existing patterns because to them it’s the way things are expected to be done.
I previously touched on this subject when I wrote about the Broken Window Principle in June 2013 and I recently came across a few blog posts that also covered this topic. One of these posts is by Jeff Atwood, the man behind StackOverflow, he shared a quote from an Atlantic Monthly article published in 1982. The quote contained the details of an experiment conducted in order to observe this principle in action. Interestingly enough, the results speak for themselves. Reflecting on my personal experiences and thinking about these results makes me to think that “temporary” patches can easily become permanent in any project.
By not keeping track of a project’s technical debt, “temporary” patches slip off our radars and live forever. At first sight this might not seem like such a bad thing. But what happens when we get a new requirement for a feature that resembles an existing “temporary” patch? Well, developers usually start from something that already exists. In this case it’s probably going to be the “temporary” patch. I mean, it’s been tested in production so we know the code works… right?
In Clean Code episode 22, Test Process Robert Martin tells us that caring for our production code is crucial, but that caring for our tests is just as important. That if we are careless with our tests, they will become a burden and will probably be abandoned. He also reminds us that recreating production code from a healthy suite of tests is possible, but that recreating tests from the production code is usually not possible.
At the end of the day, it all boils down to one word “caring”. If you care about the code and your project, they will evolve as you learn new skills. It’s not going to be perfect, but it’s probably going to be maintainable. Resulting in good team moral, better velocity and especially better quality. Don’t put things off to later, because you’ll probably never get back to them until it’s too late.