How to write software than will keep working for decades without problems

Published on 2021-11-08.

I think that most people in the software industry have been in the situation of running a legacy system that everyone dreads because it was developed on a platform that was outdated a long time ago. In this article I will address the issue of how you develop software that keeps running without fear of breakage even when you upgrade to the latest version of the platform that the system is running on.

There are situations in which breakage is unavoidable, but you can mitigate the risk of breakage substantially if you follow a few basic and important ground rules.

Avoid the shiny - choose boring technology

Don't use "the shiny" or trendy when you choose a platform for your system. Use "boring" technology that has been battle tested and proven. This is important because boring technology rarely changes, but even when it changes, you can rely firmly on most of the basic features, which brings us to the next point.

Make custom functions, don't rely on the platform

Some platforms and programming languages change even basic functionality without caring too much about backwards compatibility, and even those that try to be backwards compatible occasionally break because of some unforeseen problem or feature that needs to be addressed - it's almost a natural part of the evolution of software. However, by avoiding the usage of platform dependent functions and making your own, you can eliminate this problem almost completely.

Even when the platform or programming language provides you with a specific function that you need, if your system depends heavily on this function for some very important feature, you should consider making your own function and use that instead. This way you eliminate the dependency on the platform provided function and you can be completely sure that the specific function will keep working even when the platform is updated.

This doesn't mean that you should write all your functions yourself, but the less you rely on platform specific functions the less likely it is that your software will break when the platform is updated.

I have personally deployed this strategy on multiple occasions and I have developed software for clients that was originally developed on (just as an example) PHP 4.x. which is now running on PHP 8.0 and it is still working exactly as it should.

The downside of this strategy is that it takes a bit longer to develop the software in the beginning, but the long term benefit is MASSIVE.

Avoid frameworks like the plague

Very rarely is the added complexity of frameworks justified and the added risk of breaking stuff down the line makes it a NO GO for serious software deployments. Only toy software and very small applications can justify the usage of frameworks and the likes.

Libraries is not the same as a framework, but even libraries can cause problems. The more complexity you add to a software project the more you risk breaking the software down the line. Consider how much of a library you really need and consider extracting only the parts that you need or make your own custom functions that provide that exact functionality.

I have heard the argument that using a popular framework is a must when you're dealing with a team of developers because then everyone will know that framework and understand the software, if you develop your own solution then nobody will understand the software, but this is a bogus argument. Being a software developer requires that you're able to understand code. Some code can be more difficult to understand that other code, but it has nothing to do with using a framework. Most frameworks nowadays has become so stupidly complex that they almost require more time to understand that the underlying programming language.

One requirement for making quality software is documentation, so make sure you document everything from the very beginning and make sure you adopt a well defined coding style. That way even a junior developer can investigate and understand the software well.

Running with well documented in-house solutions guaranties that nothing is suddenly changed, removed or added that will break stuff next time you upgrade the platform.

However, some clients just don't get it! They want the solution done yesterday and understands absolutely nothing about the long term consequence. I cannot count the number of times a client has insisted on a quick solution with the following argument: "I understand what you're saying, but we need this done now, then later, when we have made a ton of money, we can concentrate on security, performance and long term support!" In every single situation - without exception - has this turned out to be a disaster.

It's easy and quick to make junk! Quality requires time and deliberation.

Don't worry about breaking the rules

Sheeplings follow religiously and blindly!

Several times I have seen projects halted to a grind because the developers where thinking a lot about rules and less about solving problems. What kind of pattern does this problem fit into?, We must not repeat ourselves so let's add this hugely complex function rather than doing a single copy and paste here!, etc.

This point have less to do with how to keep your software running for decades, but it is still relevant because when you are following rules you become rigid and your creativity is blocked! Learn to think independently and do what works best, not what some professor or famous person is blogging and yelling and screaming about.