Skip to content
Technical Debt: What It Is and How to Manage It

Technical Debt: What It Is and How to Manage It

DodaTech Updated Jun 19, 2026 6 min read

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:

RecklessPrudent
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%: Critical

CodeSmell 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=myauthtoken

Expected 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.95

Rewriting

Sometimes a component is so tangled that refactoring is riskier than rewriting. Rewrite only when:

  1. The existing code is untestable
  2. Requirements have fundamentally changed
  3. 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 processing

Common 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

  1. What are the four types of technical debt in the quadrant model? Deliberate/Reckless, Deliberate/Prudent, Inadvertent/Reckless, Inadvertent/Prudent.

  2. How does SonarQube calculate the debt ratio? Remediation cost (estimated fix time) divided by total lines of code, multiplied by 100.

  3. 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.

  4. What is the Strangler Fig pattern? Incrementally replacing a legacy component piece by piece until the old system is entirely replaced.

  5. 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

Is technical debt always bad?
No. Prudent, deliberate debt is a valid engineering strategy — you knowingly take a shortcut to meet a deadline, with a plan to fix it later.
What is the difference between technical debt and code smell?
Code smells are symptoms that might indicate debt. Technical debt is the quantified cost of those symptoms. A code smell is the smell; debt is the repair bill.
How often should we measure technical debt?
Every build. Add SonarQube or a similar tool to your CI pipeline so debt ratio is visible on every pull request.
Can technical debt be zero?
No. Every codebase has some debt. Zero debt means zero risk-taking, which means zero innovation. The goal is manageable debt, not no debt.
How do I convince my manager to let me fix debt?
Show the data: time spent on bug fixes in debt-heavy modules, onboarding time for new developers, and velocity decline. Managers respond to metrics, not complaints.

What’s Next

TutorialWhat You’ll Learn
Code Refactoring TechniquesSafe refactoring patterns and practices
Static Code Analysis ToolsAutomated tools for measuring code quality
SonarQube Setup GuideSetting 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