Types of Technical Debt: Intentional, Unintentional and the Quadrant Model

In this article:

• Why classifying types of technical debt matters
• The technical debt quadrant: Fowler’s framework
• Intentional technical debt: when it is valid
• Unintentional technical debt: where most of it hides
• Applying the technical debt analogy in practice
• Conclusion

Why classifying types of technical debt matters

Not all technical debt is the same. Treating a deliberate trade-off the same way you treat accumulated ignorance leads to poor decisions about where to invest remediation effort. Understanding the types of technical debt gives engineering leaders the vocabulary to have precise conversations about what they have, why it exists and what to do about it.

The classification also changes the conversation with non-technical stakeholders. A board or a CFO who hears “we have technical debt” has no useful information. A board that hears “we have deliberate, documented shortcuts worth an estimated eight weeks of engineering time, and we have inadvertent architectural problems in the payments module that are directly causing three of our five monthly incidents” can make a funding decision.

Across hundreds of codebases, the pattern is consistent: organizations that categorize their debt by type address it more efficiently than those that treat it as a single undifferentiated problem. The categories determine the remediation strategy, the sequencing and the ownership.

The technical debt quadrant: Fowler’s framework

Martin Fowler’s Technical Debt Quadrant organizes debt on two axes. The first axis distinguishes deliberate from inadvertent debt. The second distinguishes prudent from reckless decisions. The intersection of these two axes produces four quadrants.

Reckless and Deliberate. “We do not have time to design this properly.” The team knows a better approach exists and ignores it under pressure. This quadrant generates the most expensive debt because it is invisible by design. Nobody documented it, nobody owns it and nobody plans to fix it. It surfaces as mysterious bugs, unexplained performance degradation and systems that seem to break for no reason.

Prudent and Deliberate. “We will ship this now and refactor after launch.” The team understands the trade-off, records it explicitly and schedules remediation. This is the only quadrant where the technical debt analogy holds cleanly: it is a conscious loan with an intended repayment plan. It remains manageable as long as the repayment actually happens.

Reckless and Inadvertent. “What is an abstraction layer?” The team did not know they were creating a problem. This quadrant is common in codebases written by teams without architectural experience or with no senior oversight. The debt is invisible not because someone hid it but because no one knew it was being created.

Prudent and Inadvertent. “Now we understand the domain better, we should have structured it differently.” The team made a reasonable decision with the information available. Later experience revealed a better approach. This is the most forgiving quadrant and the most honest reflection of how software development actually works.

Intentional technical debt: when it is valid

Intentional technical debt is a valid business tool when three conditions are met. First, the team explicitly understands what they are giving up. Second, the shortcut is documented in a way that a future engineer can find and understand. Third, there is a plan, with an actual date or milestone, to address it.

When all three conditions are present, intentional technical debt functions like a short-term loan. It accelerates delivery at a known cost, with a defined repayment schedule. The engineering team retains visibility over it, the organization retains control and the debt does not compound silently.

The most common failure mode is that teams satisfy condition one but not conditions two and three. They understand the trade-off at the moment of decision but fail to document it or plan its resolution. The knowledge lives in the head of whoever wrote the code. When that person leaves, the debt becomes invisible, and invisible debt is the most expensive kind.

A practical test: can a new engineer joining the team today, without talking to anyone, find and understand every deliberate shortcut in the codebase? If not, your intentional technical debt has become unintentional.

See our tech debt solution for how we approach the discovery and documentation phase in client codebases.

Unintentional technical debt: where most of it hides

Unintentional technical debt is debt no one planned. It is not the result of a trade-off. It is the result of limited knowledge, insufficient process or scale outpacing the architectural foundations.

The most common forms: a system built as a monolith because the team had not yet learned about bounded contexts; a data model designed for a workload that was ten times smaller than the current one; authentication logic copied between services because there was no shared infrastructure component; configuration management done through environment variables in a codebase that has grown to forty services.

None of these are failures of intent. They are failures of information or capacity. Treating them as moral failures leads engineering teams to be defensive about the codebase rather than honest about it. Treating them as natural artifacts of a growing system and addressing them systematically is what separates organizations that manage debt from those that are managed by it.

The discovery process for unintentional debt requires static analysis, dependency mapping and code health metrics. It cannot be done accurately by asking engineers to self-report, because the nature of the debt is that it is not visible to the people working inside it every day. Our software due diligence assessments use automated analysis to surface it objectively.

Applying the technical debt analogy in practice

The technical debt analogy is a communication tool as much as a technical one. When used correctly, it translates engineering problems into business language.

The principal (the original shortcut) is the amount of effort saved when the decision was made. The interest (the ongoing cost) is the friction added to every subsequent change that touches that area of the codebase. The total debt (principal plus interest) is what remediation will cost. The opportunity cost is what the organization could build if that capacity were freed.

For engineering leaders, the most useful application of the analogy is the cost projection. If we know that a specific architectural problem is adding four hours of friction to every deployment, and we deploy twice a week, we are paying eight engineer-hours per week in interest. Over a year, that is 416 hours: roughly a quarter of a full-time engineer. The question then becomes: does remediating this problem cost less than 416 hours of engineering time? Usually yes, significantly.

This framing makes technical debt a business decision rather than a technical preference. It is the framing that gets remediation work prioritized at the board level.

Conclusion

The types of technical debt, whether intentional or unintentional, prudent or reckless, require different responses and different levels of urgency. The quadrant model is the most practical tool for organizing those responses.

What matters most to engineering leaders is not the theoretical categories but the operational question: which debt, in which part of the system, is most directly blocking the outcomes the organization needs? That question requires accurate assessment, not just classification.

Eden Technologies has helped over 200 organizations move from vague awareness of debt to structured remediation plans with measurable outcomes. The process begins with a concrete assessment of what exists.

Does your codebase have these problems? Let’s talk about your system