Independent educational resource. Not affiliated with CAST, SonarSource, or any code-analysis vendor. Data sourced from CISQ, Stripe, McKinsey, and DORA reports.

Section V, Taxonomy

Types of technical debt.

Eight categories of debt with cost ranges, warning signs, and remediation strategies, plus Martin Fowler's deliberate vs inadvertent quadrant for the diagnostic question that comes before measurement.

Section II

Fowler's quadrant.

Before measuring debt, classify it. Martin Fowler's quadrant separates debt by intent (deliberate vs inadvertent) and judgement (reckless vs prudent). The quadrant your debt sits in determines whether the right response is process, coaching, refactoring, or stop everything.

<- Deliberate
Inadvertent ->
Section III

Eight categories of debt.

For each category: definition, causes, warning signs, measurement approach, typical cost range, and remediation strategy.

I

Architectural Debt

Risk: High
Causes

Monoliths under load, tight coupling, outdated patterns, unbounded service growth

Warning signs

Deploy fear, change ripple, integration tests slow

How to measure

Module dependency graph density, deploy independence ratio

Typical cost

$200K to $2M+ annually for mid-size teams

Remediation

Strangler fig pattern, bounded context extraction, anti-corruption layers

II

Code Quality Debt

Risk: Medium
Causes

Time pressure, low review rigour, junior team without coaching, copy paste culture

Warning signs

High complexity scores, duplication, magic numbers, methods over 50 lines

How to measure

Cyclomatic complexity, duplication ratio, SonarQube code smells

Typical cost

10 to 20% velocity reduction

Remediation

Linting in CI, complexity ratchet, refactoring sprints, pair programming

III

Test Coverage Debt

Risk: High
Causes

Skipped tests under deadlines, flaky test fatigue, no integration test infrastructure

Warning signs

Production regressions, slow CI, fear of merging, low coverage report

How to measure

Line, branch, mutation coverage, integration test count

Typical cost

$2K to $15K per production incident, increased frequency

Remediation

Coverage gates, mutation testing, integration test infrastructure, contract tests

IV

Dependency Debt

Risk: High (security)
Causes

Update fatigue, breaking changes, transitive dependency lock, abandoned upstream

Warning signs

Stale lockfile, outdated major versions, vulnerability backlog growing

How to measure

Mean dependency age, critical vulnerability count, deprecated API count

Typical cost

3 to 8 engineer days per major upgrade, security incident exposure

Remediation

Renovate or Dependabot, monthly review, replace abandoned dependencies

V

Documentation Debt

Risk: Medium (compounds with attrition)
Causes

Docs as afterthought, no doc review, key engineers leaving, no ADR practice

Warning signs

Onboarding over 4 weeks, tribal knowledge, runbook gaps, stale wiki

How to measure

Onboarding time to first PR, doc currency audit, ADR coverage

Typical cost

2 to 4 weeks slower onboarding per hire, 5 to 10% velocity tax

Remediation

Docs in repo, ADR practice, doc review in PR, living wiki

VI

Infrastructure Debt

Risk: Medium
Causes

Manual deploys, environment drift, no IaC, ad hoc scaling

Warning signs

Deploy hesitation, environment specific bugs, slow recovery, no rollback

How to measure

Deploy frequency, mean time to recover, environment parity score

Typical cost

5 to 15% additional downtime risk, slower delivery

Remediation

IaC adoption, blue green deploys, ephemeral environments, golden paths

VII

Security Debt

Risk: Critical
Causes

Unpatched vulnerabilities, weak auth, exposed secrets, missing threat model

Warning signs

Critical CVEs open over 30 days, secrets in code, auth ad hoc

How to measure

Critical vulnerability count, mean time to patch, secrets scan results

Typical cost

Variable, but a single breach often exceeds total annual debt cost

Remediation

SAST plus DAST in CI, vault all secrets, threat model per feature, regular pen test

VIII

Data Debt

Risk: High at scale
Causes

Schema drift, missing migrations, denormalised under pressure, no data contracts

Warning signs

Inconsistent data models, broken reports, migration fear, ETL fragility

How to measure

Schema drift count, data quality test coverage, contract coverage

Typical cost

Compounds with system count, often invisible until reporting fails

Remediation

Migration discipline, data contracts, lineage tooling, governance

Section IV

Priority matrix.

Not all debt deserves equal urgency. This matrix orders categories by typical risk and remediation cost, so you can pick the right starting point.

CategoryTail riskRemediation costPriority
SecurityCatastrophicMedium1, do first
ArchitecturalHigh, growingHigh2, sequence after security
Test CoverageMedium, frequentMedium3, fund continuously
DataHigh at scaleHigh3, if data complex
DependencyMedium, security adjacentLow to medium4, automate
InfrastructureMediumMedium5, batch with platform work
Code QualityLow individually, compoundsLow per item6, Boy Scout rule
DocumentationLow, rises with attritionLow7, ongoing hygiene
Section V

Common questions.

01Is technical debt always bad?+

No. Deliberate, prudent debt taken to meet a real business deadline can be a sound choice provided three conditions are met: the trade-off is documented, the principal is tracked, and a remediation plan exists. The problem is undocumented, unplanned debt that accumulates without intent. Martin Fowler's quadrant separates the strategic from the negligent.

02Which type of debt costs the most?+

Architectural debt has the largest blast radius because it affects every change. Security debt has the highest tail risk because a single incident can exceed years of accumulated cost. Test coverage debt is the most expensive on a per-incident basis. The right answer depends on your business: a fintech prioritises security, a fast-moving SaaS prioritises architectural.

03How do I know which type I have?+

Run the eight dimension assessment on this site. The dimensions map directly to seven of these eight categories (data debt is the exception, addressed separately for systems with significant data complexity). The dimension scoring lowest is the type you carry most.

04Should I address all eight types in parallel?+

No. Sequential focus beats parallel sprawl. Pick the dimension scoring lowest, dedicate two to four sprints to it, then re-assess. Architectural and security debt are often best addressed first because they have the largest cascading effects on the other categories.