Technical Debt Is a Balance Sheet Item

Overview

Ward Cunningham coined the term "technical debt" in 1992 to describe something specific: when you take a shortcut in software development — writing code that solves the immediate problem but is not quite right — you create a debt. Like financial debt, it accrues interest. The longer you carry it, the more it costs you.

The concept has expanded considerably since then. Today, technical debt covers any deferred decision or deferred investment in technology that creates ongoing cost or risk: infrastructure past its end of life, systems never upgraded, integrations built quickly and never stabilized, documentation never written, security patches deferred, architecture decisions that made sense in 2009 but now block everything the organization wants to do.

Why the Interest Metaphor Holds Up

When an organization takes on financial debt, the interest is visible. It appears on financial statements. It is tracked and reported. There is institutional accountability for managing it.

Technical debt interest is invisible. It does not appear on any report. It accumulates as slower development velocity, more time on maintenance instead of new capabilities, more incidents, and dramatically more expensive modernization projects when the reckoning finally arrives.

And it compounds. A system five years out of date is manageable. A system fifteen years out of date — carrying fifteen years of customizations, integrations, and undocumented business logic — is a different problem entirely. The longer the debt goes unaddressed, the more expensive it becomes to pay off.

What Technical Debt Actually Looks Like

Code debt is the original meaning: software that works but is written in ways that make it hard to understand, modify, or maintain. Every time someone needs to change it, they spend extra time figuring out what it is doing first. The risk of introducing a bug is higher than it would be with cleaner code.

Infrastructure debt is hardware and software past its recommended life or end of vendor support. Servers running operating systems that no longer receive security updates. Databases running versions the vendor no longer patches. Network equipment past its replacement cycle. This creates security risk — known vulnerabilities cannot be fixed — and operational risk, because aging hardware fails more often.

Architecture debt comes from decisions that were appropriate at the time but now constrain what is possible. A system designed for a few hundred concurrent users that now serves tens of thousands. An integration approach that worked for ten systems but becomes unmanageable at fifty. An authentication model built before current security requirements existed. Architecture debt is typically the most expensive form to address, because fixing it means redesigning, not maintaining.

Documentation debt is the most underappreciated form. When a system is built, the people who build it understand how it works. When those people leave, that understanding leaves with them unless it was written down. In enterprises, systems routinely outlast the people who built them by decades. Documentation debt means that when something breaks, when someone needs to modify the system, or when an AI project needs to understand what business rules the system enforces — nobody knows. Finding out is slow and expensive.

Who Pays

The people who accrue technical debt are often not the people who pay for it.

A development team under pressure to ship a feature quickly writes code that works but creates debt. The team moves on. The debt is inherited by whoever maintains the system later — which may be a different team, under different management, several years down the road. The pressure that created the debt is not felt by the people who eventually pay it off.

This is not a moral failing. It is a structural consequence of how technology work is organized and evaluated. When teams are measured on short-term delivery and not on the long-term health of what they build, optimizing for short-term delivery is the rational response.

Changing this requires treating technical debt as a real organizational liability — something tracked, reported to leadership, and factored into planning. Some organizations do this formally. Engineering teams maintain a register of known debt, estimate the cost of addressing each item, and dedicate a portion of each development cycle to paying it down.

Technical Debt and AI

Three specific problems show up when AI initiatives run into technical debt.

First, data access becomes harder. AI needs data. Data lives in systems. Systems with heavy technical debt — undocumented interfaces, fragile integrations, inconsistent data formats — make getting that data out significantly more difficult and time-consuming.

Second, AI-adjacent modernization gets riskier. Many AI projects require some modernization of underlying systems: better APIs, more real-time data, cleaner data models. If those systems carry significant debt, the modernization work becomes more complex because the debt has to be understood and addressed at the same time.

Third, AI systems themselves accumulate technical debt fast. A machine learning model trained, deployed, and then forgotten is technical debt. Never monitored for performance degradation. Never retrained as the underlying data changes. Never documented so that someone else can understand how it works. Deploying AI without a maintenance plan is exactly the kind of shortcut that creates future costs — and most organizations do not have a maintenance plan.

Technical debt is not glamorous. It does not make headlines. But it is one of the most significant factors in determining how fast — and how successfully — an organization can move on modernization and AI. The organizations that have dealt with it seriously have a meaningful and compounding advantage over those that have not.