The hidden costs of application rewrites

We all know that legacy code is expensive to keep around:

• Developers who know VB, PowerBuilder, COBOL, RPG and can actually figure out your app's source code and fix/maintain/improve it are getting scarcer and more expensive to hire. And it's not like the universities are churning them out anymore.
• Some of those apps have to run on obsolete hardware that's harder and harder to find spare parts for. And yes, computers do actually wear out.
• Some vendors (cough Microsoft cough) are writing support contracts for really old stuff with truly punishing pricing. 

All this adds up, not only in cash out the door but also in costly delays responding to market changes, regulatory issues, IT improvements, and more.

What to do?

Four choices: retire, replace, rewrite, or migrate. Let's take them in order:

Retire

If the app is still running, chances are it still has business value so retirement may not be an option. But it's still a useful exercise to ask yourself "what would happen if this app didn't exist tomorrow?" Another useful question is "what vulnerabilities or risks are we exposed to by allowing this legacy application to continue?" Every application has a sponsor, even legacy ones, so determing in conjunction with the app sponsor what the effects of retirement would be on both the local group as well as the organization at large can shine a light on the best disposition. A great example of an app that screams out for retirement is some ancient lashup of Office apps to track something that the CRM already does.

Replace

Maybe it was necessary 15 years ago to roll your own solution to a pressing business problem--thus creating a future legacy issue--but that isn't necessarily true today. More and more point solutions are appearing as hosted (SaaS) applications, particularly those that benefit from collaboration. 

Rewrite

I've yet to meet the developer who, upon looking at old code written by Someone Else, didn't want to rewrite it from scratch. And who can blame them? I'm guessing but I'd be willing to be there are more extant legacy line-of-business applications written in Visual Basic than any other programming language. After all, VB was the first technology that allowed almost anyone to write a Windows program. Using designers and components, even experienced Windows programmers could churn out apps with GUI interfaces and data base backends with speed. So there's a lot of it around. But it's written in BASIC (remember "GOTO"?) and has things in it that drive current developers a little crazy, like weak typing and a lack of object-oriented structure.

There are times, certainly, when rewriting a legacy application from scratch is the only reasonable alternative. Some of the more obvious ones:

• The app is absolutely mission critical and needs constant updates and improvements.
• The app is the public face of your business (think Amazon or Facebook). 
• You need to make a huge change (like more than 50 percent of the code). 
• The original code is fatally flawed--poorly written, unreadable, unsalvageable. 
• Dependencies on external libs or components that are no longer available, you don't have the source code, and they no longer work on modern platforms. 

Migrate

Code that works, even bad code, won't just quit working on its own. Any new bugs you run into aren't new at all, they were always in there (at least since the last build) waiting to rear their ugly heads. Unlike your Dad's Buick, it won't wear out with use. No, the reasons you can't live with old code are usually external to the code--the OS goes out of support; the hardware it depends on can't be found for love nor money; it can't play nice with other apps any more. When that happens you have to either rewrite or migrate it. Migration makes sense when the cost of rewriting (and the risk--see below) outweigh the business value of the application. Migration makes perfect sense for apps that have strong business value but need to modernize; apps where the source code is rich and complex and future changes are anticipated. Being able to "lift and shift" to a new platform and a new, modern language (such as C# instead of VB) where changes are possible and where the new code tree can serve as a starting point for selective structural improvements.

Why not rewrite everything?

The real problem with software rewrites is that they are expensive and risky. The odds that your rewrite project will go off without a hitch, coming in on schedule and budget, are right up there with the odds of picking this Saturday's Powerball number. Historically as many as 70 percent of all rewrite projects are failures in that they either missed the budget, schedule, or user requirements by a significant factor. Even the best developers write buggy code--as many as 50 bugs per 1000 lines of code (KLOC). A 100KLOC project could wind up with 5000 bugs to find, fix, and test. And the historical data suggests that some percentage of those actually won't be found before you deliver the application, but will pop up like Whack-a-Moles later on.

I think most straight-ahead application rewrites start with an honest belief that the requirements will exactly match the existing application in order to effectively bound the project and simplify test and development. But like the mechanic who says "Since we gotta yank the tranny we might as well replace the clutch and change the rear main seal" the temptation to sneak in a few little "as long as you're changing that" improvements is almost impossible to resist. A change here, a change there and pretty soon there's goes the schedule.

Simple arithmetic says it will cost between $6 and $23 per line of code you write, from start to finish. 

Ouch. 

Need more information? Check out our eBook with specifics and a free calculator to use for your own app rewrite projects.