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.