The Agile Executive

Making Agile Work

Technical Debt: Refactoring vis-a-vis Starting Afresh

with 2 comments

Only three options are available to you once your technical debt overwhelms the development and customer support teams:

  1. Continue as is.
  2. Start refactoring in earnest to pay back your debt.
  3. Switch to a new code base, either by launching an unencumbered development project or through acquiring new software from another company.

The first option, obviously, does not solve any problem – you simply continue a struggle that becomes more and more difficult over time. As indicated in the post Elbow Room for Handling Technical Debt, the second option is quite difficult to carry out if it is exercised at a late point in the software’s life cycle. This post examines the third option – starting afresh.

The attraction of starting afresh is always tempting. The sins of the past, hidden in layers over layers of technical debt and manifesting themselves in low customer satisfaction and poor customer retention, are (sort of) forgiven. The shiny new software holds the promise of better days to come.

Trouble is, your old sins are there to get you in three nasty ways:

  1. New technical debt: Even if the shiny new software is very good indeed, it will decay over time. Unless you transformed your software engineering practices to ensure refactoring is carried out on an ongoing basis, sooner or later you will accrue new technical debt.
  2. Migration: Good that the new software might be, it is not likely to provide all the functionality the old software had. Migrating your customers will require a lot of hard work, particularly if your customers developed elaborate business processes on top of your old software.
  3. Critical race between old and new: For a period of time (say a couple of years) the old software is likely to run alongside the new software. Any significant new regulatory requirement will force you to update both the old software and the new software. Ditto for security. Any nifty new technology you might want to embed in your new software is likely to be equally desirable to customers who still use your old software. You will be pressed to incorporate the new technology in the old software, not just in the new software.

Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:

For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.

Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.

You might be able to reduce the ‘150% for two years’ investment by applying some draconian migration measures. Such measures, of course, will affect your customers. In the final analysis, your decision to acquire new software must be viewed as the following simple question:

What value do you place on your customer base?!

Advertisements

2 Responses

Subscribe to comments with RSS.

  1. Nice post. I appreciate that you proposed a model to evaluate this decision.

    However, in practice I find that teams and organizations rarely consider starting afresh. It’s often written off as being impossible without any analysis at all.

    I encourage teams I work with to evaluate starting afresh even it seems impossible. Of course, you need to be smart about changes like this, but you are never starting completely new. You’re starting with the knowledge you’ve learned over the years building and supporting a product in the market.

    Todd Olson

    November 11, 2009 at 9:39 pm

  2. No doubt indeed, “you’re starting with the knowledge you’ve learned over the years building and supporting a product in the market.” I would add that you start as well with the ongoing needs of the customer base using your legacy sysyem. The way you cater to (or fail to cater to) their operational and business needs while working on and introducing the new software is your acid test.

    Israel

    Israel Gat

    November 12, 2009 at 7:15 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: