What is technical debt? A business risk IT must manage

What is technical debt?

Technical debt is the cost accrued over time from technology implementation decisions that emphasize expediency over long-term quality and maintenance. It is based on the idea that cutting corners for the sake of speed when writing code or setting up infrastructure will create more work to upkeep, secure, or manage in the future. For example, if the underlying code of an application pushed quickly into production is convoluted and difficult to update and maintain, the time or resources saved in the process of writing it will eventually need to be repaid in frustration and work down the line.

The idea was coined by legendary programmer Ward Cunningham, one of the authors of the Agile Manifesto, and he laid it out succinctly at the OOPSLA conference in 1992:

Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a standstill under the debt load of an unfactored implementation, object-oriented or otherwise.

While the term technical debt found its origins in software development, the concept is applicable to a wide range of IT implementations and operations beyond custom code.

Why is technical debt important?

Technical debt is often thought of in terms of financial debt, a tool for achieving something today that would be impossible without it. Just as a mortgage can help a home buyer capitalize on a property opportunity without having the full asking price at the time of the sale, a company can keep pace with competitors and make good on market opportunities by rolling out a software product or web service before the code has been perfected for long-term maintenance. 

On the other hand, taking on technical debt in this way saddles you with burdens you’ll have to deal with for years, potentially crippling IT innovation. Just as paying off a 30-year mortgage with interest will mean having paid much more than the selling price for your house, rushing a software product out the door to get first-mover benefits can subsequently eat up lots of future person-hours from your development, QA, and customer service teams.

So, is technical debt bad? The question misses the point of its importance. Financial debt in the abstract is neither good nor bad, and there are well-defined ideas such as the time value of money that help you determine whether or not taking out a specificloan is a good idea. Similarly, the conceptof technical debt allows you to think about (and even quantify) the tradeoffs involved in software development under real-world markets and pressure.

And, extending our metaphor, there are different ways to deal with technical debt, just as there are with financial debt. You can make small, regular payments that are manageable in the short run but ultimately cost a lot over time; or you can gather up the resources necessary to pay all or most of the debt off in a lump sum. For tech debt, this could mean accepting the daily toil and lost efficiency of working with substandard code; making a conscious plan to chip away at the debt, rewriting code and addressing problems over time; or ripping and replacing with a completely refactored version at a set point sometime in the future.

Technical debt in Agile: The fact that the phrase “technical debt” was coined by one of the thinkers behind Agile project management is no coincidence. Agile frameworks are often designed to take technical debt into account and encourage teams to build regular time into their schedule to revisit old code to work off that debt. That’s part of the Agile philosophy of continuous improvement.

Types of technical debt

One way to think about different kinds of technical debt comes from an influential 2009 essay from Martin Fowler. Fowler popularized the concept of code refactoring, a process that involves dealing with a lot of technical debt, so it’s a subject to which he gave a lot of thought. His essay proposed two different axes you can use to categorize technical debt. The first is planned vs. unplanned, which is self-explanatory. The second is reckless vs. prudent, which seems similar but is not quite the same thing: Prudent debt is debt that’s accounted for when taken on or later evaluated as part of a technical debt strategy, whereas reckless debt is piled up without much thought. The two axes together create a quadrant of debt types:

• Planned/reckless: “We know we’re making lots of shortcuts here, but frankly we don’t have time to think or deal with that — let’s just get it over the finish line!”
• Planned/prudent: “We’ve assessed the risks of this design before we rolled it out. We know the consequences that we’ll have to deal with, and we have a plan for them.” This could be the way a team thinks when quickly rolling out a minimum viable product that they know they’ll have to revamp later once they’ve gained users and market share.
• Unplanned/reckless: “We have a superstar team and this whole process will probably go fine!” [Later: it turns out the process did not go fine]
• Unplanned/prudent: “We discovered some problems that arose from our initial development process, but we’re keeping on top of them, learning from our mistakes, and have a plan for remediation.”

If you’re looking to accrue the “good” kind of debt, you should be favoring planned over unplanned, and prudent over reckless.

Technical debt can arise in many areas of your enterprise’s technical infrastructure. CIO’s Isaac Sacolick outlines seven types of tech debt that could cripple your business, including data debt, open source dependency debt, and architectural debt.

Causes of technical debt

With technical debt, the devil is in the details, so let’s look at some specific drivers that lead teams to take on technical debt:

• A rush to meet deadlines: Time constraints often force teams to take shortcuts, leading to substandard code that must be dealt with later. Your tech leadership team must prioritize tasks effectively and track postponed work to ensure it ultimately gets addressed.
• Unclear project requirements: When goals are vaguely written or not well thought out, teams may produce code that doesn’t really align with the underlying needs. Work done early on to define clear requirements can pay off later with cleaner code.
• Poorly written code: One of the main sources of tech debt, sloppy code makes future development and refactoring slow and inefficient; well-structured code, on the other hand, is easier to maintain and integrate with new features.
• Inadequate documentation: If poorly documented, even well-written code will cost your team and their successors wasted time and effort down the line. Establishing strong documentation from the start may take time, but will ultimately reduce effort going forward.
• Inevitable system evolution: Even well-designed codebases require ongoing maintenance due to evolving business needs, security threats, and outdated technologies. Code can “drift” due to dependencies on other packages or minor tweaks that have unintended consequences. In some ways this is the most insidious cause of tech debt, and should be guarded against.

How to measure and manage technical debt

One important difference between financial and technical debt: It’s much easier to quantify how much money you owe than it is to figure out your exact level of technical debt. There are techniques to help, however; for instance, in a whitepaper, CodeScene suggests a strategy in which you measure your team’s unplanned work, which is a good stand-in for time spent cleaning up tech debt they’ve inherited.

Even if you can’t hang a number on your debt, you still need to get a handle on it. Andrew Sharp, research director at Info-Tech Research Group, is a strong advocate for tracking technical debt. He advises IT leaders to document their most critical technical debt, understand its business impact, and establish a clear process for resolving it.

Understanding what technical debt you have is the first step to managing it. CIO’s Mary K. Pratt has a deep dive on how tech leaders should approach managing technical debt: You need to prioritize it on your road maps, think about it as a business risk, and be sure that when you do take on new debt, it’s in the planned/prudent quadrant. 

How to explain technical debt in the C-suite

Unfortunately, it can be difficult to convince CEOs and organizational leadership to invest the resources and personnel necessary to deal properly with technical debt. Technical debt is not a “sexy” subject; resourcing to address it doesn’t obviously contribute to revenue, and in the end, reducing technical debt doesn’t always come with any new capabilities to point to.

Here are some strategies for convincing execs to prioritize technical debt:

• Koenraad Schelfaut explains how to talk to your board about tech debt, laying out the business-oriented lingo that will advance your cause. For instance, talk about “revenue bottlenecks” rather than “legacy systems.”
• Management is increasingly using the concept of risk management to quantify and mitigate uncertainties facing the business. Framing tech debt as a business risk — a risk of missing out on future opportunities because of the time wasted on current problems — is one way to shift the conversation.
• Overall, efforts to address technical debt can be tied to other projects, be balanced against other IT priorities, and be incorporated into a long-term strategic plan that shows return on investment.

You’re never going to be able to reduce your technical debt to zero. But with the right approach, you should be able to minimize and manage it — and take on more when that makes technical sense and can forward your organizational goals.