Your code is complex and working with it is difficult. Years of development and bug fixes have you ready to declare bankruptcy on your technical debt and start again from scratch. It feels so freeing to leave all your past mistakes behind and start over in a new technology and do everything right this time. Before taking that plunge, let’s take a careful look at what the actual costs of beginning again really are.

A Model for Estimating Rewrite Costs

You can list out all the features in your application and build a development estimate and timeline around rebuilding these features. Most people will take this step before setting out to rewrite a software application. Why then does the software rewrite project notoriously run 4, 8, or even 10 times longer than estimated? There are three key factors that cause rewrite efforts to balloon. These factors are typically ignored when counting the costs of a rewrite up front: The catch-up cost with the existing application, the cost of undiscovered scope, and the cost of enhancements needed to gain acceptance.

Catch Up

The first factor is the catch-up cost. If you are replacing a useful software system (why would you replace a system that wasn’t being used?), then you’ll know that it takes a fair amount of effort to keep that existing product going. Customers make new requests, bugs are found, and new sales are made that require new features. In most situations, a team cannot stop development on the current system in order to rebuild the new one.

When you set out to rebuild a system, you can only build an estimate for that effort based on what you know about the current system. You can’t account for the features that the maintenance team will add while the new team is doing the rebuild. Those features haven’t even been requested yet.

We can, however, make a guess based on the assumption of the productivity of the new team vs the old team. For example, if the new development team is churning out features at a rate twice as fast as the old team, it will take them two times your initial estimates to catch up with the existing application team. If they are operating 5 times as fast, the catch-up factor is 1.25X. The table below shows how long it will take to catch up to the existing app team relative to the rebuild team’s pace.

Undiscovered Scope

The second factor that greatly extends the timeline of a rewrite project is the undiscovered scope hiding inside of the existing application. The systems that are candidates for rebuilds are often quite old. They have accumulated years and years of features and bug fixes and have often survived multiple product and development teams. As people move off of the team, features are forgotten and misunderstood; but as long as those features continue to work, there will be customers continuing to depend on them.

If you try to release at this point in the development cycle, the release will be sub-par (see chart above). It may contain all you planned to build, but it will still have fewer capabilities than the original and you will likely have to go ahead and build the missing features.

This scope is usually missed in the initial accounting of the cost of a rebuild. It’s pretty difficult to measure, but you can at least make a guess relative to your initial estimate of how much scope will be discovered by the rewrite team as they probe the product. This value is best expressed as a percentage of the discovered scope that the team initially estimates that is then added back into the overall estimate. We’ll call this Factor F_us, the undiscovered Scope Factor.

Adoption Enhancements

The final hurdle that rebuilt products face is that once they obtain feature-for-feature parity (see chart above) with the old application, their customers just don’t want to take the risk of switching to the new product. If you haven’t enhanced the product in any way, then what benefit is switching to the end user? This is especially true when your software is deeply integrated into the business processes of another organization. Using your old system might be a pain, but your customer has likely become an expert in dealing with that pain. They have developed muscle memory around how to complete their tasks and developed their own way of working in your system. If you are asking them to throw all of that expertise out the window and start over, it just won’t be worth it for them to switch.

So, even after the rewrite team has caught up with all of the known and unknown features of the old application, they still must keep going and adding features until the new offering is compelling enough for existing customers to switch.

It is again a hard number to come up with, but you can at least make an assumption and include that in your overall timeline as a percentage of the estimated cost. This factor, we will call F_as, The Adoption Enhancements factor.

Bringing It All Together

These three factors: Catch up (F_cu), undiscovered scope (F_us), and adoption enhancement (F_ae) combine to cause software rebuild projects to exceed their original estimates by many multiples. The total cost, expressed in terms of your initial estimate to develop the rewrite is as follows:

True Cost = T_est + (F_cu * T_est ) + (F_us * T_est ) + (F_ae * T_est)

Let’s do an example. Let’s say you’ve pulled a team together to estimate the effort required to complete a rewrite of your core product. The team has said that it will take a team of four developers one year to rewrite the application. That estimate of one year becomes your T_est.

Now, let’s make another assumption. Let’s say you think that the rewrite team can churn out features at a rate three times faster than the team maintaining the old product. P_r is three. That means your catch up factor is 3 / (3 - 1), or 1.5. So you’ve already added another 50% or six months to the project by just accounting for the time it will take the new team to catch the old team.

How about undiscovered scope? As a percentage of the overall feature set, what does the old application have that you don’t even know about? You might consider how many years the application has been under development and how many times the team has turned over in that time. Let’s make a guess and say our F_us is 25%.

Now, let’s look at what it will take to get the product adopted by existing customers. What kind of features requests are sitting in your backlog? What it is going to take to provide enough value to convince existing customers to switch? Remember, if you try forcing a switch on a customer, it may be just as easy for them to switch to a competitor instead! For our example, let’s predict that F_ae will be 30% to build enough features to get our product to adoption.

True Cost (in years) = 1 + .5 + .25 + .3 = 2.05 years.

You can see how with even a pretty generous set of assumptions, our initial estimate has more than doubled. F_cu, the catch-up cost, is one of the most volatile. What happens if we call the new team only twice as fast at adding features? F_cu will double our initial estimate and the total true cost estimate goes to 2.55!

Before you do a cost-benefit analysis on rewriting your application, take the time to consider the true costs of the effort. I think you’ll find it almost never pays off to approach a rewrite in this way.

What’s a better way? I’ll propose an alternative to you in my next blog post!