Module 1.2: Technical Debt Classification
Master the four pillars of technical debt: Code, Architecture, Infrastructure, and Dependencies. Learn to classify, quantify, and prioritize debt remediation using the PDI framework.
🎯 What You'll Learn
- ✓ How to identify and measure code-level debt (duplication, complexity, coverage)
- ✓ How to detect architecture debt before it becomes architecture insolvency
- ✓ How to audit infrastructure for zombie resources and pipeline debt
- ✓ How to use the PDI framework to calculate total debt in dollars
Lesson 1: Code-Level Debt
Code debt is the most visible form of technical debt — duplicated code, overly complex functions, missing tests, and unclear naming. It's the easiest to measure and often the least economically impactful.
Copy-pasted code that should be abstracted into shared functions. Creates maintenance multiplication — every bug fix requires N changes.
Number of independent paths through a function. High complexity = hard to test, hard to modify, high bug probability.
Percentage of code paths exercised by automated tests. Low coverage means changes are high-risk — you don't know what you'll break.
Code that exists in the codebase but is never executed. Consumes cognitive load, increases build times, and creates false complexity.
Run a static analysis tool (SonarQube, CodeClimate, or ESLint) on your codebase. Document the top 10 code debt items by severity and estimate the hours required to fix each.
Lesson 2: Architecture Debt
Architecture debt occurs when the system structure no longer matches the business reality. It's harder to see than code debt but far more expensive to fix.
When a "monolith" can't be modified in one area without affecting others. Every change requires full regression testing because boundaries are unclear.
The most expensive architecture debt: a shared component that serves two different use cases poorly. Fixing it means untangling every consumer.
Architecture designed for 1K users serving 100K users. The system "works" but response times degrade, costs spike, and outages increase.
Draw your system's current architecture. Circle areas where a change in one component requires changes in 3+ other components. These are your architecture debt hotspots.
Lesson 3: Infrastructure Debt
Infrastructure debt hides in your cloud accounts, CI/CD pipelines, and operational tooling. It's often invisible until it causes an outage or a surprising cloud bill.
Resources running that serve no current purpose — old staging environments, unused databases, forgotten Lambda functions. They cost money 24/7.
Operational procedures that require human execution instead of automation. Each manual step is a failure point and a bottleneck.
Build times over 30 minutes, flaky tests, manual deployment steps. Slow pipelines directly reduce deployment frequency (DORA metric).
Audit your cloud account for zombie resources. List every resource and its last meaningful access date. Calculate the monthly cost of zombie infrastructure.
Lesson 4: The PDI Framework
The Product Debt Index (PDI) combines all four types of technical debt into a single economic score. It answers: "How much is our technical debt costing us in real dollars?"
PDI = (Innovation Tax × Engineering Budget) + (Estimated Remediation Cost) + (Projected Velocity Loss). This produces a dollar amount of total debt exposure.
The quarter when maintenance costs consume 100% of engineering capacity. No new features can be built. Calculated from current debt trend.
The percentage of each sprint spent on maintenance vs. new features. Like debt service on a loan — how much of your "income" goes to servicing existing debt.
Use the free PDI calculator at /tools/pdi to generate your organization's Product Debt Index. Share the results with your engineering leadership.
📊 Module Assessment
Complete to demonstrate mastery of Module 1.2: