I don't understand why people, engineers of all people, fall for the Dunning-Kruger/NIH/ageism-in-all-teh-things consumerism fallacy that everything else that came before is dumb, unusable, or can always be done better.

Code magically rusts after being exposed to air for 9 months, donja know? If it's not trivially-edited every 2 months, it's a "dead" project.

I've wondered whether that is why we find ourselves surrounded by complex software. Legacy code is code that provides more value than the cost of its replacement. Bad code endures when that cost goes up.

If you can code something quickly and well enough that it doesn't immediately collapse under its own weight, you have succeeded. The fact that a codebase has existed long enough to become "legacy" means it did a good enough job to stay alive.

Some of the challenges with old software is the ecosystem around it. Is the language it's written in still supported on modern OS? (Visual FoxPro for example). Is the database it's using still around? What about the libraries? Are they tied to a certain runtime version with no update path? Do you even have access to the source code for these dependencies? Or the application itself? Can it build on a recent machine?

I've seen projects where some infrastructure around an old piece of code was re-written to make it run on modern platforms, but that takes good engineering (some assembly required) that companies often simply can't afford.

Expect they may not, but it's bound to happen because it's been running just fine for 8000 years...

Heck, most any project I've worked on that was started more than 3 years ago has obsolete code. If it was started before it was a near-universal habit to write tests, oh yeah we're scared to touch it.

But I agree with the author that this is a sign of things to come. Our digital empire is built on layers upon layers of bad code, and the economic cost to fix it would be enormous. And that's what's shocking. Expect things to get a lot worse before they (maybe?) get better.

Yikes! How about "old enough to have a crapton of experience I'd really like to learn from/integrate with my company"? I know there is ageism in this industry (towards both people and tools), but sometimes the cavalierness with which people throw out the idea that "old == bad" and "good == new" comes as a shock.

And besides that, shouldn't we be proud of half a century of stability and compatability? Isn't "well-designed systems that stand the test of time" a holy grail to reach for, rather than poke fun at?

I've definitely seen good intentions and supposedly good practices lead to codebases that are hard to maintain. Heck, I've contributed to the problem myself occasionally - and probably everyone has, as that maintenance experience doesn't come out of thin air.

When you look at what the turnover might be at an average org versus how long a system might be used for, it's almost guaranteed that you'll have quite a few cooks in the kitchen, with different opinions in addition to the always changing business requirements and how those might translate to a technical solution.

That said, many of the older languages are actually quite valuable for new codebases as well, because most of the problems that you'll run into have already been solved and the frameworks and libraries are both mature and have proven that they'll most likely be around for the foreseeable future.

Some software lives a LONG time and it's fine, and it's up to the user whether that software is still useful to them or not.

Seriously how many posts do we see on hacker news about like "We rebuilt this ancient machine from the 1970s to learn about it." People care about computing history. Not everyone, but there's no reason to force your software to break because the calendar rolls over. Remember Y2K? Things often live a LONG time. People are still actively writing Fortran and COBOL. The short-sightedness of this is amazing, as is the condescending "we know what's best for you" security argument.

Correct. Longer if you count people in the 80s working to fix affected code that caused problems for 20-to-25 year term financial arrangements and so forth. I'm not saying it was recent, just this is a good example and one I don't think many have sufficiently learned from (too many think it was a fuss over nothing, when really it was a fuss to make sure it was nothing).

> Plus, it's not a good thing that people are "pulled out of retirement" to fix things.

I make no claim that it is a good thing. Just that it happened, has happened far more than that one big event, and similar things will continue to happen at different scales.

I could (but for commercial and legal reasons, shouldn't and won't) name specific examples of companies relying on systems written in elderly languages/frameworks, apparently locked to old versions of software components or hardware that they just hope won't break before they finally get budget for something new (which isn't likely to happen for a reasonable definition of "soon" under the circumstances) because finding the right people to fix it would be somewhere between gloriously expensive and actually impossible.

The new paradigm has to be “plan to evolve with the ecosystem.” There are just too many moving parts to treat software as static.

"Companies advertising outdated stacks open you up to the risk of building the wrong sorts of skills, which can have far-reaching effects on your career." (Emphasis mine.)

The wrong sort of skills? Like adaptability, strong diagnostic skills, pragmatism, self-awareness, and not being a massive diva all the time? Although it's true that these things can have a far-reaching effect on your career.

Every company that's been around for a while has legacy code and you need to lose the fear of working with it. You also need to develop enough humility to realise that the code you're writing today is tomorrow's legacy.

Just because something is older doesn't mean it's not still useful. Many developers these days hold an odd kind of logical fallacy that if something hasn't been done in the last few years, it's outmoded completely. Many concepts still hold high value dating back 40 or 50 years.