The Many Sources of Total Technical Debt

Technical debt is often described as the future cost created when an engineering team takes a shortcut today. The metaphor is useful, and its history is well established. Ward Cunningham introduced it to explain why apparently successful software could still require later restructuring, while subsequent work developed notions of principal, interest, and the growing cost of future change [Cun92,KNO12,Fow19].

But the usual formulation is too narrow for systems architecture.

In system development, not all technical debt begins with a shortcut. Not all of it is found in code nor is all of it created by a poor engineering decision. Some debt grows because an architecture that was once entirely reasonable becomes less aligned with the business, mission, regulatory environment, operating concept, manufacturing system, or organizational structure around it. Some appears quickly after a compromised decision. Some accumulates so slowly that the organization may not recognize it until a threshold is crossed.

That is why I use the term Total Technical Debt, or TTD.

TTD is the accumulated burden imposed on future action by architectural decisions, omissions, constraints, losses, adaptations, and environmental change across the system lifecycle. The important word is total. The debt of a system is not confined to one artifact, one discipline, or one backlog. It may be distributed across software, hardware, interfaces, requirements, verification, manufacturing, operations, governance, organizational memory, and business alignment. Research on technical debt has already shown that the phenomenon extends beyond code and includes architectural, requirements, infrastructure, documentation, and other forms of debt [KNO12, dOM+22,SHG+15]. The architectural view goes further by questioning how these burdens interact, where they are encountered, by whom, and how they change the shape of future decisions.

The second important word is burden. Debt matters because it changes what becomes difficult later.

A decision may increase the effort required to modify a system.

A missing verification capability may make future changes harder to trust
A lost expert may remove the decision memory needed to safely alter an interface
A regulatory change may make a previously acceptable design expensive to sustain
A business strategy may shift while the architecture remains fixed, turning yesterday’s strength into tomorrow’s constraint.

The architecture may not have changed, but the debt still has.

Technical Debt is not One Thing

The familiar image of technical debt is a deliberate compromise such as ship now, repair later. That case certainly exists in abundance. Short-term expediency can increase the future cost of maintaining and adapting a system, and architectural structure can strongly influence that cost [MS16,AACA15].

But a useful theory of TTD has to admit many causal sources. Debt may arise from a deliberate shortcut, but also from a decision made under incomplete information. It may result from requirements that no longer reflect the operating environment, from verification infrastructure that cannot keep pace with design evolution, from an interface that couples systems more tightly than expected, from a supplier dependency that becomes strategically fragile, or from a change in regulation that places new obligations on an old architecture.

It may arise from loss.

A person leaves
A team is reorganized
Decision rationale disappears
An undocumented workaround becomes permanent

The organization can still operate, but the future cost of understanding and changing the system has risen.

It may also arise from success.

A platform designed for one market becomes widely adopted in another
A prototype becomes operational infrastructure
A local integration becomes enterprise-critical

The architecture survives, but it now carries obligations it was never designed to carry.

None of these cases fits comfortably inside the idea that technical debt is simply the cost of bad coding or deferred cleanup.

A more useful description is

$\text{TTD} = f(\text{decisions, omissions, constraints, losses, adaptations, environment})$

This is not intended to be a directly computable equation, although it might represent a good start. It is a reminder that the current debt condition can be generated by multiple causal mechanisms, many of which interact.

Software architecture research makes a similar point from another direction. Architecture erosion can arise from both technical and nontechnical causes, and its consequences may affect system quality and evolution [LLSA22]. The broader lesson is that architectural burden is not produced only inside the technical artifact.

An Unchanged Architecture can Still Accumulate Debt

Suppose a system is stable, reliable, well tested, and well documented. Then the business changes.

Perhaps the company moves from selling products to delivering services
Perhaps customers expect continuous digital integration
Perhaps a new regulation changes the evidence required for compliance
Perhaps a merger creates a need for interoperability across systems that were never designed to communicate
Perhaps the mission changes while the installed architecture remains exactly as it was.

Nothing inside the architecture has necessarily broken. Yet the cost of future action may rise.

That is technical debt.

This is a particularly important form of slowly changing TTD because it can accumulate without dramatic symptoms. The system may continue to function. Existing metrics may remain green. The organization may see no defect severe enough to demand immediate action. But the distance between what the architecture enables and what the environment now requires is growing.

One way to express the condition is

$\frac{dA}{dt} = 0 \quad \not\rightarrow \quad \frac{d(TTD)}{dt} = 0$

where $A$ represents the architecture.

The architecture can remain unchanged while TTD increases because the surrounding environment or context has moved. This is why business alignment must be treated as a first-class component of TTD. Studies of technical-debt prioritization have shown that technical and business perspectives can diverge, and that explicit consideration of business objectives changes how debt should be understood and prioritized [dAKT+18, dA19]. At the enterprise level, technical-debt strategies likewise depend on roadmaps, target architectures, standards, and alignment across dependencies [Int24].

However, the architectural argument is stronger than prioritization. A technically coherent architecture can become strategically wrong. Its internal quality may remain high while its fitness for purpose deteriorates. That deterioration is not merely a management concern external to architecture. It changes the burden placed on every future decision that must bridge the growing misalignment.

Some Debt Changes Quickly, Some Slowly

In my original formulation of Total Technical Debt, I made a distinction between slowly changing and rapidly changing components

$\text{TTD}(t) \, = \text{TTD}_{\text{slow}}(t) \, + \, \text{TTD}_{\text{fast}}(t)$

The decomposition is conceptual rather than strictly additive. The components may interact, overlap, and change character. But the distinction matters because debt evolves on different timescales.

Rapidly changing TTD may arise from

Emergency patches and workarounds
Compressed schedules
Sudden integration failures
Urgent requirement changes
Abrupt verification problems
Operational shocks
Rapid architectural decisions made under pressure

Slowly changing TTD may arise from

Growing business-architecture misalignment
Loss of strategic fit
Aging assumptions
Increasing dependence on obsolete infrastructure
Gradual loss of expertise and decision memory
Slowly increasing verification burden
Regulatory or market drift
Accumulation of small cross-layer incompatibilities

The distinction is diagnostic. A large but stable debt burden may be manageable. A smaller debt burden that is rapidly increasing may be far more dangerous.

So the question we should be asking cannot only be

How much technical debt do we have?

We also must ask

How fast is it changing, and why?

That means the state of TTD matters, but so do its derivatives

$\text{TTD}(t), \, \frac{d(\text{TTD})}{dt}, \, \frac{d^2\text{(TTD)}}{dt^2}$

A positive first derivative means the burden is increasing. A positive second derivative means the rate of accumulation is itself accelerating.

This does not imply that we should pretend we can calculate these values precisely. Metrics are not scores, and false precision is not insight. The point is diagnostic

Two architectures with the same estimated debt can be in radically different conditions if one is stable and the other is accelerating toward a threshold.

Slow Debt Can Become Fast Debt

The slow and fast components are not permanently separate.

A slowly accumulating misalignment can suddenly become an urgent crisis. For years, an architecture may become progressively less compatible with the business model or context around it. The burden is real, but tolerable. Then a competitor changes the market, a customer demands a new capability, a regulatory deadline arrives, a supplier exits, or an acquisition requires rapid integration.

What looked like a slowly growing architectural burden becomes immediate. The debt was not created at the moment of crisis. The crisis made the accumulated debt impossible to ignore.

This is one reason static dashboards can be misleading. A system can appear stable because current operations remain stable, even while its capacity to respond to a changed future is deteriorating.

We should be continually asking not just whether the architecture works today, but whether the architecture preserves enough freedom to act tomorrow.

Debt Can Be Moved Instead of Paid

One of the most important consequences of treating TTD architecturally is recognizing that debt can be displaced.

A team may solve a local problem by pushing complexity into another subsystem
A software change may reduce implementation effort while increasing verification burden
A governance decision may shorten one schedule while creating additional integration cost downstream
A workaround may make today’s operation easier while increasing the cognitive burden on the next engineer who must understand it.

As I’ve said in previous posts

Local debt reduction does not imply global TTD reduction.

The organization may celebrate a local improvement while the total burden has merely changed location, changed owner, changed lifecycle phase, or changed timescale.

This is where TTD becomes inseparable from lived architecture.

Debt is not experienced uniformly. It is encountered by particular people, in particular roles, at particular points in the lifecycle.

A verification engineer may encounter debt that remains invisible to the development team
An operator may carry the consequences of a design simplification made years earlier
A manufacturing organization may absorb variability exported by a product architecture optimized for another concern.

The debt is architectural because its consequences cross boundaries.

Encountered Complexity and TTD Form a Coupled System

The previous post in this series introduced encountered complexity as a localized measure of how architectural structure is cognitively experienced by an agent acting within a particular locality.

This gives us a mechanism for understanding how TTD can grow.

When encountered complexity becomes high, people do not simply stop acting. They adapt, defer, simplify, work around, narrow the problem, preserve what they understand, and postpone what they do not understand.

These actions may be entirely rational within the agent’s locality, but a locally rational coping action can impose additional burden on the future.

We can represent this as a simple causal sequence as

$\uparrow \text{CCC} \quad \rightarrow \quad \uparrow \text{deferral pressure} \quad \rightarrow \quad \uparrow \text{TTD}$

The reverse relationship also holds.

Accumulated technical debt creates exceptions, hidden dependencies, historical contingencies, workarounds, fragile interfaces, undocumented assumptions, and verification burdens. These increase the complexity encountered by future agents. We can represent this as

$\uparrow \text{TTD} \quad \rightarrow \quad \uparrow \text{CCC}$

The relationship is better represented as a coupled dynamic

$\text{CCC} \quad \leftrightarrow \quad \text{TTD}$

The coupling may include delay, localization, threshold effects, and nonlinear feedback. High encountered complexity can cause debt to accumulate. Accumulated debt can increase encountered complexity. The result may be a reinforcing cycle in which the system becomes progressively harder to reason about and therefore increasingly likely to generate further debt.

This is why rate of change matters for CCC.

A high but stable encountered complexity may be understood and managed by an experienced team. A rapidly increasing CCC may overwhelm the same team because the cognitive architecture that previously suppressed complexity no longer keeps pace.

In a manner similar to TTD, the relevant diagnostics therefore include not only

$\text{CCC}(t)$

but also

$\frac{d(\text{CCC})}{dt}$

and, when appropriate, the second derivative or acceleration.

The architecture is not merely difficult. It may be becoming difficult faster than the organization can adapt.

The Current Value is Not Enough

Consider two systems with approximately the same TTD.

In the first, the debt is old, understood, localized, and slowly decreasing. In the second, the debt is poorly understood, distributed across layers, increasing rapidly, and coupled to rising encountered complexity.

A single score could make them look equivalent and they are not.

This is the same reason metrics should not be treated as rankings detached from causal context.

A useful TTD diagnostic should ask at least

What are the dominant sources of debt?
Where is the debt localized?
Who encounters its consequences?
Is the burden growing or shrinking?
Which components change slowly?
Which components can change rapidly?
Is slow debt approaching a threshold where it may become fast debt?
Is debt being paid, or merely moved?
How is TTD coupled to encountered complexity?
Is the architecture still aligned with the environment that gives it purpose?

The final question may be the most easily overlooked. A technically healthy system can still be architecturally indebted if it is becoming progressively less able to support the future that the organization actually needs.

TTD Reshapes the Future

Technical debt is often described as an increased future cost.

While this is correct, it is incomplete.

Debt does not merely make a future action more expensive. It can change which future actions remain possible and plausible. Accumulated TTD can make some architectural paths easier because they preserve existing commitments. It can make others prohibitively expensive because they require escaping years of accumulated structure. It can deepen local basins of attraction, increase verification burden, narrow the option frontier, and make deferral progressively more likely.

In that sense, TTD changes the shape of the future decision space. The architecture does not simply carry debt. It begins to steer future decisions through it.

That gives us a more complete dynamic

$\uparrow\,\text{TTD} \, \rightarrow \, \uparrow\,\text{CCC} \, \rightarrow \, \uparrow\,\text{deferral pressure} \, \rightarrow \, \uparrow \, \text{TTD}$

This should not be read as an unavoidable law. Architecture, expertise, investment, governance, verification, and deliberate preservation of decision memory can interrupt the cycle. The diagnostic purpose is to make the cycle visible before it becomes self-reinforcing.

From Debt to Dynamics

The original technical-debt metaphor gave engineering a powerful way to talk about the future consequences of present compromises. The broader concept of Total Technical Debt allows us to ask a harder question

What burdens are being imposed on future action, from all sources, across the architecture and its environment?

Those burdens are not static. They grow and shrink. They move. They interact. They accumulate at different rates. They may remain latent for years and then suddenly become apparent and urgent. They may arise from internal compromise or from external change. They may increase even when the architecture itself remains untouched.

And they are encountered by people.

Once TTD is treated as a dynamic condition rather than a static quantity, the next question becomes unavoidable

What kinds of decisions accelerate TTD, redirect it, or lock it into the architecture’s future?

That is where the causal dynamics of architecture begin.

References

[AACA15] Apostolos Ampatzoglou, Areti Ampatzoglou, Alexander Chatzigeorgiou, and Paris Avgeriou. The financial aspect of managing technical debt: A systematic literature review. Information and Software Technology, 64:52–73, 2015.

[Cun92] Ward Cunningham. The WyCash portfolio management system. In Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA), pages 29–30. ACM, 1992.

[dA19] Rodrigo Rebouças de Almeida. Business-Driven Technical Debt Prioritization. PhD thesis, Federal University of Rio Grande do Norte, 2019.

[dAKT+18] Rodrigo Rebouças de Almeida, Uirá Kulesza, Christoph Treude, D’angellys Cavalcanti Feitosa, and Aliandro Higino Guedes Lima. Aligning technical debt prioritization with business objectives: A multiple-case study. In Proceedings of the International Workshop on Managing Technical Debt, 2018.

[dOM+22] Melo, A., Fagundes, R., Lenarduzzi, V., Santos, W. Identification and measurement of requirements technical debt: A systematic literature review. Journal of Systems and Software, 194:111483, 2022.

[Fow19] Martin Fowler. Technical debt. https://martinfowler.com/bliki/TechnicalDebt.html, 2019. Accessed 2026-07-10.

[Int24] Intel IT. Enterprise technical debt strategy and framework. https://www.intel.com/content/www/us/en/it-management/intel-it-best-practices/enterprise-technical-debt-strategy-and-framework-paper.html, 2019. Accessed 2026-07-10.

[KNO12] Philippe Kruchten, Robert L. Nord, and Ipek Ozkaya. Technical debt: From metaphor to theory and practice. IEEE Software, 29(6):18–21, 2012.

[LLSA22] Ruiyin Li, Peng Liang, Mohamed Soliman, and Paris Avgeriou. Understanding software architecture erosion: A systematic mapping study. Journal of Software: Evolution and Process, 34(3):e2423, 2022.

[MS16] Alan MacCormack and Daniel J. Sturtevant. Technical debt and system architecture: The impact of coupling on defect-related activity. Journal of Systems and Software, 120:170–182, 2016.

[SHG+15] D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Fran.ois Crespo, and Dan Dennison. Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems, volume 28, 2015.