The Seven Categories of Technical Debt (Kruchten, Nord, Ozkaya)
Updated 17 April 2026
Martin Fowler's quadrant classifies debt by intent (was it deliberate?). Kruchten, Nord, and Ozkaya's 2012 taxonomy classifies debt by what it is. Both views are needed: the quadrant tells you why you have the debt; the taxonomy tells you what type of debt it is and how to address it.
Code Debt
Structural problems at the implementation level: code smells, dead code, duplicated logic, excessively long methods, poor naming, commented-out code.
Real-World Example
A helper function that converts currency codes was copy-pasted 23 times across the codebase because nobody knew it already existed. Each copy has slightly different rounding logic.
Remediation Pattern
Refactor and centralise at code-review time. Boy-scout rule works well here. Automated quality gates in CI block new instances.
How to Measure
SonarQube SQALE score, cyclomatic complexity, code duplication percentage.
Typical Interest Rate
Low-to-medium. High churn code with code smells has high interest; dead code has zero interest.
Design Debt
Pattern violations, leaky abstractions, wrong domain model, anemic domain model, feature envy, inappropriate intimacy between classes or modules.
Real-World Example
The domain model mirrors the database schema 1:1. Every domain operation is a raw SQL call. Adding a new business rule requires touching 12 files and rewriting 3 database queries.
Remediation Pattern
Introduce domain objects progressively. Apply the strangler fig pattern to migrate from data-driven to domain-driven design over several sprints.
How to Measure
Afferent/efferent coupling metrics, dependency analysis tools (NDepend, JArchitect, CodeClimate).
Typical Interest Rate
High. Design debt in frequently-changed modules accumulates compound interest rapidly.
Architecture Debt
System-level coupling, wrong service boundaries, circular dependencies between services, missing resilience patterns, anti-patterns at the integration level.
Real-World Example
The monolith that should be three services: an order-management bounded context, a fulfilment context, and a billing context. All three are wired together via shared database tables. Any change touches all three implicitly.
Remediation Pattern
Architecture Decision Records (ADRs) to prevent future accumulation. Strangler fig to refactor existing boundaries. Team-level ownership of bounded contexts. This category typically requires the most dedicated sprint budget.
How to Measure
Service dependency mapping, module coupling analysis, blast-radius estimates for changes.
Typical Interest Rate
Very high. Architecture debt multiplies the cost of every feature built in the wrong boundary.
Test Debt
Missing test coverage, flaky tests, slow test suites, tests that test implementation not behaviour, tests that require manual setup, missing integration tests for critical paths.
Real-World Example
The 40-minute CI pipeline that the team has started skipping. There are 2,000 unit tests, but 300 of them are flaky and fail randomly on the CI server. The team has learned to re-run failed pipelines. Nobody investigates the flakiness.
Remediation Pattern
Delete flaky tests rather than tolerate them. Invest in faster test infrastructure before adding more tests. Prioritise tests on the highest-churn code (see CodeScene). DORA correlates strong testing practice with elite delivery performance.
How to Measure
Coverage percentage (starting point), flakiness rate, CI pipeline duration, change failure rate (DORA).
Typical Interest Rate
High. Every untested change is a blind flight. Test debt enables all other debt categories.
Documentation Debt
Missing Architecture Decision Records, stale READMEs, tribal knowledge that lives in one person's head, missing onboarding guides, undocumented APIs.
Real-World Example
The authentication service that only Alice understands. Alice joined in 2019. She has moved to another team. The service processes 10 million requests per day. Nobody else knows how the session token is generated.
Remediation Pattern
ADRs written when decisions are made (not retroactively). Documentation-as-code in the same repo as the service. Architecture diagrams auto-generated from code where possible. Pair programming on undocumented areas.
How to Measure
Truck factor (how many engineers can each service lose before it becomes inoperable), onboarding time for new engineers, number of services with zero ADRs.
Typical Interest Rate
Medium in normal times. Exponential during team changes (onboarding, departures, reorganisations).
Infrastructure Debt
Outdated cloud configuration, unpatched server images, mutable servers that have been hand-configured over years, missing observability, expired TLS certificates, dependency versions that are multiple major versions behind.
Real-World Example
The pets-not-cattle EC2 instance that has been running since 2017. It has been hand-patched by three different engineers. Nobody knows what is installed on it. It runs a cron job that 40% of the platform depends on. Nobody wants to touch it.
Remediation Pattern
Renovate/Dependabot for automated dependency updates. Infrastructure-as-code (Terraform, Pulumi) for all new resources. Quarterly dependency-update sprints. SBOMs (Software Bill of Materials) for auditability.
How to Measure
Mean time to patch critical CVEs, number of services on deprecated dependency versions, percentage of infrastructure defined as code (IaC coverage).
Typical Interest Rate
Low until a CVE hits, then catastrophic. Log4Shell was an extreme case.
Build Debt
Non-reproducible builds, manual deployment steps, CI/CD rot, deployment runbooks that only the original author can execute, missing rollback procedures.
Real-World Example
The deployment runbook with 47 manual steps that only the original deployment engineer (who left in 2021) could execute without errors. The current team takes 4 hours to deploy to production and averages 1 incident per deploy. Deployments happen monthly.
Remediation Pattern
Automate the deployment runbook into a pipeline one step at a time. Start with the steps most likely to cause errors. Every manual step is a compounding interest payment. Target: full automation, zero manual steps, any engineer can deploy.
How to Measure
Deployment frequency (DORA), mean time to restore (DORA), percentage of steps in deployment that are automated.
Typical Interest Rate
High for teams that need to move fast. Build debt directly limits deployment frequency, which DORA correlates with elite performance.
Which Category to Tackle First
Architecture and test debt are typically the highest-leverage starting points. Architecture debt because it multiplies the cost of every other category -- you cannot effectively address code debt in the wrong architecture. Test debt because it is the safety net that makes addressing all other debt safe.
- Test debt first -- you need a safety net before refactoring anything else. Without tests, reducing debt risks introducing regressions.
- Architecture debt second -- wrong boundaries make every other change more expensive. Fix the structure before optimising the content.
- Build debt third -- automate deployment so you can deploy the fixes above safely and frequently.
- Documentation debt in parallel -- the ADRs you write during the above changes prevent the same mistakes recurring.
- Design and code debt last -- high-ROI, but lower urgency than the structural categories above.
- Infrastructure debt: continuous -- dependency updates should be automated and never allowed to fall behind more than one major version.
Continue reading:
Sources
- Kruchten, P., Nord, R. L., Ozkaya, I. Technical Debt: From Metaphor to Theory and Practice. IEEE Software, 2012.
- Dagstuhl Workshop. Managing Technical Debt in Software Engineering. 2015.
- Fowler, M. TechnicalDebtQuadrant. martinfowler.com, 2009.
- Google DORA. State of DevOps Report 2024.