How Long Will Your Code Last?

One of the most difficult aspects about being a programmer is the fact that almost nothing you’re writing now will still exist in 15 years. It’s one of the truisms of our profession that change happens FAST — much faster than other professions.

At the end of your career there will be almost no legacy of running production code. That’s a bitter pill to swallow especially if you are a software craftsman who takes pride in his work.

For example, let me just take you through a brief stroll through the software graveyard by mentioning names like:

• Word Perfect
• Lotus 123
• Windows 3.1
• Geocities (which incidentally just shut down)

This is software that used to rule the world just a a decade ago and is now piled onto the trash heap of history. It gets even worse than that though. If you were the lucky guy who wrote the first version of Word Perfect, most likely, very little of code still existed by version 9.

And these were industry leaders. As good as you are, odds are you are not writing the next Word Perfect. You are probably writing a line of business application with a half-life of 5 years or less.

So should we be thinking about this while writing code today? It’s temping to just say that it will be rewritten in a few years so what’s the point of making it perfect. But therein lies the answer.

Code is never perfect and almost always has some kind of bug or breaking point if stressed hard enough. Imperfect people simply can’t make perfect code. The key is to make the code better with each iteration.

Change in the software industry is inevitable so why not embrace it and strive to make the code better each time you touch it? This is similar to the idea of not leaving broken windows in code:

The “Broken Window Theory’’ has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

    Don’t Live with Broken Windows

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.

Like a topic that I often write about in my other blog, we as software professionals need to focus on continually improving our code (and skills) rather than writing it once for eternity.