Should we always pay back Technical Debt?

Jim Highsmith on Technical Debt

A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.

Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."

Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.

Just chuck it

Let's assume a product has been in development for a few years. During that history, the software delivery team has garnered a significant amount of domain knowledge through trial and error. Some assumptions were validated, others definitively proven incorrect. Adjustments have been made, entire screens have been overhauled to improve the user experience. The data model has been tweaked to accomodate unanticipated requirements without invalidating all prior collected data. And, as we've established, there is significant technical debt.

In this same amount of time, the development tools have undergone three major revision updates, the database platform has undergone one major revision update, and the standards for the web-based front-end have undergone significant change, not to mention the advantages of jQuery, which your app is using sparsly.

The cost of maintenance and new development is on a steep incline. Making reparations as we go along will result in a slow recovery. If it took us four years to get here, it will likely take us four years to recover; perhaps longer. If you've ever worked for a couple of days on a piece of code and lost it, you know it takes about half a day to write the whole thing again and do it better.

So what is more risky? Continuing to work on this code base, cobbling together mis-matched parts in old technologies and slowly grinding out improvements or writing a new one?

I agree good code is an asset. But, just as in other investments, sometimes the best move is to take the loss and get out rather than holding on in hopes of a recovery.

Then do it better

We've the opportunity to advance the tools and technologies. We've an opportunity to build it again fortified with several years of learning through trial and error. Take advantage of this opportunity and do it well.

3 comments:

  1. I've been involved in a number of tech-debt rewrites. All disastrous. If you rewrite a crappy app with the same crappy team, what do you expect the outcome to be?

    Incremental improvement has the advantage of providing many teachable moments.

    ReplyDelete
  2. Perhaps the business will not use the same team to do the rewrite.

    Are there situations where a rewrite is a better choice than incremental improvement?

    Is there a valid business perspective wherein writing messy code is perfectly acceptable? What if it is an intentional and financially responsible part of our strategy to throw the code out and write it again every couple of years?

    This topic came up at Simple Design and Testing this year. The points made me feel all squirmy and uncomfortable, but I have to admit they sound plausible. Perhaps exceptional, but nevertheless a seemingly realistic scenario. So I figured I'd toss it out here and see what kind of reaction I received.

    ReplyDelete
  3. As your and Toby's comments both suggest, it depends on what the team(s) have learned since the first implementation and what will *truly* be different the this time around.

    How refactor-able is the first implementation? I would guess it's not (or it probably wouldn't be in that state in the first place). However, good unit tests would help make that transistion much easier and lend to a real refactoring. Without unit tests, even incremental changes are probably rewrites.

    Is there an option somewhere between option #2 and #3? e.g. new code and bug fixes must be done with unit tests and code coverage... eventually leading to a stronger code base?

    This article by GojKo Adzic which also has some good points: http://gojko.net/2009/06/19/eric-evans-why-do-efforts-to-replace-legacy-systems-fail/

    ReplyDelete