Legacy Software - Love It!

As we usher in the new, lets just take a moment to talk about the "old", and why we love it like it's new. Because in some ways, it can be!

In the last couple posts, we looked at the options you can have when dealing with your legacy software applications. Assuming 'do nothing' is not an option, so far we looked at maintaining what you have and starting from scratch. At Full Metal we love to promote a third hybrid approach. Give your legacy software some love with incremental improvements.

What is required?

1. Ownership of the source code There are two aspects of this. Firstly, if you don't own the software then you are probably not in a position to modify it. Secondly, you need the code to actually work on. Is the most up to date version in your control or do you have free access to it? This is especially important for compiled languages where you need access to the pre compiled source code.
2. Upgrade path Is the language of your current software still widely used and supported? Are you going to have to upgrade and move to a new development environment at the same time. You can use the incremental improvements approach with two languages but it adds a lot of complexity to the project. It also means the number of developers who can take on this approach will be much smaller and therefore normally more expensive.
3. Multi-function software The best solution for simple software is to start again, one big effort to move from your current solution to the up to date version of it.

What does incremental improvements involve?

As you would expect from a hybrid approach, aspects of both maintenance and rebuild will take place, usually at the same time. As both with all development, one of the first things that needed to be done is a review of the current software. Here you be look at:

• The framework version it is on.
• Libraries that are being used, their version number and if they are still actively supported.
• The rest of the stack. For example, the hardware, operating system and database.
• The quality of the code. Is it well documented? Has a modern development pattern been used such as MVC? Are their security issues that need resolving?
• Are there specific areas of concern? Parts of the software that do not work well or are a constant area that bugs appear.
• Is there redundant functionality?
• The current list of bugs and required new features.

The above will allow a plan to be drawn up concentrating on the most pressing issues first. We have seen (and probably tried ourselves!) to avoid doing the above and set out with the intention of when we fix a bug, we bring that part of the code up to date. It rarely, if ever works. The big problem is that bugs tend to be urgent and the time pressure means that the quickest solution, just fixing it, is the one people take. The incremental improvements never happen. This can also lead to one of the disadvantages we point out below. Parts of the software that work, never get upgraded.

So, a priority based plan of action that covers the whole software is the way to go. Depending on the age of legacy software one of the first things is to upgrade the stack that the current framework and application works on. The idea being that where possible it is better to have everything running on the same platform. Not least to avoid the expense of running more servers.

The process is defined by the plan. You will keep fixing bugs, keep the software running and alongside that bringing your software up to date.

What are the positives of incremental improvements?

Some of the benefits of incremental improvements are:

• Can be planned to fit in with cashflow.
• No big transition from one platform to another and typically no downtime.
• No or little training required for users, changes to them are small.
• Easier testing of smaller areas of the code.
• Setting up a process that stops your code becoming legacy again.

What are the negatives of incremental improvements?

Of course, there are a few downsides:

• Typically takes longer than build from scratch.
• Might have to run two stacks during the process - proper planning should minimise this.
• Stable parts of the code can often be forgotten without a plan.
• Has some pre requisites as listed above. So not possible in all situations.

Summary

We hope it comes across how much in favour of this approach we are for being legacy code up to date. A well researched and thought out plan can make it the most painless of the options we have discussed in the last few posts and it has a big benefit for the cashflow of a business. If you would like to explore how to incrementally improve your legacy software then please get in touch.

Remember if you give your legacy software some love it will continue to support your business for a long time to come. In the meantime; if you need any help with your legacy software, then please contact us!

+44 (0) 1604 663690 | [email protected] | Unit 2 Basset Court, Grange Park, Northampton, NN4 5EZ