ianhenderson.org / 2023 july 26
software is pointless without a system that can load and run it. this ephemerality makes a lot of software people anxious. as systems get more complicated, it can take more effort to keep up with changes, and for some types of software, it can be a struggle to get something written even a year ago to work again.
so it's natural to ask: how do you make software that lasts? i'll list some potential approaches in rough order from "worst to best", in my own opinion.
you can't predict what will happen in the future, but maybe if you write flexible enough software, it will be able to adapt and survive in these new environments. probably every programmer is familiar with this kind of desire. the problem is that all this flexibility makes the overall software more complicated. the actual changes that will need to be made to adapt it to future environments are probably not the ones you planned for, and the extra complexity just gets in your way. experienced programmers are already wary of this kind of software design, but longevity is often the excuse given for why it's necessary.
another approach is looking at what kinds of systems have survived a long time already and trying to imitate their qualities. you look at something like an NES game and realize -- hey, this is pretty easy to write an emulator for. so clearly simplicity in this sense means longevity!
while it's true that simplicity makes it easier for people to write emulators, the reason the NES has survived isn't due to any technical aspect of the system. computer systems are inherently sociological -- they reproduce themselves via people. a lot of people played NES games and wanted to bring these games into the future for others to play them. there are other systems just as simple as the NES that are nowhere near as easy to emulate or to find games for.
that's not to say this approach can't be fun or produce interesting software, but it won't guarantee your software will run for a long time. you'll still need someone to care enough to write an emulator that runs on whatever system people use in the future. and realistically, the fact that everything on your system is intentionally simplified makes it less likely that people will care about it.
instead of designing a new system, you could find one that meets your needs and which has lasted a long time already. the same sociological forces that have kept that system around will continue to act into the future. and having more software depending on it will only increase the pressure. this pressure can be very strong -- even flash, a complicated system that was never designed for future extensibility, has managed to survive (through the heroic work of ruffle contributors) due to the volume of meaningful content made in it.
the downside of this approach is that these systems naturally have lot of historical baggage, and software written for them may not "fit in" to a modern system in the same way. writing a win32 gui app is a huge pain compared to something like electron. unity won't export your game to a gamecube ISO you can load into dolphin.
plain C code and small websites with no dependencies tend to keep working longer than code in advanced programming languages and frontend frameworks. this has nothing to do with any technical aspect of these languages and frameworks -- obviously C has a lot of problems, for example -- it's the social processes around the C language that keep it from changing quickly.
if people love your software, they'll do whatever they can to make sure it keeps running. the super mario 64 community created a full decompilation of the game which can be compiled to run on modern systems. ioquake3 was built on the open source release of quake 3 and is still being maintained and updated. finding things you enjoy and working to keep them around is a very natural thing for people to do.
unfortunately, this approach often doesn't work due to our system of intellectual property. you need to make money on your software, so you sell the rights to it -- the person with the rights doesn't care about longevity and would rather maintain control.
the general progression here has been from purely technical approaches (building the flexibility into the software) to purely social ones (allowing the people who love your software to keep it alive). in the end, as computer systems change, someone is going to have to do some work to keep your software running -- whether that's downloading an old dependency, writing an emulator, or decompiling a binary. the technical aspects of your software can make this work harder or easier, but ultimately someone will have to care enough to do it.