How can I make my code survive? (anti software rot)

Question

Hi,

looking back at my programming career. I have made a lot of things. But unfortunately, a lot of it doesn't work anymore.

Getting the code to recompile, turns out to be tricky as well:

• Libraries are outdated (don't work anymore, updated to newer versions which are incompatible with versions 5 versions back)
• OS incompatibilites
• hardware changed (videocard specs, soundcard etc)
• Even compiler weirdness. (Old stuff made in Watcom, just doesn't compile out of the box on Visual studio 2008)

Actually. This realization made me kind of depressed.

Here we are, every day designing and programming our most clever bits of programs, and in a few years it just doesn't work anymore (apart from the fact that it's probably surpassed by another software program which is even more clever)

If I were a builder. I would lay bricks on other bricks. And 80 years later, I would walk through the city with my grandson. Point at a house and say: Look kid... your grandfather made this.

So my question:

How can I assure that my software survives the test of time?

Any special language I should work in? Any given OS which is better suited for this than another?

Any insight welcome!

Answer 1

1. Budget a specific amount of time to dedicate to fixing upgrade issues every time you upgrade something.
2. Upgrades are first in testing/evaluation mode. Only after they are validated they are accepted as the new official status of your system.

At one project I was in we refused to use the latest version of Borland C++ just because it didn't fulfill one requirement, related to alphabetical ordering of strings with international characters ('ñ', 'ç'). We sticked to the older version because we simply needed that feature.

Answer 2

It is often a matter of good library design, whether their developers were thinking of backwards compatibility or not.

Sometimes it is up to you to read the documentation and not use quick solutions that are marked with "subject to change in the future".

If you can, keep the exact versions of third party components you were using along with your projects.

As for the programming language or OS that you use, it does not really matter. More important is to limit dependencies on third party components or on yet experimental but not mature technologies.

Answer 3

• Build on frameworks/libraries/platforms that have a solid history.

  Some project that just popped up last week is probably still going to change dramatically or go away completely soon. Look for something that has been stable for a while.

• Choose a platform that looks like it's going to be around for a while.

  Meaning it should be backed by a large company that has quite some stake in the technology, or it's an open source platform that seems like it's going to be maintained for a while.

• Write clean code.

  Avoid hacks at all costs, write text-book code, use only official API calls.

• Don't rely on undocumented behaviour. (by popular demand)

  If the documentation doesn't say it should be doing this, don't use it, it might stop doing it eventually.

• Keep an eye on deprecated APIs or those that seem like candidates for deprecation.

  Never use the former, ask the gods for the latter.

• Stay in the loop and maintain.

  Even with all the precautions, you pretty much can only actively maintain your application to keep it running. The better a job you do at the other points, the less maintenance you usually need.

Answer 4

I doubt that a modern UNIX contains any of Ken Thompson's original code (Linux certainly doesn't) but he's still known as the creator of UNIX. The reason that code rot affects codebases is because people stop using the compiled code, so there is no more reason to maintain it. So if you want to be able to point stuff out to your grandchildren, you have to come up with a concept (not just code) that people will want to be using in 40 years or so. And that is hard.

Answer 5

Buildings stay for a long time because they are maintained. When there is no people around, the buildings won't last long (look at the never opened themepark in Tsjernobyl) For software it is simular, but both construction as degradation can go much faster.

Make sure the software you build is * valuable for society * is open source (so others will take over the job of rejunivation; updating the code to the world and available libraries) OR you keep the environment in which it works alive; but this won't be easy.

It is much easier nowadays to keep the binary artifacts alive; virtualisation and emulation are very good now. You can emulate a C64 on your multi-Ghz-multi-core Wintel machine

Good luck!

Answer 6

Deliver your software as a virtual appliance. As long as the VM vendor provides an upgrade path to keep old VM images running, your software keeps working. You can do the same for your development environment.

OS vendors face similar issues because they want to keep existing software running on new versions of their OS. They too have gone virtual to achieve this (e.g. Windows XP mode for Windows 7).