Technical Debt: What It Is and How to Manage It
Technical debt is the implied cost of additional rework caused by choosing an easy solution now instead of a better approach that would take longer — like borrowing time from your future self with interest.
What You’ll Learn
- What technical debt is and the four types in the quadrant model
- How to measure technical debt with SonarQube and other tools
- Strategies for reducing debt: refactoring, rewriting, and retiring
- When it makes sense to accept debt versus fix it
Why Technical Debt Matters
Every shortcut you take today adds interest. A quick hack that saves 2 hours now can cost 2 weeks later when a new feature depends on that code. According to Stripe, developer time wasted on bad code costs the industry $85 billion annually. Teams that ignore technical debt eventually reach a point where every change breaks something — the “brittle codebase” trap.
DodaZIP tracks technical debt in its compression engine using SonarQube metrics. When debt exceeds a threshold, the team allocates a sprint to refactor before adding new features.
Learning Path
flowchart LR
A[Code Review] --> B[Technical Debt<br/>You are here]
B --> C[Code Smells Detection]
C --> D[Static Analysis]
D --> E[Clean Architecture]
style B fill:#f90,color:#fff
The Quadrant Model
Martin Fowler’s technical debt quadrant classifies debt into four types:
| Reckless | Prudent | |
|---|---|---|
| Deliberate | “No time to design — ship it” | “We know this isn’t ideal, but we need to ship now. We’ll fix it next sprint.” |
| Inadvertent | “I didn’t know about design patterns” | “We learned better architecture from the last project. Let’s refactor.” |
Deliberate debt is a conscious trade-off. Inadvertent debt comes from ignorance or skill gaps. Reckless debt has no plan to repay. Prudent debt has a known repayment plan.
Measuring Technical Debt
SonarQube Metrics
SonarQube calculates a Debt Ratio based on the estimated time to fix all issues:
Debt Ratio = (Remediation Cost / Total Lines of Code) × 100
Thresholds:
- < 5%: Healthy
- 5-10%: Watch
- 10-20%: Action needed
- > 20%: CriticalCodeSmell Density
SonarQube also tracks code smell density per 1,000 lines. Track this over time — a rising trend means debt is accumulating faster than it’s being fixed.
# SonarQube CLI example
sonar-scanner \
-Dsonar.projectKey=myapp \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=myauthtokenExpected output:
INFO: Analysis total time: 42.315s
INFO: Debt ratio: 3.2% (2h 15min)
INFO: Code smells: 147 (1.2 per 1,000 lines)Strategies to Reduce Debt
Refactoring
Improve the internal structure without changing external behavior. Refactor in small, safe steps with tests.
# BEFORE: Duplicated logic
def calculate_discount_standard(price):
if price > 100:
return price * 0.9
return price
def calculate_discount_premium(price):
if price > 100:
return price * 0.85
return price * 0.95
# AFTER: Extracted with parameter
def calculate_discount(price, premium=False):
rate = 0.85 if premium else 0.9
if price > 100:
return price * rate
return price if not premium else price * 0.95Rewriting
Sometimes a component is so tangled that refactoring is riskier than rewriting. Rewrite only when:
- The existing code is untestable
- Requirements have fundamentally changed
- The rewrite can be done incrementally (Strangler Fig pattern)
Retiring
Delete dead code, unused endpoints, and deprecated modules. Every line of unused code is debt that still costs: it must be compiled, tested, and understood by future developers.
# Deprecated — remove after migration period
import warnings
warnings.warn(
"LegacyAPI is deprecated. Use NewAPI instead.",
DeprecationWarning,
stacklevel=2
)When to Accept vs Fix Debt
Accept debt when:
- The feature has time-to-market pressure (MVP launch)
- The code will be replaced soon anyway
- The cost of fixing exceeds the cost of living with it
Fix debt when:
- Adding new features becomes slow and risky
- Onboarding new team members takes too long
- Bug fix rate increases in a specific module
- The debt ratio in SonarQube exceeds your team’s threshold
The Boy Scout Rule
Leave the codebase cleaner than you found it. When you touch a file for any reason, fix one small piece of debt — rename a bad variable, extract a function, add a missing test. Small improvements compound.
# While adding a new feature, clean up as you go
def process_user_data(data):
# Renamed from vague 'x' to descriptive 'data'
# Extracted validation into separate function
if not validate_user_data(data):
raise ValueError("Invalid user data")
# ... rest of processingCommon Errors
1. Confusing Debt with Bad Code
Not all bad code is technical debt. Debt is a conscious trade-off. Bad code written by incompetence is just bad code.
2. Trying to Fix All Debt at Once
A “big refactoring” sprint often introduces new bugs. Fix debt incrementally — the Strangler Fig pattern replaces components one at a time.
3. Not Tracking Debt
If you can’t measure your debt ratio, you can’t manage it. Run SonarQube or a similar tool in your CI pipeline.
4. Ignoring Inadvertent Debt
Deliberate debt you planned. Inadvertent debt is more dangerous because you don’t know it exists. Code reviews catch inadvertent debt.
5. Using “Technical Debt” as an Excuse
Not every shortcut is strategic debt. “No time” is often a symptom of poor prioritization, not a valid architectural decision.
6. Forgetting Tests in Refactoring
Refactoring without tests is dangerous. Always have a test suite that covers the behavior before you change the structure.
Practice Questions
What are the four types of technical debt in the quadrant model? Deliberate/Reckless, Deliberate/Prudent, Inadvertent/Reckless, Inadvertent/Prudent.
How does SonarQube calculate the debt ratio? Remediation cost (estimated fix time) divided by total lines of code, multiplied by 100.
When should you accept technical debt? When time-to-market pressure is critical, the code will be replaced soon, or the fix cost exceeds the carrying cost.
What is the Strangler Fig pattern? Incrementally replacing a legacy component piece by piece until the old system is entirely replaced.
What is the Boy Scout Rule in software? Leave the codebase cleaner than you found it — fix one small piece of debt every time you touch a file.
Challenge: Run SonarQube (or a free alternative like CodeClimate) on a personal or open-source project. Document the debt ratio, top 5 issues, and create a plan to reduce the ratio by 50% in two sprints.
FAQ
What’s Next
| Tutorial | What You’ll Learn |
|---|---|
| Code Refactoring Techniques | Safe refactoring patterns and practices |
| Static Code Analysis Tools | Automated tools for measuring code quality |
| SonarQube Setup Guide | Setting up SonarQube for your team |
Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. Updated 2026-06-19.
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro