If you are managing a legacy application, you might feel like the language it was written in is a bit old and perhaps there is some cruft and technical debt in the existing codebase. Should you keep forging ahead with your current tech stack? Or would an application rewrite offer a chance to modernize?
Is the current language well-suited for future development?
One of the first tasks I would take on is to determine whether your current application’s language is well-suited for future app development. This can be broken down into two specific questions:
1. Can the existing language handle the requirements of the application?
Generally speaking, the answer is “yes” except under extreme conditions. For example, a Python application is interpreted and is therefore slightly slower than a compiled language. In the unlikely even that your application is truly being affected by using an interpreted language, you might consider switching to something compiled (e.g., Go).
2. Is there a healthy workforce knowledgeable in this programming language that can carry on development of the application in the future.
This is the bigger consideration, in my opinion. Let’s say your application uses the ColdFusion programming language and you will be in need of a new developer soon. Will you be able to find one? That might seem like a difficult question to answer, but there is actually some easy data to find on this: check out how many job listings there are for ColdFusion in your area. If I go to indeed.com and search for ColdFusion jobs in the Washington, D.C. area, I find 89 jobs. That’s not very many. If demand is that low, it’s fairly safe to assume supply is also low! Conversely, if I search for Python jobs in the Washington, D.C. area, I find 7,348 jobs. That’s quite the difference! If my application is written in ColdFusion, I would think seriously about how it will be maintained in the future.
Do you know what your application does?
This is not a joke question. If you’re working on a legacy application, it has likely had many years of feature development. Now, your team may have been fastidious the entire time and the application might be very well-documented and well-tested. But it’s also possible (read: likely) that not every feature and every edge case is documented or tested. If this is the case, you should consider the risk involved in a rewrite: what is the consequence of a rewrite that misses an edge case? A lost sale? Or a lost life? System criticality should play a huge role in deciding how to move forward with a potential rewrite.
If your application is not critical and you can stomach the risk, then you might be able to go forth with a rewrite and risk missing some edge cases. However, if an edge case may mean life or death, consider doing more robust discovery work before embarking on a rewrite journey.
Can you afford to do it?
An application rewrite can be an expensive prospect—not only do you have to rewrite some or all of the application, you also have to maintain the existing codebase. You should consider whether your organization can afford to do these activities simultaneously.
Can you afford not to do it?
If you are having a lot of trouble finding tech talent to support a legacy language, or are finding that your application is otherwise too challenging to continue to maintain, you may have no choice but to rewrite. Inaction is a choice, so don’t let that inaction result in not rewriting if you have to do it.
If you do rewrite, do discovery first
If you’re going to take the refactor plunge, consider using this opportunity to do user research and find out what your users need rather than only trying to recreate what your application currently does. You might find that a rewrite provides the perfect opportunity to not only modernize the software under the hood but also provide a more joyful user experience. You might be able to eliminate some rarely-used features and implement some small wins.
Use open source
If you do a rewrite, please use an open source solution! Many languages and frameworks are completely open source and free to use. This prevents your organization from being locked in to a vendor and generally ends up with a larger pool of talent from which you can recruit.
This is actually not a binary question
Even though we just spent a bunch of time discussing whether you should rewrite or not rewrite, it’s important to understand that this doesn’t have to be a binary question. A smart way to approach this problem is to evolve towards a microservices architecture in which each part of your application becomes its own service. That way, you can bite off a smaller piece of your application, rewrite it in a new language, and deploy only that piece of the app separately. Your users would use the legacy app for most interactions but be directed to the new microservice when appropriate.
For example, if you have a legacy eCommerce application, you could elect to rewrite just the payment service and deploy that on its own. Users would do all of their shopping on the legacy app but then be directed to the new service to process payments.
Don’t be afraid of change, but don’t chase shiny new things either
My last piece of advice is not to be afraid of change, but also not to chase every shiny new tech that comes along. A great example of this is if you have a tried-and-true Java application that was written over the years but works well. There may be some work you can do to improve your development processes, improve test coverage, improve UI, etc., but Java is quite performant and the talent pool is healthy. Knowing when not to rewite is just as important as knowing when to rewrite!