"I'm Not Touching That!"

Here are four (of many) reasons why no one wants to touch legacy code:

1. You have to be twice as smart as the person who wrote it
2. Time heals all wounds...and erases all memories
3. No one wants to bell the cat
4. Over time, the cost of bugs exceeds the value of new features

Code is Harder to Read than it is to Write

Everyone knows that debugging is twice as hard as writing a program in the first place.  So if you're as clever as you can be when you write it, how will you ever debug it?
  -Brian Kernighan, "The Elements of Programming Style, Second Edition"

This is especially true for legacy software that relies heavily on global state.  Every piece of global state is another plate you need to get–and keep–spinning before you can even begin to solve the original problem you dove into the code to fix.

Mature Code Doesn't Actually Break that Often

One problem with mature code bases–I'm talking about applications that have been in use for over ten years–is that they tend to be in pretty good working order after they've been around that long.  

Why is this a problem?  

It means that you tend not to be working in them every day the way you would a brand new application for which you are actively developing new features.  Thus, when you do have to go poking around inside them to fix a problem, it can take a long time to reorient yourself to how everything works.  

No One Wants to Bell the Cat

You break it, you bought it.

It doesn't matter if the code is a deck of cards balanced on the head of a pin.  If you're the one who breathes on it wrong, you're still going to get the blame for bringing it all down.

It may be in the organization's best interest to add supports to make the code safer to work in, but it's not in the best interest of any single developer to be the one to do it.

Bugs Get Costlier

I created the following graph for an article I wrote about why Microsoft has not been investing in new features for Access:

The X-axis is labeled, "Market Share of the Application," but it could just as easily be changed to, "Years of Production Use," especially when it comes to custom software.  As business processes become more dependent on the core functionality of the software, the cost of breaking that core functionality goes up.

And, if we assume that we developed all the most important features first, then by definition each additional feature we add will provide less value than previous ones.

Image by Gerd Altmann from Pixabay