Modernising Software

Recently, I picked up a project that we hadn't worked on for 5 years. Before doing anything new, we embarked on a modernisation step.

I want to explain why and what we did.

Does software age?

The software worked 5 years ago, so why do we need to do anything?

The software may not have changed, but the rest of the world has. Particular challenges we faced were:

• The system was designed on runtimes which are now out of support. We need to test and adapt the software to new runtimes.
• Some components have flagged security risks, so we need to update them.
• We cannot move the software to newer platforms in the client's IT infrastructure because of a lack of testing and support on newer operating systems.

These are immediate technical challenges. These should be handled as part of the ongoing maintenance of a project to keep the system running well and secure. In fact, future legislation from the EU and the US on cybersecurity (e.g. https://ec.europa.eu/commission/presscorner/detail/en/QANDA_22_5375) may make this a legal requirement!

If your systems are offline and isolated, this reduces the impact. However, you could still end up with a future where for example, you cannot buy a new Windows XP machine. It is better to make sure you can upgrade it proactively rather than being forced into a rush when your last XP machine dies.

Dependency Updates

This is the most critical part we are working on. Software tends to have many different dependencies, including:

• The operating system it is designed to run on. (e.g. Windows 10, Ubuntu 16.04)
• The platform or run-time engines to run it. (e.g. LabVIEW 2015 or Node v14)
• The software libraries and dependencies it uses.

In many cases, as long as these components are still in active support, updating these can be straightforward. It is in these platform's interests to make it easy!

The software libraries can be the trickier component. If multiple major versions have passed by since your last upgrade, then your system may not work well with them any more and may need more work to be able to use the latest features and security patches.

Developer Tools

The other significant aspect of this project is that much of the tooling available for developers has moved on. We started development 10 years ago, and in this particular ecosystem, there have been 1 or 2 extra generations of tools.

Again the old tools and libraries work, so why do we care?

There are a few good reasons to keep on top of these.

• We may be forced to jump to something new because tools are no longer supported or insecure. By making the change now, we can:
  1. Do it on our timeframe instead of as a rush project when something breaks.
  2. Make the change much easier by moving up one generation of tools instead of 3 or 4, where translating it may be harder.
• We can get the benefits of the new tools now. Higher productivity or better feedback will start paying us back for further development. If we wait until we have to change, we miss out on those benefits (while still having to do the work to change!)

This is a web project, so some examples of the new benefits we get immediately are:

• Improved testing tools are easier to automate as part of continuous, automated testing, so we should catch bugs earlier and write fewer in the first place.
• We can containerise parts of the application. Before I had to manage a virtual machine with the system, which was slow and error-prone to update. I can now create a representative test version of the system in a few minutes with little overhead. In the future, this will make it far easier to update the deployed application as well.
• New code analysis tools have already caught latent bugs in the system.

End Result

By the end of this process, we have software that can:

• Run on newer systems to take advantage of cost savings and new providers.

• Be secure and easier to patch security issues in the future.

• Take advantage of modern improvements for better performance and customer experience.

• Be improved faster and with less cost than before.

• Has a lower risk of getting dropped by customers because it is hard to manage or represents a security risk to the rest of their infrastructure.

Summary

You should ideally modernise software incrementally and consider upgrades as part of a software product's lifecycle.

It is critical to keeping your software secure and available, as well as helping to keep development fast and efficient. This saves you money and helps you to keep up with the competition.