Maintaining legacy platforms

Your beautiful, shiny new app is finished. Every bug has been found. Every feature has been perfected. Everyone breathes a sigh of relief.

Two years later and the powers that be want to add a new feature to the app. A perfectly reasonable request. So the engineering team start to plan out what they need to do to get this feature built and deployed.

Except that the lead developer who built it has left…. and the third party API that you were using is no longer being updated…. and, since the original build of the site, the technology that was used has gone through several new versions. So, if you update the site then it will no longer work with the third party API.

Oh no! 😱 You’re working on a legacy platform! *cue ominous music*

‍

‍

What makes a platform 'legacy'?

All projects and systems depend on things outside of themselves to run. The simplest of websites will still need to be stored on a web server so that people can visit the website.

If a platform uses a framework or plugins, which the vast majority of them do these days, or relies on third party services, then there is a possibility that the platform becomes ‘legacy’ when it is no longer using the latest version of the dependencies it relies upon.

While it’s critically important to keep your dependencies updated, in a recent survey, 52% of developers said they find it painful.

GitHub

Why do dependencies change?

A platform can use ‘frozen’ versions of its dependencies, which means that it will continue to work as it always has, but there’s a reason why these resources are being updated.

Over time security flaws are found and patched, and new recommendations for best practices are released. Resources are then updated to be as secure and well-written as possible. If your platform isn’t updated alongside them then it will still have those security flaws and will still use out-of-date practices.

These updates are vital but they can cause problems.

If you don’t freeze the resource versions on your project then, if they automatically update, your website or app could break without warning.

If someone wants a change to the platform, but you haven’t kept the resources it uses up-to-date, then the engineering team will either need to:

make major updates to the platform so that they can use the latest versions to ultimately make the changes wanted
or, the engineer has to work around the out-of-date platform to implement the changes without breaking the existing code, leading to more complex code that may require more maintenance in the future

Software engineers are constantly learning so that they can stay on top of new technologies. This means that the old way of doing things gets forgotten when it’s no longer applicable.

However, if the engineer is then required to work on a platform that uses these methods – methods that are so out-of-date, they may have been deprecated before that person even became a engineer – then they have to spend longer researching how the legacy platform works so that they can safely make changes to it.

What’s the solution for maintaining legacy platforms?

Prevention is better than cure. The best way to solve this problem is to not have it in the first place!

By implementing maintenance plans on platform, they will be periodically audited. These audits can include both manual and automated maintenance.

Automated maintenance tools can be helpful for highlighting issues that can then be scheduled in for investigation during the audit:

GitHub Dependabot – for checking if your platform’s third party dependencies are up-to-date
Detectify – runs security tests on your platform to ensure it isn’t vulnerable to attack
Loader.io – to stress test your platform and see how well it handles high usage levels

Manual platform maintenance checklist

Make sure the platform can run from a fresh install based on the instructions in the readme file.
Check and update the platform documentation if necessary.
Check that the platform is able to scale with the client’s future requirements, if possible, so that it’s future-proofed.
Use this maintenance time as a training opportunity to onboard other developers to the platform, so that they will already be familiar with it in case they are scheduled to work on it.
Document the updates made, and who worked on them, as well as what possible updates might be needed in the next maintenance audit.

To fix the problem of legacy platforms, prevent them from becoming legacy in the first place! A mixture of automated tools and a bit of manual maintenance periodically will help product teams to keep platforms fresh so that they are ready for any changes that might be required.