Fighting the half-life of code

Question

I am building a small application that supports a research project. My goal is to make the code to be painlessly executable and readable on as many operating systems as long as possible.

My reasoning is that 2-3-5-10 years down the line I will work on a completely different research project, but my software may have to run again as well as modified again. The person who manages that code at that time should then be able to do that as painlessly as possible. This means, ideally, avoiding to install an entire OS from the present, that is outdated at that future time, together with legacy libraries, to make the software work and make changes to it. Note that I'm not looking for absolute solutions, as everything in computer science always changes, but something that is good enough! I.e. I would like to know what runtime is still useable yet changes sufficiently slowly and base my approach in that, so that my software's half-life is longest.

Non-solutions and their reasons (but correct me if I'm wrong):

• Docker. While Docker makes code be more easily reproducible in present runtimes, by making the steps to have it run more uniform, sharing any code in a Docker container exposes my code to any change in the software that makes up the Docker ecosystem itself - so if Docker changes significantly in 10 years, there is no guarantee of backward compatibility. Thus, there's not guarantee for future-proof reproducibility, which I'm aiming for.

• Assembly: I could of course code the whole thing in assembly (or compile it down to assembly if I code in a higher language, as I would), using a set of CPU instructions that is as restricted as possible that has high likelihood to stay fixed over the time span (e.g. a carefully chosen subset of x86). But that would introduce a number of problems:

  -- It might be the case that things might break in such a process (already converting Python GUI applications to C can introduce weird bugs), making it harder to code the application.

  -- An even bigger issue: I cannot read or make changes to my application. For that I would have to supply the (high-level) source code, but then there's again the issue the a future run-time will not support that source code.

Question 1: What would a good trade-off be in terms of future-proof reproducibility?

Question 2: I guess one good approach is to think 2-3-5-10 years backward. What existed back then that I could still painlessly execute but also read today? (Perhaps coding in C, as it is well supported and its standard barely seems to change with time?)

Question 3: How should I deal with 3rd party libraries? Assume C would be the best answer to the previous questions. To make everything work, I would need all the 3rd party libraries I use to also be in C and also ship them together with my application. Is there a better solution for that?

Answer 1

If its not too complex for sure JavaScript and HTML (and preferably within one file).

Browsers need to have A LOT of backwards compatibility.

I’m pretty sure if you keep to normal logic all your forms and javascript will just work fine in 10 years on all browsers and all OSes and can be run with one click.

Update: I think people in the comments are confusing the HTML/JavaScript ecosystem to JavaScript the language. To be clear: don't use any preprocessors (like less or sass) or package managers like NPM. They break A LOT. If you use any libraries, try to keep it simple and of course include the code within your project. Don't refer to external files.

I'm very confident that even sites from 1995 will still run today. Although deprecated even frameset still works.

Answer 2

Disclaimer: I am a guy who leads a team which maintains > 100 programs, where most of them have a long history, several of them much longer than just 10 years. From that experience, I can tell you that your best bet to achieve "future-proofness" is not to make wild guesses how the future might look like and try to design something like future-proofness into the software. Making predictions is hard - especially when they are concerned to the future.

Instead, if you want programs to live as long as possible, you need active maintainers, people who keep the software alive, and if necessary, port older code to newer technologies. If your program is of any interest to someone else in 10 years, chances are not too bad there could be someone filling out this role.

Don't get me wrong, this does not mean you cannot take any precautions. Even with active maintainers, you probably want to keep the maintenance effort low. @Candied_Orange's answer gives some good advice here (note all the recommendations there do implicitly assume there are maintainers in place). Let me add that making conservative technology choices is usually a good idea. You can google, for example, for the top 20 programming languages / ecosystems in 2012, compare them to the ones popular today and see which are still alive and actively supported by their vendors. Most of the language environments which are already older than 10 years have a high chance to survive the next 10 years as well (that's analogous the Doomsday argument, which is surely debatable, but probably better than nothing).

Of course, you should avoid technologies which are already abandoned by their vendors because they have already a clear successor, like VB.6, Python 2, Perl 5, Objective-C or technologies which are completely outdated like Cobol or Fortran. I would also recommend to avoid "the latest and the greatest", like Rust or Kotlin, and to avoid "cutting-edge" features in programming languages like C++, since there is too much movement there.

Same holds for 3rd party libs: if you rely on libraries which were mostly stable for the last 10 years, chances are high they will be there in 10 years from now. I would, however, recommend to validate who provides the libs: especially, if those are single persons or only very small organizations, you should make a risk asessment of what will happen in case they abandon the development. Is the lib open source and are you able to maintain it by yourself in case the authors cease development? Is it so popular someone else will probably maintain it? Or when it is closed source: is it provided by a bigger vendor who is likely to maintain it 10 years from now, and values backwards compatibility? If you are unsure, it is probably best to look for a different lib.

Concerning "readability" (you mean of the media where you store your source code, I guess)? That's mostly the same - you need to have an active maintainer who makes regular backups, copies the data to a new storage media from time to time, and keeps the archives alive.

For example, I have here a C++ program I wrote for my diploma dissertation almost 28 years ago. It was once stored on a floppy disk, in between I used Zip drives, CD and DVD roms. Today I keep my archives on external harddisks which are regularly renewed. But the whole source code is still readable, and it compiles with only minor modifications under GCC as well as under MSVC. However, that program makes almost no use of anything but the C standard libs, and it avoided C++ features like templates which were "cutting-edge" at the time when I wrote that program.

Answer 3

Choose a popular programming language

The more people that know the language the better the odds someone who wishes to replicate your work will know the language.

By popular I mean new graduates in your recruiting pool are likely to understand your code base without needing to be sent off to a training class on the language.

While not technically part of the language, some frameworks can cause this same problem.

Separate the core of your project from infrastructure details

Unlike choice of language, most infrastructure choices don't have to be spread throughout the code base. By keeping them out of your core they are easier to change if needed. Beware of frameworks. Prefer libraries.

For example, if I can look at your code and tell that you're using the Foo framework then that code has no more "half-life" than the Foo framework has. If you're not willing to do that to your core code then push Foo out into isolated code that lets your core use Foo like a library through a minimal interface. Then if Foo crashes and burns you don't have to re-implement the whole thing. Just what you need.

Make your dependencies easy to substitute

Talk to your dependencies through simple abstractions that make your needs clear and keep your core from knowing what it's talking to and future people can drop something new behind that abstraction without your core knowing or caring.

Write readable code

None of that works if people can't follow what's happing. Give things good names. Have people read your code today. See how much they understand without you explaining it. Be willing to rewrite, restructure, and rename to make your code understandable. Do this soon after you write even a tiny bit of code or you're going to forget the code and become unwilling to make significant changes.

---

Question 1: What would a good trade-off be in terms of future-proof reproducibility?

The pattern to follow here is very simple: make it work, make it good, repeat. The faster you make it work the more time you can spend making it easy to reproduce. Decompose and do this on the smallest useful bits you can. You'll get better as you go.

Question 2: I guess one good approach is to think 2-3-5-10 years backward. What existed back then that I could still painlessly execute but also read today? (Perhaps coding in C, as it is well supported and its standard barely seems to change with time?)

A popular language is a good choice. Also, avoid "fads". The harder someone is selling it the less likely it's good enough to stand the test of time.

Question 3: How should I deal with 3rd party libraries? Assume C would be the best answer to the previous questions. To make everything work, I would need all the 3rd party libraries I use to also be in C and also ship them together with my application. Is there a better solution for that?

Boil it down to your requirements. Your core shouldn't care if it's needs are solved by a 3rd party library or done by one of your replicators. Just make clear what the cores needs are.

Answer 4

I think you're right to look back (say) 10 years into the past. The languages which were around then and are still mostly unchanged today are the "boring" ones: C, C++, Java.

If you took a program in one of those languages from 2012 which was designed to be future-proof, I'm pretty sure you could get it to compile and run today. The problem you have is that "designed to be future-proof" is going to significantly slow down development, possibly by an order of magnitude. You will want to:

• Use as few third-party libraries as possible, preferably none. In this very specific case, you do want to reinvent the wheel so you know exactly what your dependencies are.
• Code defensively for future architecture changes. For something like C, that means making zero assumptions about the platform on which you are running - e.g. an int is not 32-bits; Java is perhaps slightly more constrained in its specification so maybe easier to code to.

You will need to decide whether the additional development time (for both present you and future you) is worth it.

(As an aside, x86 assembly is I suspect a terrible choice for future compatibility; the world is moving to Arm, and fast)

Answer 5

I think you are approaching this wrong.

10 years isn't a long time for Microsoft, IBM or Oracle. Stuff you wrote in VB6 or Java 10 years ago will still run on the latest version of windows today. This is because some big bank or government somewhere is still running windows 3.1 whilst also spending millions and demanding compatibility.

If you want your software to still run after 10 years on windows and linux then write it in java or .net core.

Sure the official support period for a specific version might be shorter than that, but the weight of these slow moving big spenders is behind you.

Answer 6

At one point I was working in a small company which can be best described of making a living of doing Agile COBOL development. A customer specific request of an alteration of their standard product could be in production in two weeks. Their product was written in OPM COBOL running on a AS/400 which is very different from customer operating systems like Windows and Linux, and which was conceived in the late 80'es. Before the internet! So it was my job to write Java-code (running on the AS/400 which it was very good at) to talk to other systems.

Question was, how should this non-COBOL code be written so it could be maintainable for at least a decade? The choice of Java was already given, but which technologies and libraries to use? (This was before the arising of Maven, when that came the job became a lot simplere because things stay on Maven Central for basically ever). At that point there was a lot of projects gathering under the Apache umbrella due to the success of the Apache http server.

I found out the following:

• The Java projects under Apache could not be relied on to live as long as I wanted them to. Several was severely neglected and others downright abandoned.
• The specifications from Sun about how to implement servlets and Java Enterprise turned out to be very sturdy and implemented by many vendors giving choices. Coding to the reference implementation (Glassfish with JavaServer Faces) was perhaps the best long-term decision made.
• Java is a very good choice for long term code. Sun had it in their DNA to be as backwards compatible as possible, and Oracle has honored that after their purchase. There are still Java 1.0 jars out there that run unmodified with the latest version of Java.

Additionally:

• You need a local copy of everything you use in your build. Network resources come and go (just ask the Wayback Machine). You must be able to build even if your internet connection is down. Use internal proxies for artifacts so they have copies that go in your backup system.
• Automate your builds. If your code can build and run from a blank template, you don't rely on individuals machines. Docker helps too.

That said. This mindset is worth a lot to the right employer, because code lives a lot longer than most people think.

Answer 7

I think your premise is wrong. In ten years no one will be interested in running your code. More likely someone will want to redo it on a different platform, implementing logic that matters then.

If you want to make people's lives easier you would do better looking at what code exists in the organization you work for now and stick with that. If they use Java, so do you. If they make a web page for everything, so do you. If at any time things will need to be changed in the future, your code will just be one of many similar parts that need to be converted rather than the oddball of someone who insisted to do things differently.