Can Software Be Durable?
27 maraoz 31 7/20/2025, 1:49:22 PM
What would you change about software development if your apps must last 50 years?
What must software developers do differently to build apps that will still work 50 years from now?
Can software be durable?
I would say that was viable because it had zero dependencies and could be built with the equivalent of gfortran *.f77, provided one changed the source in plausible looking ways first.
If your software relies on fetching things from the Internet it is probably doomed within a year or so and surely within a decade.
Wouldn't bet on today's up and coming language still existing either. C89? Will probably still build fine with some compiler passing appropriate flags.
Hardcoding x64 or aarch64 assumptions likely bad for longevity too, as both are surely gone before 2075 ticks around, though equally I couldn't find a VAX and still got that code running. So that's more about minimising the cost of porting rather than anything fundamental.
Came to say this. Minimize your dependencies. Software can last forever, but everything around it changes and can break or otherwise cause incompatibilities.
- C gives you the least likely to be broken by evolution of OSes without added effort, because they need backwards compatibility.
- Java will be even more durable as it can be implemented/fixed after you compile your software. I ran my games compiled 20 years ago on a Risc-V computer flawlessly = not a single glitch! That said it requires JVM efforts to be maintained.
Oracle is heading the wrong direction in every aspect (removing fundamental features like sandbox without a clear path to replacement), but the bytecode standard will prevail, ahead of clones like C# and WASM.
That said if you make a VM why not have it JiT/AoT on all 3 bytecodes?
Either way the JVM is the final emulator, as long as it's maintained.
- Literate Programming which was developed so as to work around limitations of the Pascal development stack as it existed when the project was begun: http://literateprogramming.com/
- web2c which allows converting .web source into a format which may be compiled by pretty much _any_ C compiler
LP was described by Knuth as more important than TeX, but it suffers a bit from folks not understanding that it's not so much documentation (if it were, then _The TeXbook_ would be the typeset source of plain.tex) as code commentary only useful to developers working to extend/make use of the application --- there really does need to be some sort of system for manual documentation, but I suspect that it will continue to be a talented technical writer for the foreseeable future.
- it’s self-contained: it works without dependencies, and with the hardware it was designed for
- there’s an ongoing need: peope want to continue playing Space Invaders
- it’s transposable: the environment it runs in can be recreated through additional layers (emulators here)
- it’s recreatable: the core concepts behind Space Invaders can be reimplemented in the prevailing contexts of the time
In honor of thr 40th anniversary of this hack, I recently played the stock version in an emulator on a web page. Code lives on, I suppose.
Modern SaaS apps can't be run once the company shuts it down. You don't have the code, not even the executable.
* Hardware * Network * Storage * Electricity
Before go to software, because if the hardware break then what?
After it, you need an OS where you can be certain don't depend on the cloud or phone home ever, then after that you probably need a decent set of:
* Solid programing lang: Like Rust * Or very barebones: Like C * A RDBMS like sqlite
Set of tooling like code editor, image, etc
Software is more like a plumbing. It a) wears out b) requires maintenance c) people maintaining it is integrated part of the whole system.
But on the other hand, my 1993 1 character patch to the Linux kernel was replaced in around 96 or 97. I hope to whatever benevolent Supreme being exists that the crap pyth*n code I added to Second Life has been replaced. No one still uses Palm Pilots or Handspring Treos anymore, so I doubt that code has much life in it. Virtually every web app I wrote is dead, but they were fun to write, so whatever. And the code I added to a couple of satellites is dead (though my ground station code is still alive.) I bet that some of the avionics code in the cockpit is hard to update as well.
So... it depends... my nuke plant code still has another decade probably and my old room-mate's anti-lock braking code will probably outlast us all. Embedded systems are probably more long-lived than the Facebook front page. Some are just hard to update cause you can't easily get to the machine, others are hard due to regulatory or compliance reasons.
The real hardware gets old, wears out, parts become difficult and perhaps even impossible to source.
The operating system accumulates known vulnerabilities until it's no longer safe to connect to anything.
You can work around the latter two problems with emulation, but it's never the same--display technology if nothing else is different and presents differently. Emulation is dependent on the fidelity of the emulation. It's much harder to make it exactly cycle-and-timing accurate, though in most cases (like Word 2007) it doesn't matter.
The instructions might exist, but they are not runnable without other supporting infrastructure.
This also ignores programs that are wholly reliant on third party compute and instructions you have no access to that can be shut down and no longer available, like your MMOs.
George R.R. Martin still writes using WordStar 4.0 in DOS.
I remember reading a news story years ago about a guy who brought a vintage Mac from the 80s into the Apple Store to see if it could be a little faster. He had been using it for his accounting (or something) for the past 30 years.
Air gapped systems like these, with some degree of physical security, are pretty safe.
While you can still buy Microsoft Office once and use it “forever”, I much prefer the $129 a year, 5 users deal with 1GB of online storage per user and each user can use office between their computers, online and on mobile regardless of operating system.
A desktop only office suite would do me no good as I go back and forth between platforms.
For your example, Microsoft can alter that price any time it sees fit, discontinue platforms you use, alter the interface drastically or cut a crucial feature in tomorrow's update... I wouldn't cope with such, and am sorry for those who must.
So your starting point for this question needs to focus on that evolution of talent. Your app needs to be well-defined and compartmentalized so that each layer can be refactored when (not if) the talent pool dwindles to nothing. You need to develop a strong refactoring culture not only to handle the reality that the best thing you deliver today will be tech debt before the 50 years are up, but that whatever problem it is solving today will likewise evolve.
The durability you seek needs to be ironically focused on change management.
That said though, the vast majority of projects I've been on are probably no longer in existence. This is why I take a more casual approach to most projects - I see it as somewhat temporary and it doesn't make sense to put so much effort into a clean project.
No comments yet