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
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.)
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.
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.
Here a search for "ls:", of the GNU CoreUtils mailing list:
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=ls%3A...
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?
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."
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.
Nearly every current file system get the occasional patch and update. But not the FATs.
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.
With Hubble, it's the hardware that's decayed, not the software :-)
