Most companies with a software development staff have legacy code that they need to maintain because it runs their business. Even companies that don’t do software as their main business may have internal tools and such that they need to maintain.
The Belief
Many software developers and even product and management would prefer to have new, shiny software all of the time and not have to deal with the old legacy code. Usually this sentiment is expressed as something like
- The legacy system is a disaster we should rewrite/replace it.
- The hot {silver bullet} will fix it all.
- The previous developers didn’t know what they were doing.
- We could do a much better job.
Nobody seems to like the legacy system. It’s usually old, sometimes in a language/framework/architecture you don’t like. You don’t recognize the metaphors and naming conventions the old programmers chose. Obviously, we could do better.
I would have picked some specific hot technology as the {silver bullet}, but in reality new frameworks, languages, methodologies, and hype come out so often you can pick whatever your most recent favorite is and just plug it in.
You look at the legacy code and some of the decisions make no sense, obviously those old programmers did not know what they were doing. Or maybe didn’t understand as well as we do now. We could start from scratch and do a much better job with our superior understanding.
The Justification
In every position I have worked where there is old code, someone has made this suggestion. They are filled with righteous indignation about how bad this system is. Any minute now it will fall apart under its own weight. There’s no way it could last another year. We could definitely do better.
And they definitely believe this about any software they have declared to be legacy. Because legacy is just one step before trash, right? There’s no need for us to put up with legacy code.