Understanding Technical Debt

"Technical Debt" is a term coined by Ward Cunningham to describe the obligations incurred by a software organization when it chooses an expedient design or construction approach that increases complexity and is more costly in the long term. The term helps communicate with technical teams and provides a powerful metaphor for describing this concept to non-technical stakeholders.

What is Technical Debt?

While the initial definition helps, it does not describe the sources of technical debt. There are two sources:

It is essential to recognize all systems carry technical debt. Our goal should be to minimize Unintentional (Type 1) technical debt by implementing processes to identify and avoid this debt source. The impact of unintentional technical debt is like being shocked at the end of the month when a bill arrives with unexpectedly high charges and interest rates.

Short-Term Versus Long-Term Debt

Companies maintain both short-term and long-term debt. In financial terms, short-term debt covers gaps between receivables (customer payments) and expenses (payroll). This debt is taken on when you are owed money and just don't have it now. It is expected to be paid off quickly. The technical equivalent seems straightforward. Short-term technical debt is taken on tactically and reactively, usually as a late-stage measure to get a specific release shipped. (We'll call this Type 2.A.)

Companies also take on debt strategically and proactively–investing in new capital equipment, like a new factory or office building. Again, the technical equivalent seems straightforward: "We don't think we must support a second platform for at least five years, so this release can be built assuming we're supporting only one platform." (We'll call this Type 2.B.)

The implication is that short-term debt should be paid off quickly, as the first part of the next release cycle, whereas long-term debt can be carried for years.

Incurring Strategic Technical Debt

When technical debt is strategically incurred, the fundamental reason is that the development cost today is viewed as more expensive than the cost will be in the future. Several reasons include:

Be Sure You Are Incurring The Right Kind of Short-Term Technical Debt

Some technical debt is taken on in large chunks: "We don't have time to implement this the right way; just hack it in, and we'll fix it after we ship." This is a large debt that can be tracked and managed. (We'll call this Type 2.A.1.)

Another technical debt accumulates from taking hundreds or thousands of small shortcuts– generic variable names, sparse comments, poor object decomposition, ignoring coding conventions, etc. This debt is similar to credit card debt. It's easy to incur, adds up faster than you think, and is harder to track and manage after it has been incurred. (We'll call this Type 2.A.2.)

Both of these kinds of short-term technical debt are commonly incurred in response to the directive, "Get it out the door as quickly as possible," "Get 'er done," or "Do the needful." Short-term technical debt from small shortcuts (2.A.2) doesn't pay off and should be avoided.

Debt Service

One of the crucial implications of technical debt is that it must be serviced. That is, once you incur a debt, there will be interest charges in the form of rework.

If the technical debt grows large enough, eventually, the company will spend more on debt servicing than it invests in increasing the value of its other assets. A typical example is a legacy code base in which so much work goes into keeping a production system running (e.g., "servicing the debt") that there is little time left to add new system capabilities. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are more risky, which is also true for technical debt.

Attitudes Toward Technical Debt

Like financial debt, different companies have different philosophies about the usefulness of technical debt. Some companies avoid taking on any debt; others see debt as a helpful tool and want to use it wisely.

Commercial teams generally have a higher technical debt tolerance than their technical teams. Executives want to understand the tradeoffs involved, whereas some technical teams believe zero is the only correct amount of technical debt. This avoidance by technical teams results from failed communications with the commercial teams regarding the existence and implications of technical debt.

Most agree that incurring debt late in a release cycle. Still, commercial teams must work on accounting for the time required to pay it off on the next release cycle. The main issue is that technical debt is less visible than financial debt. Hence, people have an easier time ignoring it.

How do You Make an Organization's Debt Load More Visible?

One way is to maintain an initiative (or project) technical debt list. Each time a technical debt is incurred, the tasks needed to pay off that debt are entered into the tracking system along with an estimated effort and schedule. The debt backlog is then tracked, and any unresolved debt over 90 days old is treated as critically past due.

This approach can increase visibility into the debt load and debt service work that needs to occur within or across release cycles. It also safeguards against accumulating the "credit card debt" of a mountain of tiny shortcuts mentioned earlier. You can tell the team, "If the shortcut you are considering is too minor to add to the debt-service list/product backlog, then it's too minor to make a difference; don't take that shortcut. We only want to take shortcuts that we can track and repair later."

Technological Relevance is not Technical Debt

Some organizations inappropriately lump costs associated with technological relevance as technical debt. The goal of budgeting efforts for technological relevance is to avoid product obsolescence. These expenses focus on work required to ensure systems work correctly with future versions of operating systems, third-party libraries, programming language improvements, etc. Most product lifecycle plans cannot account for or predict third-party release cycles or appropriately account for the impacts of these externally driven changes. Consider accounting for technological relevance separately from technological debt.

The Ability to Take on Debt Safely Varies

Different teams will have different technical debt credit ratings. The credit rating reflects a team's ability to pay off technical debt after it has been incurred.

A critical factor in the ability to pay off technical debt is the debt level a team takes on unintentionally. That is, how much Type 1 debt. The less technical debt a team creates for itself through unintentional low-quality work, the more debt a team can safely absorb for intentional reasons.

One innovative approach is to track technical debt versus team velocity. Once a team's velocity drops due to servicing its technical debt, it focuses on reducing its debt until its velocity recovers. Another approach is to track rework and use that as a measure of how much debt a team is accumulating. This remaining debt should be managed as part of the initiative backlog with a high priority.

Retiring Debt

"Working off debt" can be motivational and good for team morale because the results are measurable and tangible. A good approach when short-term debt has been incurred is to take the next development iteration and pay it off.

The ability to pay off debt depends on the software the team develops. If a team incurs short-term debt on a web application, a new release can easily be rolled out as it completes its debt-reduction work. However, suppose a team incurs short-term debt in avionics firmware. In that case, the payoff requires replacing a box on an airplane – that team should have a higher bar for taking on any short-term debt. This is like a minimum payment– if your minimum payment is 3% of your balance, that's no problem. If the minimum payment were $1000 regardless of your balance, you would think hard about taking on any debt.

Technical Debt Taxonomy

The classification presented above is complicated and needs to be clarified. Here's a summary of the kinds of technical debt. Note that the red cells should be avoided, and the yellow cells should be minimized and managed.

Technical Debt


Feature backlog, deferred features, cut features, technological relevance, etc.

(These aren't debts because they don't require interest payments.)

Type 1 - Unintentional Debt

(results of poor development practices)

Type 2 - Intentional Debt

2.A - Short-term Debt
(incurred for tactical reasons)

Long-term Debt

(incurred for strategic reasons)


Identifiable significant shortcuts

(similar to a car loan)


Identifiable tiny shortcuts

(similar to credit card debt)

Technical Debt Taxonomy

Communicating about Technical Debt

The technical debt vocabulary provides a way to communicate with non-technical teams in an area traditionally suffering from opacity. Shifting the dialog from technical to financial language provides a clear, understandable framework for these discussions. Although technical debt terminology is rare, it resonates with executives and non-technical stakeholders. It also makes sense to technical teams that are often all too aware of the debt load their organization is carrying.

Here are some suggestions for communicating technical debt to stakeholders:

Find more interesting articles by Michael Portwood at