Over a million developers have joined DZone.

Should we always pay back Technical Debt?

DZone's Guide to

Should we always pay back Technical Debt?

· Agile Zone
Free Resource

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Michael Norton, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}