Ask HN: Is there any software that can be considered finished?
Hello all,
We recently had a discussion at work about how software decays. That is, if one does not actively work on a piece of software it will eventually fall into ruin. This can happen e.g. because expertise is slowly rotated out of the business, dependencies break or the software can't be run on newer operating systems.
This begged the question: Is there any software that is essentially done? Where the last commit to the code base was done eons ago and where we expect this software to work for the foreseeable future.
The closest thing I can think of is projects that are feature complete. But they still need active patching.
Cheers 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.) GNU troff is maintained, though. Wouldn't any gaming systems with cartridges be considered finished? Atari, Nintendo, etc. People make rom hacks all the time. Do the changes have to be from an "official" source to count? ROM hacks might be considered _new_ software. 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. EDGAR would be one of these systems(https://en.wikipedia.org/wiki/EDGAR). It runs submissions and management for the SEC. It's development began in 1983. ls, cd and so on. Small tools with limited features. Unix approach. GNU CoreUtils ls is evolving. One example of that is that it can quote names with spaces in them and has started doing so by default. Here a search for "ls:", of the GNU CoreUtils mailing list: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=ls%3A... Something like ls still relies on sys-calls. If they change in the future someone would have to still update it right? So even if you have a working C-compiler in the far future, so that you can compile ls on new operating systems or whatever, even this simple application requires maintenance? > relies on sys-calls No, the rely on POSIX[1][2]. Syscalls are an implementation detail handled by the compiler. Programs (like 'ls' and the rest of coreutils) that conform[3] to the POSIX standard should continue to work in future POSIX compatible operating systems. If future operating systems deliberately introduce changes that break POSIX, then some work will be required to port the programs to the new environment.
However, this type of porting process is really implementing a new feature. The original finished version isn't affected and shouldn't need maintenance. [1] https://en.wikipedia.org/wiki/POSIX [2] Other standards are also important, but I am only mentioning POSIX for brevity. [3] https://github.com/coreutils/coreutils "Like the rest of the GNU system, these programs mostly conform to POSIX, with BSD and other extensions." Then it depends on what you consider "finished". If your underlying system changes, it's a totally different problem for me. 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.