Deciding whether or not to rewrite an application can in many cases be a defining moment in the career of CxOs. Possible outcomes range from success, like in the case of Microsoft rewriting Win32, to the more common, catastrophic failures like Netscape. So when does it make sense to take the risk? What indicators are available to help make the decision? What are the common contraindicators of rewrites?
The first question to ask prior to making the decision to rewrite, in order to transform legacy applications, is “how valuable is this application?” Does the application hold unique IP that helps differentiate the business (a.k.a. secret sauce)? Can I find 80% of functionality in a COTS or SAAS solution? If the application has high business value or holds unique IP that is critical to the business then it is a good candidate for rewrite. If not, your rewrite planning should pause here. There are often better and more cost effective ways to modernize and/or stabilize an application rather than rewriting it.
For example, we recently worked with a client to replace an aging hedging platform that managed weekly trading to minimize market exposure. This application performed a myriad of calculations against a large data set based on a unique combination of algorithms that calculated risk as well as pricing for new options. After evaluating the system functional requirements, it was determine that blended COTS/Custom solution would provide the most cost effective solution. Interestingly enough, it was the COTS solution that provided the framework and modeling to run the proprietary risk equations. The custom solution managed the data and provided an interface for the 3rd party tool.
The second inquiry is to understand the cost/benefit of rewriting an applications rather than refactoring non-performing or buggy code. For this, you will need a developer to get line of code (LOC) count for the application in question. While LOC is not a perfect measure, it can provide some rough metrics that can help you make an informed decision. Use the formula below to get rough estimates:
Rewrite Cost = (#LOC in current application)x(80% efficiency from new frameworks)x(developer cost per day) / (10 LOC/day[1])
Assuming an application with 100,000 LOC and a developer cost of $400/day, the Rewrite Cost would be estimated at $3.2M to design, build, bug fix, and deploy into production. Measure this sum against the cost to retain an application in its current state. This cost would include items like refactoring costs to remediate technical debt impacting performance or quality as well as support costs associated with bug fixes, annual maintenance, and production outages. There will likely be a gap between these values, it is your decision to determine if the value created by a rewrite justifies the expense and risk of a rewrite.
Other factors that often drive a rewrite are technological advances. Many legacy application architectures and their supporting infrastructures are not designed or optimized to leverage advances in technology like mobile or cloud. In order to take advantage of these new technology many legacy systems will need to be rewritten either in part or as a whole. A classic example is the mainframe. Nearly all cloud technologies are based on the x86 chipset which does not natively support mainframe BATCH or CICS programing. For enterprises looking to reduce their mainframe footprint and offload processing to more cost effective cloud processing platforms, a rewrite is often needed to translate legacy COBOL into a cloud-friendly language, like using Heirloom to compile COBOL as Java.
As you come closer to making that fateful decision, remember the decision to rewrite or not rewrite is a business decision first. Technology influences the future state only. With that, I will leave you with a few of my favorite ‘worst reasons to rewrite code from scratch’:
- “The legacy code base is ugly” – Last time I checked code was not poetry. It is not and will never be beautiful. It is and should always be functional and efficient.
- “We don’t know how it works or what is supposed to do.” – I have never understood how this means that rewriting is a good idea. How can you rewrite it if you don’t know what it does.
“It too slow” – benchmark the app, then optimize, rewrite only if absolutely necessary
[1] The Mythical Man-Month: Essays on Software Engineering by Fred Brooks
