|At what point should you consider rewriting a software application? Just because an application is old, doesn't mean it should be rewritten. So what factors ought to be considered when attempting to justify rewriting an application? There are many things to consider, and rewriting any application should never be taken lightly. In fact, doing a cost-benefit analysis is probably a good starting point.
In today's fast paced software development environment, today's latest fad can quickly become tomorrow's long forgotten hype. What does it even mean to be legacy? According to Wikipedia
This article is not intended to be a detailed discussion of the considerations to take into account when looking to rewrite a legacy applicaiton. That would be a considerably lengthy article. Rather it is to look at some examples from my own experiences involving legacy applications. Like most developers, I thrive on working with the latest shiny new tools, but there are also times when you need to work with that legacy application too. I have heard many developers berating these legacy applications. Sometimes for good reason too. But quite often, the legacy application has been working away for years, quietly, solidly and not caused a fuss.
Quote:a legacy system is an old method, technology, computer system, or application program "of, relating to, or being a previous or outdated computer system"
I've worked with many legacy applications over the years. Some were surprisingly good, some just plain awful. Some of them, despite their age, were rock solid and were capable of running far into the future. Others spluttered and juddered their way along and needed a lot of man-handling to keep them running.
Just because an applications is legacy is not reason enough to justify a rewrite. I remember working for one particular company where the business critical back-end application was developed in COBOL. It was over twenty years old but rock solid. It rarely caused problems or generated errors. It just worked.
Another company I worked for many years ago also had a lot of legacy code (and according to sources at the company, much of the legacy code is still there to this day). The code was part of their core business logic and had been around for over a decade. This was accountancy and financials logic, and whilst the code had been updated with bug fixes over the years, it didn't require much man-handling to keep it up and running. In fact, when they decided to upgrade the application to use newer development environments and tooling, they kept much of the legacy code as they knew it worked. They didn't want to risk screwing up their core business logic by rewriting it.
Age alone is not a deciding factor when considering whether to rewrite an application. There are many legacy applications that run just fine with few problems. Alternatively, there are a great many applications developed with modern technology and tooling that are plain awful.
A few things to consider.
- Is the application code buggy and / or cause regular problems or errors?
- Does it require man-handling to keep it up and running?
- Does it meet non-functional requirements i.e. is secure, performant etc.
- Is it easy to extend and add new features?
- Does it require legacy hardware that may be insecure?
- What are the running costs of the application (development costs fixing bugs, server / hardware costs, third-party costs etc)
- Does it interact with third-party applications that may have updated their APIs?
- Has it been developed using outdated environments or tools?
Not all of these considerations will be applicable to every scenario, so don't take the list in its entirety. They are merely intended to be conversation starters to elicit further discussion. Deciding whether or not to rewrite an applicaiton is not a decision that should ever be taken lightly, but equally you need to take into account many different pieces of information and assess them in the context of the bigger picture. Age alone is not a compelling argument for a rewrite, but taken in the context of other factors, may form one of them.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare