To rewrite or not to rewrite. That is the question!

In the past 15 years or so in my career in software, I have often had to rewrite “from the ground up”.  One of the most challenging parts of this is convincing executives of several things:

1.      This does not mean a doubled investment of the same amount of effort, risk, and pain

2.      Convincing them that the TCO WILL lower significantly.

3.      Customer satisfaction, goodwill and revenue (or efficiency, if an internal system) will increase by about the same factor.

What I have consistently noticed, is a factor of about 20. This could be idiosyncratic to the systems I have replaced, but that seems like too big a coincidence.

Investment

In the mid 2000s, my team and I refactored a VB6 desktop application that had about 2 million lines of code into about 200,000 lines of code, with approximately twice the functionality. I did so in about 3 months, whereas the original code-base took about 2 years. More recently, I did about the same on a portfolio of disparate apps to bring them into a service oriented architecture. Again, the re-investment was about 1/20th or the original.

Why does this happen? In part it stems from “the second mouse gets the cheese”. In other words, much of the pain of the first “discovery voyage” can be used to fast-track the second version.

In addition, software technology continuously moves forward.  In a relatively recent project, I removed a third party control to manage uploads. Looking at source code history, the original project to integrate this control took about two months.  And there had been many support issues. To make matters worse, the company that had created the control – complete with built-in licensing restrictions, had long since exited the market: there was no support and no source code.   

However, because technology had moved on, and Ajax techniques were now commonplace, I was able to code “from the ground up” replacement upload functionality in about 16 hours – and most of that time was spent making it look like the original so the end-users did not have to re-learn how to use their app.  While the time spent replacing it was an investment, it was far less than the original investment. 

In this article I will not go into the pros and cons of third-party controls – that is a lengthy subject worthy of an article in itself.

And that story illustrates another component to the savings – knowledge.

First, all the knowledge gained writing the original app has been captured in code. If the codebase is monolithic (or sprawling) – i.e. it pre-dates design patterns and clean/pragmatic coding techniques, likely the knowledge will be obscured, but in most cases it can still be reverse engineered fairly easily.  And newer, iterative processes allow you to reverse engineer and re-code in small, manageable chunks.

Second, the industry itself has a body of knowledge that increases exponentially with time.  Ten or twenty years ago, it was often necessary to innovate techniques from scratch with little or no body of knowledge to draw from. This usually involved trial-and-error and was a painstakingly slow process.  Now, however, almost anything you want to do is likely documented somewhere – you just have to search the web until you find it – usually a quick process.  Rarely do developers need to innovate techniques from scratch. In some ways that is a shame – this level of innovation is motivating to innovators – but it is very good news for the bottom line.

And remember, the original investment is sunk costs. This can create a misconception that a rewrite somehow means that original investment was wasted, particularly if the rewrite is 1/20th of the original cost. But throwing good money after bad is a fallacy in any scenario. And the knowledge from the original project, which is what code embodies, is still a salvageable asset. The ROI on starting over will pay of far faster and with a much steeper positive curve if you invest in the rewrite instead of the Jenga tower your old code base has likely become.

Cost of Ownership

Every line of code in your application may seem like an asset, but in fact it is a liability. It costs time and money to create, time and money to maintain, disk space, time to scroll through, adds to build/release times, download size/speed, execution speed and so on. While each line of code adds only a miniscule percentage to these things, they add up quickly, especially if you have millions of lines of code.

The features in an application that deliver business value are the assets. So the Equity of your code is:

Of course, how you measure the value of your software features is subjective and unique to your business.  But within your business, the formula is sound.  And a side effect of thinking in these terms is to help your development team stay away from unnecessary features! Software engineers love to innovate and be helpful. If they think it might be useful, there is a very good chance they will code it. So thinking in these terms helps keep them focused on the business value you actually need – not the bells and whistles that make your app seem cutting-edge, but in actually do nothing for your business or your customers.

The formula for cost of ownership is:

COO = Lines of Code * (Cost to create one line + (cost to maintain 1 line * lifespan))

In both cases, there is a (virtually) linear relationship between the lines of code and your bottom line!  

And while it may be tempting to squeeze a few more years of life from an aging application, consider impact of a 1/20th reduction in the number of lines of code, written more cost-effectively, and supportable more cost-effectively. I will use an off-the-cuff example, based loosely on my experience.

Old Code:

• Equity Ratio = 1,000,000 / 1,000,000 = 1. (‘value of features’ is arbitrary for simplicity)
• TCO = 1,000,000 LOC * ($5.00 + ($1.00 * 10 years) = $15,000,000 or $1.5m/year

New Code:

• Equity Ratio = 1,000,000 / 50,000 = 20
• TCO = 50,000 LOC * ($1.00 + ($0.25 * 10 years) = $175,000 or $17.5k/year

While these figures are made up, you can see that the Equity ratio of your code has increased by 20 times, and your TCO has decreased by a factor of 80!  Of course, these figures can vary considerably, but you get the point.   AND because of the opportunity cost of maintaining the old code, likely your new code will have increased value very quickly.

Customer Value

And, of course, we all have customers. Whether they are internal and you are providing a service for efficiency, or they are external and bringing in revenue, it should be self-evident that your customers will be happier or more efficient, and much more willing to engage in future business opportunities with you!