Wouldn't any gaming systems with cartridges be considered finished? Atari, Nintendo, etc.
Absolutely. Here are a couple examples of software libraries that I wrote nearly 15 years ago that are still in use by lots of people and haven't needed any form of maintenance since then:
https://www.fairtutor.com/fairlylocal/
https://www.fairtutor.com/fairlycertain/
Step one is to recognize when it's feature complete and bug free, and then stop messing with it. But the most important thing in keeping something finished is to not let anybody else unfinish it. As in, ruthlessly weed out any dependencies that make breaking changes.
Sadly, most breaking changes come from developers who like to monkey with things for no reason, because they have a project and can't help themselves from working on it after it serves its initial purpose. Find these early and either rewrite them or make sure they don't have security issues then stop updating them.
The one thing you can't control is if you have to depend on a big 3rd party service. For my 2 main rent paying products, the only changes I've had to make in the nearly 10 years that they've both been "done" has been to bump versions of things for AWS, Twilio, Stripe, etc. when they changed the API for something that worked perfectly fine previously. Sometimes these rewrites are pretty invasive and time consuming. Reduce these dependencies as much as you can.
The best way of doing that is to run your own stuff on your own servers. AWS can and will (and often do) force you redeploy your shipped .NET Core 1.0 lambdas as .Net Core 1.1, 6 months after that version becomes available. Then they'll force you to redeploy as 2.0 a year later. Then 2.1 the next. On the other hand, your server can still be running 1.0 today if it makes sense to do so (such as for something like a Lambda function that's not exposed to the outside world). The sooner you put in the work to spot that you're on that train and get yourself off it, the better.
It's all doable.
I think it depends on what ones means by finished.
Cars need maintenance after being finished on the manufacturing line. So I would say if the functionality isn't changing, then it is finished and the other parts are maintenance.
What about all those old government systems we keep hearing about, IRS, Unemployment Offices, etc that are essentially untouchable because they were programmed in something ancient like COBOL to run on mainframes? They're running in emulators now, interfacing with layers and layers of abstraction in modern languages, but by the very nature of the situation they will probably never be updated or altered, because if the immense will to so do existed, a whole new system would probably be made instead. That sounds like "finished" to me.
ls, cd and so on. Small tools with limited features. Unix approach.
I replaced a 17-year-old Panasonic Inverter microwave oven with a new one. The firmware seems almost the same. The only differences I spotted:
1. "Quick min" (increment by 60 seconds) has become +30 (increment by 30 seconds)
2. When the microwave is done cooking, and starts beeping, the beeps stop immediately when the door is opened. The 17-year-old model rang out its beeps regardless of door state.
Are the FAT file systems close enough to software? FAT32 is commonly used on SD cards to this day, and as far as I can tell, it hasn't and isn't changing. There is also xFAT that hasn't seemed to change since it was introduced.
Nearly every current file system get the occasional patch and update. But not the FATs.
The V2.00 ROM in my 1987-dated ADA MP-1 guitar pre-amp(Z80 processor) isn't going anywhere.
Windows 95 and other such operating systems.
Also software running on old toys like Pokedexes and other non-updateable electronics, like MP3 players, cd players, DVRs, microwave ovens, computer monitors, non-smart TVs, non-smart digital watches, and digital cameras.
+1 for TeX. Also programs that have been formally proven correct (mostly small-scale critical systems such as the braking system in the TGV).
With Hubble, it's the hardware that's decayed, not the software :-)
TeX (almost)
A lot of games are that way. It's no longer the way games are made, but the nature of games mean they're complete, with sequels.
I recently saw PayPal is still using code I wrote 16 years ago. Ironically, I was working for my architect from PayPal at another company at the time. We had a good laugh.
Bryan Cantrill:
http://dtrace.org/blogs/bmc/2004/08/28/the-economics-of-soft...
>> software does not wear out. That isn’t to say that software never breaks (or isn’t broken to begin with), but software that works can work in perpetuity. A favorite example of mine is troff. The source for troff is some of the nastiest stuff ever written — but it works. It hasn’t been touched in years, and probably will never be: it’s written in a portable language (C) and relies only on the most basic OS facilities. troff will work indefinitely — it will never wear out.
>> (The tragic footnote to troff is that its author, Joseph Ossanna, died tragically in 1977; the very fact that his software is humming along perfectly more than a quarter of a [century] after his death is a testament to software’s unique imperviousness to wear.)