We can start by writing software that doesn't have any features at all, and save ourselves the trouble of removing them later. /s

Here you go: https://github.com/kelseyhightower/nocode

As long as code connects to other code, it will need to be updated whenever the other code is updated.

Maintenance-free code is a chimera.

Maintenance-free code exists. I'm sorry you haven't experienced work at an org that has 10+ year old code which hasn't changed at all, easily verified by source control. (Has Mozilla published something anywhere about exactly how much work it is to keep FTP support around?) And while not technically 100% free, something closely related that's basically free is lots of 10+ year old code which does need to change sometimes but only as part of a batch of the same change in many places, and that's basically free because it's done automatically by tooling.

Small code segments may indeed be maintenance free.

If a large codebase that interacts with any other system/code (either through usage of shared libraries, network connection or a common file format) has not changed, that means there's likely technical debt that hans't been addressed (or needed to address).

You can continue to use most command-line FTP programs without problem. Since the terminal is a fairly stable interface, programs written long ago often have no problem compiling and running on modern systems, or only require small changes.

I wouldn’t actually say that, but it may be more of a problem of ecosystem maturity and priorities than it is one of interface stability: I work under Linux and love it, but getting a 20- or 30-year-old program to compile or run under it is surprisingly more painful than doing the same for a Win32 program of similar age, despite the ostensible stability and undeniably better documentation, including that of historical issues, in the former case. (To be fair, getting an old DOS program to compile or run anywhere except a full VM is an absolute nightmare, even if it can sometimes be offloaded to DOSBox maintainers.)

I would say it—getting a 20-year-old CLI program to compile and run is often not much trouble at all. Not always, but often.

Even if the program was never written from Linux, you can often get it to compile and run by fixing up headers and making some other minor changes to the source code. I’ve had plenty of success compiling and running programs that were only ever designed to run on IRIX or Solaris or other Unix systems.

You can do that in any language; just write software that no one uses. The rest of it needs to be maintained regardless of what language was used.

The main issue with old code, is that it slows down refactoring.

Refactoring new code is not faster

refactoring no code (because it was removed) is certainly faster.