> Do you really want to be using 20 year old software?

Yes. When a piece of software is working the way I want, I don't want to change it. I want to keep it indefinitely. Aren't there games from 20 years ago you'd like to play again?

When a developer makes improvements, of course I want those updates. Keep me up to date automatically. But let me opt-out. Let me revert. Here's my dream: I'd be able to rewind my whole operating system back 10, 20, 30 years and be able to run and use everything from back then, exactly how it was.

Data in older programs was in legacy formats that often could only be read by that program (and sometimes only specific versions of it). One might assume that since we're using a lot more plaintext formats, our formats and encodings today will last forever, but I wouldn't be too sure of that. Better than it used to be, but it would be hubris to assume that we've hit the pinnacle of perfection of the best possible formats.

And yes, I really want to be using 20 year old software. I have software dating back to some originally written in the 1960s, updated in the 1970s, ported to the PC during the 1980s-early 1990s, which still runs fine today. Some of the programs require an emulator or virtual machine, but they still run fine. With a fair amount of confidence, I can modify and recompile the source code and it will still run. (I did this recently to add JSON output to a program written in 1989-1990.)

The problem is dependencies. Originally they were compiled in or included. But then people got all wonky about code re-use and shared libraries led us into DLL hell. Then we had things like OCX and VBX components that were shared and then vanished. Much of that is patched-over now to avoid some of those problems, and for things from that era, a VM typically runs them.

But more recently dependencies are much greater, and changing much faster, and much more often rely on network connections to specific endpoints which may not be there tomorrow. You can fairly readily pack some DLLs into a VM and run stuff from there consistently, but you can't pack a working snapshot of the entire internet into it.

That's aside from how much more complex the build systems and their dependencies have become. I know for a fact that I could still easily build and run code I wrote >15 years ago today, but not code that I wrote 10 years ago. Not all of the things necessary to build it are still available.

Admittedly systems like unemployment that are in daily use for business purposes probably should be updated. But if I want to play the original Fallout, released in 1997, I should still be able to. And in fact I can. Newer games might not last 5 years. If I want to go back and look at/adjust some vector images I made in the 1990s-2000s, I can do that in a VM, using the source files in the software used at the time, and generate new output files. With today's software, I won't be able to in the future.

Changing code may be progress. Replacing working code with code that works less well is definitely not progress, though.

The problem is that working old code often has far more corner cases and bug fixes in it than you think. It's easy to "replace" it with something that is buzzword-compliant and that uses the new shiny, but that doesn't cover all the cases and doesn't have all the needed bug fixes. That's not a step forward.

> It's easy to "replace" it with something that is buzzword-compliant and that uses the new shiny, but that doesn't cover all the cases and doesn't have all the needed bug fixes. That's not a step forward.

This is a false equivalency imo. If you build a replacement system that is buggy and sucks, you did a bad job, it has nothing to do with the tools that you are using. This seems like more of a criticism of management to me

> If you build a replacement system that is buggy and sucks, you did a bad job

Or you just didn't know about all the edge cases, niche ways of using it, and the regulation on page 475 of some arcane law code that requires that something be so.

> Or you just didn't know about all the edge cases, niche ways of using it

Sure but this goes both ways. Developers cannot know all future requirements when writing the software. SaaS models largely alleviated this problem because people are continuously working behind the scenes adding new features and fixing bugs

What you say is true. But it's really hard. It's almost impossible to get all the corner cases and only-documented-in-the-code requirements. It's, yes, a criticism of management, but it's not just that they managed the process badly. It's that they chose to go down that path at all.

It is also true that old code gets harder and harder to modify, and requirements do change, so you have to modify the old code. But you're not going to make good choices on whether or when to rewrite if you mis-estimate how hard the rewrite is to get right.

> What you say is true. But it's really hard. It's almost impossible to get all the corner cases and only-documented-in-the-code requirements.

See my other comment about continuous improvement, iteration and SaaS. We can’t expect people to get things right the first time, or ever for that matter.

Code doesn't rust or corrode or accumulate bugs as it gets older. Obviously things can change around it, i.e. Dependencies and that can lead to some mandatory changes but really there are plenty of software that is old. Much older than 20 years and it's "ready" i.e. Has All the features it needs and it's still being built and run on modern computers and it works fantastically. My own software goes back +15 years now and over the years I've ported it from 32bit builds to 64bit builds and from Qt4 to Qt5. Other than that very few new features or changes in the past years since it has all the functionality that is needed. And it works great. What's wrong with that?

Changing code (or UI or UX or anything really) just for the sake of changing it is just nonsense busywork to me.