Pretty much every software developer has, at some point in their career, had to maintain old software. It could be a legacy system created in days gone by, or software recently built using outdated technology to preserve some backward compatibility. Either way, you've probably faced this challenge at some point: What do I need to ask before modernizing a piece of software? Here are five important questions you should ask yourself when working on an old project before you begin modernizing it.
First Question: Why Was It Created?
The first question you have to ask is why this software was created. This is the fundamental question: Why does this software exist? Talk to the people who use it, review the documentation, and try to find out as much as possible about its origins. What problem was this software meant to solve? Did it solve that problem entirely, or was it only a partial success? Does the issue that originally required this software still exist, or has it since been resolved by other means?
Understanding why this system or solution was created in the first place is essential. Depending on the answer, you may already be able to determine whether it makes sense to invest effort in modernizing it or not.
Second Question: Who Made It, and When?
The second question is: who made this software? Was it built in-house by the company or institution using it, or was it developed by a third party? You already know why the software was created, but it's equally important to know by whom. Knowing who built it also gives you a solid sense of when it was built.
With both answers — "Why?" and "Who?" — you can begin to picture the context in which this software came to life: at some point in time, there was a problem, and a person or team created this solution to address it. Just by answering these questions, you'll likely uncover a lot about the infrastructure and technology originally used, whether that's an open-source framework or a paid corporate solution.
Third Question: Do You Still Need It?
This is another critical question. Now that you understand the context in which this solution was created, the "Why?" and the "Who?". Ask yourself whether you still need to keep it. Think of this as the "For what?" follow-up question.
When considering this, factor in your viable alternatives. Could a modern solution be less costly than the effort and budget required to modernize the existing software? To answer this properly, you'll need to calculate how much the current software is costing you today, and how much implementing an alternative would cost.
Another possibility: You need this software, but only a small part of it, a small piece that solves a lingering problem. In that case, consider modernizing only what is currently required.
Fourth Question: Is It Possible to Maintain It As-Is?
By this point, you should have a solid grasp of why this software was created and why it's still in use. The next step is to ask: Can you avoid modernizing it by simply maintaining it in its current state?
It may seem counterintuitive to ask this in a guide about modernization, but any change carries both a cost and a risk. This is your "May I?" question, as in, "May I keep it as it is?"; building on the "Why?", "Who?", and "For what?" questions you've already answered.
To truly answer this question, you need to weigh the risks of modernizing versus not modernizing. Consider the growing complexity of the project, the costs involved, and the risks that come with changing the code. Keep in mind that new versions of libraries and frameworks are released constantly; code that could be used to update your older project. This is both a blessing and a challenge: Updating libraries can offload some maintenance responsibility, but updating one library may force you to update other libraries in a domino effect.
This effort needs to be calculated carefully. You need to identify what is truly critical to modernize and determine the minimum effort required to do so. The less time, money, and risk involved, the simpler and more cost-effective the modernization will be for your client.
Will you replace entire hardware and software components in bulk? Or will you refactor specific pieces of code for better control over the process? Either approach requires deep knowledge of the technology in use and an understanding of how the software evolved over time.
Fifth Question: What Is the Cost of Modernizing It?
If you've reached this fifth question, you've already concluded that modernization is necessary. Regardless of whether you'll rewrite part of the system or all of it, the work must be done. So the final question is: How much is it going to cost?
It's easy to see why this question must be answered before you start: It tells you whether modernizing this software is even feasible. By answering it upfront, you avoid the painful scenario of running out of time, money, or resources mid-project; thus leaving the work unfinished.
Final Thoughts
Modernizing software is a risky endeavor. I can't guarantee you'll be able to answer all the questions above. Sometimes it's impossible to know who originally built the software. Sometimes it's difficult to estimate the cost of modernization. And sometimes, the hardest question is whether it needs to be modernized at all.
There are structured methodologies that can help — such as Architecture Driven Modernization or Model Driven Engineering — but even deciding whether to modernize is a challenge in itself. When that happens, remember the original reason why you took up the task, and the right decision will eventually become clear.
If you found this article helpful, follow me on social media and on dev.to for more content on software modernization and related topics.
Cover image by Freepik - www.freepik.com
Animated GIFs by GIPHY - www.https://giphy.com/
Top comments (0)