technical debt

What is technical debt?

Technical debt -- or tech debt -- is the implied cost incurred when businesses do not fix problems that will affect them in the future. Accruing technical debt causes existing problems to get worse over time. The longer debt builds up, the more costly it becomes to rectify.

Companies that delay or omit work for the sake of speed accrue technical debt, which they need to pay back later or face consequences. Technical debt is a common concept in software development, where team leaders delay features and functionality, cut corners, or settle for suboptimal performance to push the project forward. It occurs as the result of a "build now, fix later" mentality. In software engineering, tech debt is sometimes called code debt.

DevOps, Scrum and Agile development frameworks rely on speed, so managing technical debt in these methodologies is important to ensure quality isn't sacrificed.

The term technical debt was coined by developer Ward Cunningham. Cunningham was one of the authors of the Agile Manifesto and former head of research and development at Wyatt Software. During his time at Wyatt Software, Cunningham wrote in a report for the 1992 OOPSLA conference: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. ... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation."

Why is technical debt important?

As technical debt accumulates, the teams become less capable of focusing on growth and new features, and become more concerned with putting out fires -- implementing short-term solutions to longstanding, worsening core problems.

The problems that technical debt creates can also cause a chain reaction that spills into other departments. A problem that starts in development might affect the processes and people who perform other core business operations, such as manufacturing, order fulfillment and shipping.

In some cases, it is favorable or necessary to incur technical debt. A business might decide that it is worth incurring if a project needs to be completed quickly to meet a deadline or if a problem cannot be solved immediately. Teams must balance tradeoffs between quick decisions and high quality.

What are the causes of technical debt?

Technical debt is caused by the decision to not solve a problem. The following are some example software development problems that can lead to technical debt:

• Unclear project requirements. If teams alter or redefine requirements well into the project, it can force them to go back into the code and rework it to include new components that conform to the new requirements.
• Bad code. Code without proper standards can make updating it later increasingly difficult. Nonmodular code can make it harder to integrate with other code further down the line.
• No training. A lack of developer training can lead to poorly written code.
• Poor tool implementation. Developers might incorporate a new tool despite having no business case for it, wasting resources.
• Lack of documentation. Missing or inaccurate code documentation can make revisiting or updating code difficult, as programmers are forced to reacquaint themselves with the codebase.
• Poor hardware implementation. Installing hardware without proper cable or port markings can lead to technical debt by making maintenance unnecessarily difficult. Ignoring hardware configuration can also create costly performance or security issues in the future.
• Lack of testing. Releasing code without testing it can cause technical debt in the form of performance errors that require patches or fixes.
• Information silos. Information and data silos can cause teams to duplicate efforts or miscommunicate. This might occur when teams choose not to communicate if it slows them down.
• Competing departments. Prioritizing business needs might put pressure on development teams to cut corners, resulting in technical debt.
• Ignoring updates. Letting legacy code or systems sit while new ones are implemented can lead to interoperability issues down the line.

In each of these examples, the technical debt is the list of problems that teams need to address so that the project functions as intended.

How technical debt can be used

Technical debt is not always a bad thing. There are two types of technical debt:

• Planned. This is the result of taking shortcuts with an awareness of and accountability for the consequences. The debt remains visible to the team taking it on. The business actively chooses to forgo certain tasks and take debt on for a good reason.
• Unplanned. Unplanned technical debt is when problems go unaccounted for and spiral into bigger, less manageable problems. This is the result of taking shortcuts with little thought to the consequences. It becomes apparent when the consequences start to affect productivity.

Planned technical debt is useful -- and in some cases necessary. Sometimes projects require a faster time to market that requires them to make the quick decision instead of the most optimized decision. For example, if a business wants to fast-track a certain technology or establish itself in a new market, it would be worth it to hurry a project along. The key to managing technical debt correctly is to measure and be accountable for the parts of the process that are intentionally skipped. This way, debt remains manageable and can be incorporated into a business's overall plan.

How to measure technical debt

With proper measurement, technical debt doesn't accrue a problematic amount of interest and can be managed. But measuring it can be difficult. There are several metrics an organization can use to measure technical debt.

One example is technical debt ratio (TDR). TDR is a way to estimate the future cost of technical debt. An ideal TDR is 5%.

Other metrics include the following:

• defect ratios, or the number of new defects compared with old ones;
• code quality;
• completion time; and
• code reworking or refactoring.

To stay ahead of and remain accountable for technical debt, teams need to track it through change management.

One way to do this is by creating a technical debt registry. This is a document that lists all existing issues, explains the consequences that result from these issues, suggests resources to fix the problems and categorizes them by severity. As new problems arise and decisions are made, changes can be logged using a ticket or tracking system and prioritized in the registry. Some project management tools include features to improve code quality and manage backlog.

Examples of technical debt

One basic example of technical debt is the Southwest Airlines cancellation debacle of 2023. A massive storm system caused tens of thousands of flight cancellations during the 2022-23 holiday season. Although all airlines were affected, Southwest canceled a disproportionately large number of flights. Southwest was uniquely affected due to its outdated IT infrastructure -- namely, its flight scheduling model and internal management system. For example, Southwest did not have an efficient way to communicate to crew members that they'd been reassigned and to shift them where they were needed most.

The airline had experienced problems with the system that resulted in smaller-scale meltdowns in the past, but never invested in improving its systems before the avalanche of cancellations in 2023. This is an example of a company forgoing needed technical maintenance, accruing debt and eventually having to repay it when an emergency happens. An update to Southwest's 20-year-old routing system would have been costly, but it would have given the airline enough resilience to withstand the storm that caused the meltdown.

The real-life example from 2023 somewhat resembles a fictional example detailed in Gene Kim's IT novel The Phoenix Project. In the book, IT manager Bill is tasked with saving the Phoenix Project -- the implementation of a software suite that integrates retail and manufacturing at Bill's company, Parts Unlimited. The project is already late and over budget when Bill is tasked with saving it. Bill saves the project by eliminating information silos and implementing better processes, but not before a failure due to technical debt that catches the public eye. The fictional software project misses a deadline by a wide margin due to a database conversion gone wrong, and the team is left resolving a series of problems with short-term fixes just to keep the whole operation from collapsing.

As one character puts it in the novel, "Left unchecked, technical debt will ensure the only work that gets done is unplanned work. When you spend all your time firefighting, there's little time or energy left for planning. It's the IT capacity death spiral."

Proper change management is essential for ensuring technical debt is accounted for and IT teams are in sync when updating their technical systems. Learn the difference between IT change management and configuration management and how the terms overlap.