[OnlyMortal]

You’re quite clearly wrong.

You write code to fit the immediate business need and that shifts rapidly over a year or two.

If you do otherwise, you’re wasting your time and the money of the enterprise you work for.

You cannot see the future however smart you might be.

[saulpw]

"Rapidly over a year or two"

That time window is when the code is not legacy yet. When the developers who wrote the code are still working on the code, the code is loaded into their collective brain cache, and the "business needs" haven't shifted so much that their code architecture and model are burdensome.

It's pithy to say "all code is legacy" but it's not true. Or, as from the other reply, if you take the definition to that extreme, it makes the term meaningless and you might as well not even bother talking, because your words are legacy the instant you say them.

[mediaman]

Why are enterprises running code from 1985?

How long code needs to last is actually highly variable, and categorical absolutist statements like this tend to generally be wrong and are specifically wrong here. Some code will need to change in a year. Some will need to last for forty years. Sometimes it's hard to know which is which at the time it is written, but that's part the job of technical leadership: to calibrate effort to the longevity of the expected problem and the risks of getting it wrong.

[andrewflnr]

You would start to have a case if you said "all code older than a year or two". You didn't, you just said "all", including code you wrote last week or five minutes ago. More to the point, you're including well-factored code that you know well and are used to working with day in and day out. If that's legacy code, then you've triggered the second half of my objection.

[perrygeo]

Obviously, code is constantly changing. That's not really the point. The point is that as soon as no one understands the code (thus no one on staff to effectively debug or change it) it's "legacy" code.

Let's say you need to make big sweeping changes to a system. There's a big difference if the company has the authors still happily on staff vs. a company that relies on a tangle of code that no one understands (the authors fired 3 layoffs ago). Guess which one has the ability to "shift rapidly"?