I'm starting to really dislike the term "legacy code". It implies the code is bad because it's old. It perpetuates the misconception that code gets "stale" and problems build up. But that's not true. "Legacy code" is bad because it's BAD. All code is "legacy code" because unless the project is brand new, it has some history. We just don't call good old code "legacy code" because it hasn't caused us any problems. There is no reason to correlate bad code with age.
I think you're misunderstanding the term. Legacy code -- like legacy lots of other things -- is the intersection of "bad" and "it's too late to fix now".
Code which can be fixed easily isn't "legacy". Code where a replacement would need to be bug-for-bug compatible in order to avoid breaking things is "legacy".
My favorite definition of legacy code is bad code for which no tests exist. It's terrible because people have no idea what to do with it and no idea what they're breaking when they change it.
I've heard of that scenario, but I'm curious about what the best way to produce a bug-for-bug replacement would be. Should you do it right, and then put a layer in front of it that switches/transforms the output to match the old errors?
Code sitting on the same machine can keep on performing the same way forever.
But other things change. The library changed its interface. You coded your crypto lib when MAC-then-Ecrypt was all the rage. You aren't handling HTTP/1.0 headers. Windows 7 doesn't even have those 16-bit drivers any more.
I hate the "throw everything away and rewrite with the brand new frame work every two years" that some parts of the web development community seem to have (and then get angered when you ask about a version over six months old because it is what you installed everywhere). But sometimes software does rot if it's old and no one is trying to keep it up-to-date.
In 'Working with Legacy Code', Michael Feathers defines legacy code as code without sufficient tests.
The great thing about this definition is that it doesn't matter how old the code is - if it can be changed without worry about introducing unwanted behaviour because of test coverage, then it's not legacy.
It also means that you can write new legacy code right now!
The only legacy code that people talk about is bad legacy code. People never fondly remember the function they wrote ten years ago that's still doing what it should do, no debugging required.
It's always the function that's been rewritten twenty times that gets labelled as legacy code.
While code may not go bad with age, the surrounding world (compilers, frameworks, dependencies) change constantly. So while the code quality of a million LOC Java 1.0 application might be stellar, maintaining it may still be a royal pain. So in one way code does get "stale" when left untouched for too long.
