Technical Debt Management

Overview

Technical debt represents the implied cost of future rework required when choosing an expedient solution over a better approach that would take longer. Like financial debt, technical debt accumulates "interest" in the form of increased maintenance costs, slower development velocity, and higher risk of defects.

Understanding technical debt requires recognizing that not all debt is bad. Just as financial debt can enable valuable investments (like a mortgage), technical debt can strategically accelerate time-to-market. The key is distinguishing between deliberate, managed debt and accidental, untracked debt. Deliberate debt involves conscious tradeoffs documented through Architecture Decision Records, while accidental debt accumulates through lack of knowledge or attention.

The "interest" on technical debt compounds exponentially. Code that's 10% harder to understand doesn't just slow development by 10% - it slows onboarding, increases bug rates, makes refactoring riskier, and eventually creates areas of the codebase that nobody wants to touch. This guide provides frameworks for identifying, measuring, prioritizing, and systematically addressing technical debt.

Core Principles

Visibility: All technical debt must be documented, tracked, and visible to stakeholders. Hidden debt cannot be managed effectively
Intentionality: Distinguish between deliberate debt (conscious tradeoffs) and accidental debt (results of carelessness or lack of knowledge)
Balance: Strategic debt can accelerate delivery when the benefits outweigh long-term costs
Measurement: Track debt using concrete metrics (complexity, coverage, dependency age) rather than subjective assessment
Prevention: Build processes that prevent new debt from accumulating through automated quality gates
Continuous Paydown: Regularly allocate time to address existing debt rather than waiting for dedicated "cleanup sprints"

Understanding Types of Technical Debt

Technical debt manifests in multiple forms across the software development lifecycle. Recognizing these different types enables more effective identification and prioritization.

Code Debt

Code debt arises from implementation shortcuts that sacrifice long-term maintainability for short-term delivery speed. This is the most visible form of debt because developers encounter it daily during feature work.

Common manifestations:

Duplication occurs when identical or nearly-identical code exists in multiple locations. This violates the DRY (Don't Repeat Yourself) principle and creates a maintenance burden because any change to the logic requires finding and updating all copies. Developers often miss some instances, leading to inconsistent behavior.

// High code debt: duplicated validation logic across multiple functions
function processPayment(amount: number, userId: string) {
  if (amount <= 0) throw new Error('Invalid amount');
  if (!userId || userId.length === 0) throw new Error('Invalid user');
  // payment processing logic
}

function refundPayment(amount: number, userId: string) {
  if (amount <= 0) throw new Error('Invalid amount');
  if (!userId || userId.length === 0) throw new Error('Invalid user');
  // refund processing logic
}

// Better approach: extract shared validation
function validatePaymentRequest(amount: number, userId: string) {
  if (amount <= 0) throw new Error('Invalid amount');
  if (!userId || userId.length === 0) throw new Error('Invalid user');
}

function processPayment(amount: number, userId: string) {
  validatePaymentRequest(amount, userId);
  // payment processing logic
}

function refundPayment(amount: number, userId: string) {
  validatePaymentRequest(amount, userId);
  // refund processing logic
}

The refactored version centralizes validation logic. When validation requirements change (for example, adding a maximum amount check), you modify one function instead of hunting through the codebase for all validation instances.

Poor naming forces developers to constantly decipher intent. Variables named data, temp, x or functions named doStuff, process provide no semantic information, requiring developers to read implementation details to understand purpose.

Complex methods with high cyclomatic complexity (typically above 10-15 decision points) become difficult to understand, test thoroughly, and modify safely. Each additional conditional path increases the cognitive load required to reason about the function's behavior.

Tight coupling between components means changes in one area ripple through many others. When a database model change requires updates to controllers, services, and UI components, the coupling creates fragility and slows development.

Missing abstractions occur when repeated patterns haven't been extracted into reusable components. Every developer reimplementing the same pattern increases the chance of subtle differences and bugs.

Architecture Debt

Architecture debt emerges from structural decisions that limit system scalability, flexibility, or maintainability. This debt type is particularly insidious because it affects the entire system and typically requires significant effort to remediate.

Common manifestations:

Monolithic architecture packages all functionality into a single deployable unit. This creates deployment bottlenecks - any change requires deploying the entire system, increasing risk and slowing release cycles. Teams cannot deploy independently, scaling requires scaling everything (not just bottleneck components), and a bug in one area can crash the entire system.

Tight service coupling occurs when services directly call each other synchronously in complex dependency chains. This creates cascading failures (if Service A depends on B, which depends on C, then C's failure affects A), prevents independent deployment (deploying A might break B), and makes it impossible to scale services independently.

The diagram shows how synchronous coupling creates fragility - a failure in the Notification Service propagates up the call chain, potentially failing the entire user request even though notification is not critical to order processing.

A better architecture uses asynchronous messaging for non-critical paths and implements circuit breakers for resilience (see our Spring Boot Resilience guide).

Missing abstraction layers violate separation of concerns. Direct database access from presentation components makes it impossible to change persistence mechanisms, prevents applying consistent business rules, and creates tight coupling that prevents independent testing.

Technology lock-in occurs when excessive dependence on vendor-specific features prevents migration. This exposes you to pricing changes, technology obsolescence, and difficulty hiring developers familiar with niche technologies.

Scalability limitations mean architecture works at current scale but cannot handle anticipated growth. By the time growth materializes, you're doing expensive rewrites under pressure with users experiencing degraded performance.

Architecture debt compounds over time because it creates path dependencies. The longer a monolith exists, the more intertwined its components become, making decomposition progressively harder.

Test Debt

Test debt reflects inadequate or missing automated testing, increasing regression risk and slowing development velocity. The lack of a safety net makes developers hesitant to refactor, allowing code quality to degrade.

Common manifestations:

Low test coverage means code paths exist without automated verification. Changes in those areas cannot be validated automatically, requiring expensive and error-prone manual testing. This slows development and allows bugs to slip into production.

Brittle tests fail for unrelated changes (high false positive rate). When tests fail intermittently or due to irrelevant changes, developers lose trust and eventually ignore test failures. This defeats the purpose of automated testing entirely.

Slow test suites taking more than 10-15 minutes create friction in the development cycle. Developers stop running tests frequently, missing failures until CI runs. This delays feedback and makes debugging harder because the developer has moved on to other work.

Missing integration tests mean that while individual components might work correctly in isolation, their interactions remain unverified. Integration bugs only surface in production where they're expensive to fix and harm user experience.

No mutation testing prevents verifying that tests actually detect defects. You might have 90% line coverage, but if the tests don't actually assert anything meaningful, they provide false confidence. See our Mutation Testing guide for comprehensive coverage measurement using PITest (Java) or Stryker (JavaScript/TypeScript).

The interest on test debt manifests as bugs reaching production, longer debugging cycles, and hesitation to refactor because changes cannot be validated quickly. Teams with test debt often say "we can't afford to write tests" when in reality, they can't afford not to - the bugs and slow development cost far more than test investment.

Documentation Debt

Documentation debt accumulates when written explanations fail to keep pace with code evolution. This creates information asymmetry where knowledge exists only in a few developers' heads.

Common manifestations:

Outdated documentation describing old behavior actively misleads developers. They waste time trying to understand why their implementation doesn't match the documentation before discovering the documentation is wrong. This is worse than no documentation because it erodes trust.

Missing API documentation forces developers to read implementation code to understand how to use APIs. This is slow and error-prone - implementation details might not reveal all edge cases, assumptions, or error conditions.

No architecture diagrams mean new team members take months to build accurate mental models of system structure. Existing team members maintain inconsistent mental models, leading to divergent assumptions during design discussions.

Undocumented decisions create institutional amnesia. Six months after an architectural decision, nobody remembers why that choice was made. This leads to repeated debates, reversal of well-considered decisions, or fear of changing things "because there must have been a reason." Architectural Decision Records solve this by documenting both the decision and its reasoning.

Incomplete runbooks extend incident recovery time. When production fails at 2 AM, incomplete documentation means engineers improvise under stress, increasing the likelihood of mistakes that worsen the situation.

Documentation debt has a multiplicative effect - it slows every future developer who needs to understand the system and increases the likelihood of incorrect assumptions leading to bugs.

Infrastructure Debt

Infrastructure debt involves outdated tooling, deployment processes, and operational practices. This debt often remains invisible until it causes production incidents or prevents scaling.

Common manifestations:

Manual deployment processes requiring human intervention create opportunities for errors (missed steps, wrong environment, incorrect configuration), slow release velocity, and limit deployment frequency. Organizations with manual deployments often deploy only weekly or monthly, batching changes and increasing risk.

Outdated dependencies with known security vulnerabilities expose the system to exploits. Additionally, falling too far behind makes future upgrades harder because breaking changes accumulate. Upgrading from Spring Boot 3.0 to 3.1 is straightforward; upgrading from 2.0 to 3.1 requires handling years of breaking changes simultaneously.

Insufficient monitoring means you discover issues when users report them rather than through proactive alerts. By the time users notice, the problem has likely impacted many transactions. Our Observability guide covers implementing comprehensive monitoring.

No disaster recovery plan means data loss during failures. Without tested backup and recovery procedures, you cannot confidently estimate recovery time objectives (RTO) or recovery point objectives (RPO). "Testing" recovery during an actual disaster is expensive.

Configuration drift occurs when environment-specific configuration isn't managed as code. Development, staging, and production environments diverge, causing "works on my machine" problems that are difficult to diagnose because you cannot reliably reproduce production conditions.

Infrastructure debt increases operational costs (more time spent on manual processes and incident response) and extends incident response times because the systems supporting development and operations are inefficient.

Identifying and Cataloging Debt

Systematic identification of technical debt prevents it from hiding until it becomes a crisis. Multiple detection methods capture different types of debt.

Code Smells and Static Analysis

Code smells are surface indicators suggesting underlying problems. While not bugs themselves, they correlate with defect density and maintenance difficulty. Automated tools detect many of these patterns without human intervention, enabling continuous monitoring.

Common code smells:

Long methods (exceeding 50-100 lines) typically handle multiple responsibilities. This violates the Single Responsibility Principle and makes the method difficult to understand, test, and modify. Extract helper methods to clarify intent and reduce complexity.

Large classes with dozens of methods or hundreds of lines indicate a God Object that knows or does too much. These classes become change bottlenecks because unrelated features are tangled together.

Long parameter lists (more than 3-4 parameters) often indicate missing abstractions. Consider introducing a parameter object or builder pattern to group related parameters.

Feature envy occurs when a method primarily operates on data from another class. This suggests the method belongs in that other class, closer to the data it manipulates.

Primitive obsession means using primitive types (strings, integers) instead of domain objects. Using String for email addresses misses opportunities for encapsulation (validation, formatting) and type safety.

Static analysis tools:

SonarQube provides a technical debt ratio, highlighting code that violates quality rules with estimated remediation time. It tracks issues over time, showing whether debt is growing or shrinking. Integration with CI/CD pipelines prevents new debt from being introduced.

ESLint (TypeScript/JavaScript) and Checkstyle (Java) enforce coding standards automatically, catching issues like unused variables, inconsistent formatting, and common bug patterns.

CodeClimate assigns maintainability scores to files and tracks code churn combined with complexity. Files with high churn and high complexity are prime refactoring candidates because they're frequently modified yet difficult to understand.

SpotBugs/FindBugs (Java) detect bug patterns and potential runtime errors through static analysis, such as null pointer dereferences, resource leaks, and concurrency issues.

These tools integrate into CI/CD pipelines to prevent new debt (see our Pipelines guide for implementation patterns).

Complexity Metrics

Quantitative metrics provide objective measurements of code complexity that correlate with defect density and maintenance costs.

Cyclomatic Complexity counts the number of linearly independent paths through code by measuring decision points (if statements, loops, case statements). A method with cyclomatic complexity of 15 has 15 different execution paths that should ideally be tested. Higher complexity correlates with more difficult testing and higher defect rates.

The metric was developed by Thomas McCabe in 1976 based on graph theory. Each decision point in code creates a branch in the control flow graph, and cyclomatic complexity measures the number of linearly independent paths through that graph. Research consistently shows that functions exceeding complexity 10-15 have significantly higher defect rates.

Functions exceeding this threshold should be refactored into smaller, single-purpose functions. This isn't just aesthetic - it's a proven leading indicator of bugs.

Cognitive Complexity measures how difficult code is for humans to understand. Unlike cyclomatic complexity, it penalizes nested structures more heavily because they require maintaining more context. Code with deeply nested conditions is harder to reason about even if the cyclomatic complexity is moderate.

// High cognitive complexity due to nesting (cognitive complexity: 8)
public boolean validatePayment(Payment payment) {
    if (payment != null) {
        if (payment.getAmount() != null) {
            if (payment.getAmount().compareTo(BigDecimal.ZERO) > 0) {
                if (payment.getAmount().compareTo(MAX_AMOUNT) <= 0) {
                    return true;
                }
            }
        }
    }
    return false;
}

// Lower cognitive complexity using guard clauses (cognitive complexity: 4)
public boolean validatePayment(Payment payment) {
    if (payment == null) return false;
    if (payment.getAmount() == null) return false;
    if (payment.getAmount().compareTo(BigDecimal.ZERO) <= 0) return false;
    if (payment.getAmount().compareTo(MAX_AMOUNT) > 0) return false;
    return true;
}

The second version has the same number of decision points but lower cognitive complexity because the guard clause pattern eliminates nesting. This is easier to understand because you can process each condition independently without maintaining nested context.

Code Churn measures how frequently files change. Files that change often combined with high complexity indicate volatile areas requiring frequent modifications. These are prime candidates for refactoring because they're both difficult to understand and frequently touched - the debt accumulates interest rapidly.

Tools like SonarQube and CodeClimate track these metrics over time, showing whether code quality is improving or degrading.

Manual Code Review Indicators

Experienced developers recognize patterns during code review that indicate accumulating debt. Encouraging team members to flag these issues during code review creates a feedback loop for identifying debt before it gets merged.

Hesitation to modify code serves as a leading indicator of debt. When developers avoid touching certain areas because they're "fragile" or "complex," that fear represents real cost. The code is communicating that it's difficult to change safely.

Frequent bug fixes in the same area suggest underlying structural problems rather than superficial bugs. If the same module requires repeated fixes, the root cause likely lies in the module's design, not individual bugs.

Difficulty understanding code during review indicates problems. If multiple reviewers struggle to understand code's intent, it needs clarification through refactoring or documentation. Code is read far more often than it's written, so optimizing for readability is critical.

Extensive comments explaining logic can be a smell. While some comments are helpful, extensive comments explaining convoluted logic often indicate the code itself should be simplified. As Martin Fowler says, "When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous."

Workarounds and hacks with comments like "temporary fix" or "TODO: refactor this" explicitly acknowledge debt. These TODOs should be tracked in your debt register rather than left in comments where they're easily forgotten.

Performance and Operational Signals

Production systems provide signals about technical debt through their operational characteristics. These signals often reveal infrastructure and architecture debt that isn't visible in code review.

Slow build times exceeding 10-15 minutes reduce developer productivity by creating long feedback loops. Developers lose context while waiting for builds, run builds less frequently (missing failures earlier), and waste significant time. Slow builds often indicate excessive dependencies, poor build configuration, or architectural issues like tight coupling.

Deployment frequency decline suggests increasing deployment risk from lack of automation or accumulated complexity. If deployments become less frequent over time, teams are implicitly acknowledging increased risk, which points to underlying debt.

Increasing bug escape rate (percentage of bugs reaching production) indicates insufficient testing coverage or increasing system complexity that outpaces test growth. Track this metric over time to identify trends.

Long time-to-resolution for incidents suggests insufficient observability or overly complex systems. If incident resolution takes progressively longer, you're accumulating debt in either monitoring/logging infrastructure or system design.

These metrics should be tracked in your observability platform and reviewed regularly in retrospectives.

Prioritization Frameworks

Not all debt is equally urgent. Effective prioritization ensures limited refactoring time addresses the highest-impact debt. Without prioritization, teams address easy or interesting debt rather than important debt.

Impact vs. Effort Matrix

This simple 2×2 matrix categorizes debt based on business impact and remediation effort:

Quick Wins (high impact, low effort) provide the best return on investment. These should be addressed immediately. Examples include fixing duplicate code in frequently modified files, adding missing database indexes for slow queries, or implementing caching for expensive calculations.

Major Projects (high impact, high effort) deliver substantial value but require significant investment. These need dedicated planning, potentially spanning multiple sprints. Examples include decomposing a monolithic service, implementing comprehensive integration test coverage, or upgrading a major framework version. These should be broken into smaller incremental tasks when possible.

Fill-ins (low impact, low effort) can be tackled during downtime or as part of other work. Examples include updating outdated comments, renaming poorly named variables encountered during feature work, or fixing minor code style inconsistencies. Apply the Boy Scout Rule for these items.

Time Sinks (low impact, high effort) should generally be avoided. They consume significant resources for minimal benefit. If debt falls in this quadrant, seriously question whether it needs addressing. Sometimes the right answer is leaving it alone.

Risk Scoring Model

A risk-based approach prioritizes debt that poses the greatest threat to system stability or business outcomes:

Risk Score = Probability of Issue × Impact of Issue

This quantitative approach helps defend prioritization decisions to stakeholders by making the rationale explicit.

Probability factors:

Code churn rate indicates how frequently code changes. Higher churn creates more opportunities for defects. Tools like CodeClimate measure this automatically.

Defect history is the strongest predictor of future defects. Areas with historical defects are likely to have more because underlying complexity or architecture problems persist.

Complexity correlates with defect density. Research by McCabe, Watson, and others consistently shows that cyclomatic complexity above 10-15 corresponds to sharply increased defect rates.

Impact factors:

Business criticality varies by feature. Payment processing failures cost revenue directly; cosmetic UI issues might not. Understand your system's critical paths and prioritize debt in those areas.

User base determines blast radius. Issues affecting 100,000 users have more impact than those affecting 100 internal users. Consider both user count and user importance (internal tools vs. customer-facing vs. revenue-generating).

Blast radius measures how many components an issue affects. Problems in shared libraries affect more code than issues in isolated modules. Database schema issues affect all services; a bug in one microservice affects only that service.

Example risk assessment:

Debt Item	Probability	Impact	Risk Score	Priority
Payment service has no circuit breaker	70%	Critical (4)	2.8	P0
Legacy auth code hard to modify	40%	High (3)	1.2	P1
Slow admin dashboard queries	30%	Medium (2)	0.6	P2
Outdated comment in utility function	10%	Low (1)	0.1	P3

This scoring makes prioritization discussions concrete rather than subjective.

Interest Payment Analysis

Technical debt, like financial debt, accrues interest. The "interest" is the ongoing cost paid in reduced productivity. This framework makes technical debt tangible to non-technical stakeholders by expressing it in business terms.

Calculate monthly interest:

Identify the cost: How much additional time does this debt consume monthly?
- Example: Developers spend 5 extra hours per month working around a missing abstraction
Multiply by developer cost: If developers cost $100/hour (loaded cost including salary, benefits, overhead), that's $500/month in interest
Calculate payback period: If fixing the debt takes 20 hours ($2,000), the payback period is 4 months ($2,000 investment / $500 monthly savings)
Prioritize debt with shortest payback periods: Debt that pays for itself quickly should be addressed first

This makes the business case clear. For the example above: "We're spending $500/month working around this missing abstraction. A $2,000 investment fixes it permanently, paying for itself in 4 months and saving $6,000 annually thereafter."

Some debt has very short payback periods (weeks or months), making the ROI obvious. Other debt might have payback periods measured in years, making it less attractive to address immediately.

Debt Paydown Strategies

Different strategies suit different team situations and types of debt. Most effective approaches combine multiple strategies rather than relying on a single approach.

Dedicated Debt Sprints

Dedicated sprints allocate 100% of engineering capacity to addressing technical debt with no feature work. This provides focused time to address significant debt that's difficult to tackle incrementally.

When to use:

Debt has reached critical levels visibly affecting team velocity (every feature takes longer than it should)
Multiple related debt items can be addressed together (e.g., upgrading all microservices to a new framework version)
After major feature releases when the team needs a break from feature work
Before starting a major new initiative that would be impeded by existing debt

Implementation approach:

Plan thoroughly: Before the sprint, identify and prioritize all debt items using the frameworks above. Estimate effort and dependencies.
Set clear goals: Define measurable outcomes (e.g., "increase test coverage from 60% to 80%," "reduce build time from 20 minutes to 8 minutes"). This provides success criteria and demonstrates value.
Track progress: Use burn-down charts to visualize debt reduction. Make progress visible to stakeholders.
Communicate value: Share metrics showing improvements achieved (build time reduction, defect rate decrease, decreased complexity). This builds case for future debt investment.

Caution: Dedicated debt sprints remove all feature delivery for that period, which may not be acceptable to business stakeholders. Clearly communicate the expected benefits in terms they understand - faster future feature delivery, reduced production incidents, lower maintenance costs. Get stakeholder buy-in before committing to a full debt sprint.

The 20% Time Rule

Reserve a fixed percentage of each sprint for technical debt work, ensuring continuous paydown without halting feature development. This provides sustainable, predictable debt reduction.

Common allocations:

20% rule: Allocate 1 day per week or 20% of story points to debt
30/70 split: Dedicate 30% of engineering time to quality improvements and 70% to features
Fixed capacity: Reserve specific developers (e.g., 2 out of 10) full-time on debt while others work on features

The percentage should reflect your current debt load. Teams with high debt might need 30%, while teams with low debt might sustain quality with 10-15%.

Implementation:

## Sprint Planning Template

**Sprint 47 Capacity**: 100 story points

**Feature Work (80 points)**:
- User story: Payment retry mechanism (13 points)
- User story: Transaction history export (21 points)
- User story: Dashboard performance improvements (34 points)
- Bug fixes (12 points)

**Technical Debt (20 points)**:
- Refactor payment validation logic (8 points)
- Add integration tests for auth service (8 points)
- Update Spring Boot from 3.1 to 3.2 (4 points)

This approach provides predictable debt paydown while maintaining feature velocity. Crucially, paying down debt actually increases feature velocity over time by reducing maintenance burden. The time invested in debt pays for itself through faster future development.

Boy Scout Rule

"Leave the code better than you found it." Every time you touch code for any reason, make small improvements. This continuously improves code quality without dedicated refactoring time.

Practical application:

Adding a feature in a poorly named class? Rename it (using IDE refactoring tools to update all references automatically)
Fixing a bug in a complex method? Extract helper methods to clarify logic
Updating a component? Add missing test coverage for the code you're touching
Working in a file with unclear comments? Update them to reflect current behavior

Example:

// Before: While adding a new validation rule, you encounter this
public void processPayment(Payment p) {
    if (p.amt <= 0 || p.amt > 10000) throw new Exception("Bad amount");
    // ... process payment
}

// After: Boy Scout Rule applied - better naming, extracted validation, proper exception types
public void processPayment(Payment payment) {
    validatePaymentAmount(payment.getAmount());
    // ... process payment
}

private void validatePaymentAmount(BigDecimal amount) {
    if (amount.compareTo(BigDecimal.ZERO) <= 0) {
        throw new InvalidPaymentException("Payment amount must be positive");
    }
    if (amount.compareTo(MAX_PAYMENT_AMOUNT) > 0) {
        throw new InvalidPaymentException(
            String.format("Payment amount %s exceeds maximum allowed %s",
                amount, MAX_PAYMENT_AMOUNT)
        );
    }
}

The improvement takes only a few extra minutes but compounds over time. The refactored code has better naming (payment instead of p, amount instead of amt), extracted validation logic, proper exception types instead of generic Exception, and clear error messages. If every developer improves code during every change, the codebase continuously improves without dedicated refactoring time.

Caution: Keep improvements small and related to your change. Large refactorings make code review difficult by mixing behavior changes with structural changes, and they increase merge conflict risk. If larger refactoring is needed, create a separate task with its own PR focused solely on refactoring without behavior changes.

Incremental Refactoring (Strangler Pattern)

When dealing with legacy systems too large to rewrite completely, incrementally replace old code with new implementations. This pattern, named by Martin Fowler after strangler figs that gradually replace their host trees, reduces risk compared to "big bang" rewrites.

The pattern works by:

Identify a boundary: Choose a well-defined subsystem or module to replace first. Start with something valuable but relatively isolated.
Build new implementation alongside old: Create new code without removing old code. Both systems coexist temporarily.
Redirect traffic gradually: Start routing some requests to the new implementation (e.g., 1% of traffic, canary users, specific feature flags).
Expand coverage: As confidence grows, route more traffic to the new implementation. Monitor error rates and performance.
Remove old code: Once all traffic uses the new implementation and it's proven stable, delete the old code.

Example scenario: Replacing a monolithic authentication service

The diagram shows how traffic gradually shifts from the legacy system to the new system. The router (which could be implemented using feature flags, API gateway routing, or application-level logic) controls the percentage of traffic sent to each implementation.

This approach reduces risk because:

The old system continues functioning during migration - if the new system has problems, you can roll back instantly
Issues with the new implementation affect only a portion of traffic initially
Migration can be paused or rolled back if problems arise
The team learns from early feedback and adjusts the approach before full rollout
Changes can be tested in production with real traffic at low volume before full commitment

This pattern is particularly effective for microservices architecture, where you can replace one service at a time while other services continue using the old implementation.

Measuring Debt

Quantitative measurement makes debt visible and tracks improvement over time. "You can't improve what you don't measure" applies strongly to technical debt. Effective metrics combine automated measurement with manual tracking.

Code Quality Metrics

Cyclomatic Complexity should be tracked at both file and function levels. Monitor:

Average complexity across the codebase (trending up or down over time)
Count of functions exceeding threshold (e.g., complexity > 15)
Complexity of "hotspot" files (frequently changed files)

Set quality gates in your CI/CD pipeline to reject PRs introducing functions above complexity thresholds. SonarQube and similar tools automate this.

Code Coverage measures the percentage of code exercised by automated tests. Track multiple coverage types:

Line coverage: Which lines execute during tests (minimum viable metric)
Branch coverage: Which decision paths execute (better metric than line coverage)
Mutation coverage: Whether tests detect defects when code is modified (best metric)

Line coverage alone can be misleading - you can have 100% line coverage with tests that don't assert anything. Branch coverage is better because it ensures both true and false paths of conditionals are tested. Mutation coverage is best because it verifies tests actually detect bugs.

See our Mutation Testing guide for implementing comprehensive coverage measurement using PITest (Java) or Stryker (JavaScript/TypeScript).

Set minimum coverage thresholds (e.g., 80% for new code) enforced in CI/CD, but recognize that coverage is necessary but not sufficient - you also need good assertions.

Code Duplication should be measured as percentage of duplicated code blocks. Tools like SonarQube and PMD detect copy-paste patterns. Set targets (e.g., less than 3% duplication) and fail builds that exceed thresholds.

Small amounts of duplication (1-3%) are typically acceptable - eliminating all duplication can create excessive abstraction. Focus on significant duplication (>10 lines) that represents duplicated business logic rather than boilerplate.

Test Coverage Gaps

Beyond overall coverage percentage, identify specific gaps that represent risk:

Uncovered critical paths: Payment processing, authentication, authorization, and data persistence should approach 100% coverage because failures in these areas have severe consequences. Track coverage of critical modules separately from overall coverage.

Missing test types: Measure coverage across different test levels:

Unit test coverage: Individual functions and classes in isolation
Integration test coverage: Component interactions, database queries, API calls
End-to-end test coverage: Critical user journeys through the entire system

See our Testing Strategy for guidance on balancing different test types using the testing honeycomb model.

Flaky test rate: Track what percentage of test runs have failures that pass on retry. Flaky tests erode confidence and waste time. A flaky test rate above 1-2% indicates serious problems that should be addressed before writing new tests.

Dependency Age and Vulnerabilities

Track how outdated dependencies are and whether they contain known vulnerabilities. Outdated dependencies represent security risk and make future upgrades harder.

Metrics to monitor:

Dependency age measures how many major/minor versions behind the latest stable release you are. Being one minor version behind is usually fine; being several major versions behind indicates significant debt.

Known vulnerabilities counts CVEs (Common Vulnerabilities and Exposures) in dependencies. Prioritize by severity - critical and high severity CVEs should be addressed immediately; low severity can be planned.

Unmaintained dependencies are libraries with no updates in 12+ months. These represent risk because security issues won't be patched and compatibility with newer frameworks may break.

Tools like Dependabot, Renovate, Snyk, and OWASP Dependency-Check automate this monitoring and create PRs to update dependencies.

Example dashboard:

Dependency	Current	Latest	Versions Behind	Known CVEs	Risk
Spring Boot	3.1.5	3.2.0	1 minor	0	Low
Jackson	2.14.0	2.16.0	2 minor	2 (low severity)	Medium
Apache Commons	2.8.0	3.13.0	1 major	4 (1 critical)	Critical

The Apache Commons dependency represents critical debt - a major version behind with a critical CVE. This should be prioritized as P0 work.

Build and Deployment Metrics

Operational metrics reveal infrastructure debt that might not be visible in code:

Build time should be tracked over time. Increasing build times indicate growing complexity, excessive dependencies, or inefficient build configuration. Set targets (e.g., builds under 10 minutes) and investigate when builds exceed thresholds.

Deployment frequency indicates deployment friction. If deployments become less frequent over time, teams are implicitly acknowledging increased risk or difficulty. This suggests automation or testing debt.

Deployment failure rate measures what percentage of deployments fail or need to be rolled back. Higher failure rates indicate insufficient testing or complex deployment processes. Track this over time to identify trends.

Mean time to restore service (MTTR) measures how long it takes to recover from incidents. Increasing MTTR suggests insufficient runbooks, monitoring, or system complexity. This is a lagging indicator of operational debt.

These metrics should be tracked in your CI/CD platform and reviewed during retrospectives. See our guide on Infrastructure and CI/CD for implementation patterns.

Preventing New Debt

Prevention is more effective than remediation. Building quality practices into your development process prevents debt from accumulating. Every hour spent preventing debt saves multiple hours of remediation later.

Definition of Done Includes Quality Gates

Your Definition of Done should include explicit quality requirements that prevent debt from being merged:

Code quality requirements:

Code review approval by at least one other developer
No SonarQube violations rated "blocker" or "critical"
Cyclomatic complexity below 15 for all new functions
Code duplication below 3% for changed files

Test requirements:

Unit test coverage ≥ 80% for new code
Mutation test coverage ≥ 75% (see Mutation Testing)
All acceptance criteria have automated tests
No skipped or ignored tests without documented justification and tracking ticket

Documentation requirements:

Public APIs have documentation comments
Complex algorithms have explanatory comments
README updated if setup process changes
Architecture Decision Records created for significant design decisions

Automated quality gates in your CI/CD pipeline enforce these requirements, failing builds that don't meet standards. This prevents debt from being merged rather than relying on humans to remember to check.

Code Review Standards

Code review is the primary defense against new debt entering the codebase. Reviewers should actively look for debt and request fixes before merge.

Specific review focus areas for debt prevention:

Duplication check: Does this code duplicate existing logic that should be abstracted? Search the codebase for similar patterns before approving.
Testability: Can this code be easily unit tested? If not, it's likely too coupled. Difficult-to-test code is often poorly designed code.
Complexity: Are there functions with high cyclomatic complexity that should be simplified? Use automated tools, but also apply human judgment about cognitive complexity.
Naming clarity: Are names self-explanatory or do they require extensive comments? Good names eliminate need for comments.
Documentation: Are non-obvious decisions explained? Why was this approach chosen over alternatives?

Review checklist template:

## Code Review Checklist

**Functionality**
- [ ] Code implements requirements correctly
- [ ] Edge cases are handled
- [ ] Error handling is appropriate

**Quality**
- [ ] No code duplication (checked via search)
- [ ] Functions have single responsibility
- [ ] Cyclomatic complexity < 15 (automated check)
- [ ] Names are clear and self-documenting
- [ ] No magic numbers or strings

**Tests**
- [ ] Unit tests cover happy path and edge cases
- [ ] Tests verify behavior, not implementation
- [ ] Integration tests verify component interaction
- [ ] Test names clearly describe what they verify

**Documentation**
- [ ] Complex logic has explanatory comments
- [ ] Public APIs documented
- [ ] README updated if necessary
- [ ] ADR created if architectural decision made

Architecture Reviews

For changes affecting system architecture, conduct formal architecture reviews before implementation to catch architectural debt early. This is significantly cheaper than fixing architectural problems after they're implemented.

Review triggers:

New service or major component
Significant changes to data models or database schema
Integration with external systems
Technology stack changes or major library upgrades
Changes affecting system scalability, security, or performance

Review participants:

Technical lead/architect
Representatives from affected teams
Security engineer (for security-sensitive changes)
DevOps/SRE (for operational concerns)
Senior developers with relevant expertise

Review process:

Author prepares design document describing the proposed change, alternatives considered, and rationale
Review meeting discusses design, identifies risks, and suggests improvements
Author updates design based on feedback
Review is approved, rejected, or requires additional iteration

Review outputs:

Architecture Decision Record documenting the decision and reasoning (see Technical Design)
Identified risks and mitigation strategies
Implementation plan with milestones and rollback approach
Security and operational considerations

This process prevents architectural debt by ensuring designs receive scrutiny before significant implementation investment. Finding architectural problems in design phase costs hours; finding them in production costs months.

Technical Debt Register

A technical debt register provides central visibility into all known debt, its impact, and plans for addressing it. This prevents debt from being forgotten and enables informed prioritization.

What to Track

Each debt item should include:

Description: What is the debt? Be specific - "Payment service is complex" is too vague; "Payment validation logic duplicated across 5 files" is actionable.

Type: Code, architecture, test, documentation, or infrastructure debt. This helps identify patterns (e.g., if most debt is test debt, invest in testing practices).

Location: Which files, services, or components are affected? Provide file paths or service names so developers can find the code.

Impact: What problems does this debt cause? Be concrete:

"Slows feature development in payment processing by approximately 30%"
"Causes 2-3 production bugs per month due to inconsistent validation"
"Prevents scaling beyond 1,000 concurrent users"

Estimated remediation effort: Story points or hours to fix. This doesn't need to be perfect, but provides order-of-magnitude understanding.

Priority: Based on prioritization framework (risk score, impact/effort matrix, payback period). P0 should be addressed within current sprint, P1 within current quarter, etc.

Owner: Who is responsible for tracking and resolving this debt? This doesn't mean they must fix it personally, but they ensure it's tracked and addressed.

Status: Identified (newly discovered), Planned (scheduled for specific sprint), In Progress (currently being worked), Resolved (completed), or Won't Fix (consciously choosing not to address).

Example Tracking Format

Using a simple table or issue tracker (JIRA, Linear, GitHub Issues):

ID	Type	Description	Impact	Effort	Priority	Owner	Status
TD-001	Code	Payment validation duplicated across 5 files	Inconsistent validation rules, 5hr/month maintenance cost	8 pts	P1	Sarah	Planned Sprint 48
TD-002	Architecture	User service directly accesses database	Cannot change DB without UI changes, prevents CQRS pattern	21 pts	P1	Team	In Progress
TD-003	Test	Integration tests for checkout flow missing	Cannot refactor checkout safely, 40% of prod bugs from checkout	13 pts	P0	Mike	Planned Sprint 47
TD-004	Infrastructure	Manual deployment to production	2hr deployment, risk of human error, blocks daily releases	34 pts	P2	DevOps	Backlog
TD-005	Documentation	No runbook for database failover	Extended outage during incidents (last incident: 4hr MTTR)	5 pts	P1	Alex	Identified

Ownership and Visibility

Ownership: Assign each debt item to a specific person or team. Without clear ownership, debt gets ignored. The owner tracks progress, advocates for prioritization, and coordinates resolution.

Regular review: Review the debt register during sprint planning and retrospectives:

What new debt was introduced this sprint? Why?
What debt was paid down? What was the impact?
Is debt growing faster than we're paying it down?
Are there patterns in the debt we're introducing (suggesting process problems)?

Stakeholder communication: Share debt metrics with product and business stakeholders monthly or quarterly:

Total count of debt items by priority
Estimated total remediation effort
Trend over time (growing or shrinking)
Examples of how debt is slowing feature development

This transparency helps secure time allocation for debt work by making the problem visible. Hidden debt cannot compete for prioritization against visible features.

Communicating Debt to Stakeholders

Non-technical stakeholders understand business impact, not technical details. Effective communication translates technical debt into business terms - cost, risk, and opportunity.

Translating Technical Terms to Business Impact

Avoid: "The payment service has high cyclomatic complexity and tight coupling."

Instead: "The payment code is difficult to modify safely. This means:

New payment features take 2-3x longer to implement than they should (6 weeks instead of 3 weeks for recent feature)
Payment bugs reach production more frequently because the code is hard to test thoroughly (4 payment bugs last quarter)
Addressing this would reduce payment feature development time by 40% and reduce payment-related incidents by 50%"

The translation focuses on outcomes stakeholders care about: time to market, quality, and cost. Support claims with data when possible.

Expressing Debt as Cost

Business stakeholders think in terms of money and opportunity cost. Frame debt in financial terms to enable rational ROI discussions.

Example cost calculation:

"Our legacy authentication system requires 20 hours of maintenance per month due to its complexity - developers spend time working around limitations, fixing bugs, and explaining how it works to new team members. At our average fully-loaded developer cost of $100/hour, that's $24,000 per year in ongoing cost.

We estimate 160 hours to rebuild it using modern patterns (OAuth 2.0, Spring Security). At the same rate, that's a $16,000 one-time investment with an 8-month payback period. After that, maintenance costs drop to 4 hours per month, saving $19,200 annually.

Additionally, the modern implementation enables features we currently cannot build, like single sign-on and mobile app integration, which are on the roadmap for next quarter."

This framing makes the ROI clear and enables rational discussion about whether the investment makes sense given other priorities.

Risk-Based Communication

Emphasize risks that resonate with business concerns:

Security risks: "Our dependency on this unmaintained library with 3 known critical security vulnerabilities exposes us to potential data breaches. The cost of a breach (regulatory fines, remediation, customer trust) far exceeds the $5,000 to update the dependency."

Compliance risks: "Our current audit logging doesn't capture all required events per SOX requirements, which could result in audit findings and potentially prevent our IPO."

Customer impact risks: "The current architecture cannot handle Black Friday traffic levels based on last year's 40% growth trend. We risk site outages during our highest-revenue period (Black Friday generated $2M revenue last year)."

Competitive risks: "Our deployment process requires 2 hours and manual testing, limiting us to weekly releases. Competitors deploy multiple times daily, allowing them to respond to market changes and fix issues 10x faster."

These framings connect technical debt to outcomes executives care about: regulatory compliance, revenue, and competitive position.

Creating a Paydown Timeline

Show stakeholders a concrete plan with milestones and expected benefits:

The timeline shows:

What will be addressed and when
Dependencies between items
Expected completion dates

For each item, communicate the expected business benefit:

"Circuit breakers (Feb 5): Prevents cascade failures, reducing incident MTTR from 45min to 5min"
"Deployment automation (May 21): Enables daily releases instead of weekly, reducing time-to-market by 5x"

Demonstrating Impact After Paydown

After addressing debt, share measurable improvements to build credibility and justify future debt investment:

Before/After metrics:

Build time: 23 minutes → 8 minutes (65% reduction, saving developers 2 hours/week)
Test coverage: 45% → 78% (production defects decreased 40%)
Production incidents: 12/month → 4/month (67% reduction, saving $15K/month in incident costs)
Time to implement payment features: 3 weeks → 1.5 weeks (50% faster, enabling 2 additional features per quarter)

Include the cost of addressing the debt alongside the benefits to demonstrate ROI: "We invested 160 hours ($16K) to rebuild authentication. In the 6 months since, we've saved 120 hours ($12K) in maintenance and reduced auth-related incidents from 8 to 1, saving an estimated $25K in incident costs. Total 6-month ROI: 230%."

These concrete results build credibility and make future debt investments easier to justify.

Anti-Patterns to Avoid

Several common approaches to debt management appear reasonable but actually worsen the problem.

Perpetual Backlog Items

Creating debt items in the backlog without ever addressing them creates the illusion of management while allowing debt to accumulate unchecked.

Why it fails: Debt items perpetually de-prioritized never get addressed. The backlog becomes a graveyard of good intentions. Eventually, the team stops even looking at these items because they know they'll never be prioritized.

Instead: If debt consistently gets de-prioritized over multiple sprints, either:

Its priority is incorrectly assessed (lower it or remove it from tracking)
Your process doesn't allocate sufficient time to debt (implement one of the paydown strategies above, like the 20% rule)

If debt is truly low priority, remove it from the register to reduce noise. If it's high priority but never gets scheduled, acknowledge you have a process problem and fix the process.

"We'll Fix It Later"

Deferring quality work with vague promises to address it later rarely results in it actually being addressed.

Why it fails: "Later" never comes. Once a feature ships, pressure shifts to the next feature. The debt remains indefinitely, accruing interest. Teams using this approach accumulate massive debt over years until development becomes nearly impossible.

Instead: Build quality into the initial implementation. The Boy Scout Rule ensures code quality throughout development rather than relying on future refactoring that may never happen. If truly time-constrained, explicitly document the debt in the register with a specific paydown plan before considering the feature done.

Only Tracking Debt from New Code

Some teams only prevent new debt but ignore existing debt, thinking it's too large to address.

Why it fails: Existing debt continues to accrue interest. The codebase becomes divided into "old bad code we don't touch" and "new good code," but features often span both areas. The old code constrains development velocity even if new code is clean.

Instead: Combine prevention of new debt with incremental paydown of existing debt. Use the Strangler Pattern to gradually replace legacy code. Apply the Boy Scout Rule to improve legacy code whenever you touch it.

Debt Work Without Test Coverage First

Refactoring code without comprehensive test coverage risks introducing bugs while trying to improve code quality.

Why it fails: Without tests to verify behavior remains unchanged, refactoring becomes risky. Developers fear breaking things, preventing necessary improvements. Even careful refactoring can introduce subtle bugs that aren't discovered until production.

Instead: Before refactoring, ensure comprehensive test coverage. This may mean writing characterization tests for legacy code to capture current behavior before modifying it. Characterization tests document what the code currently does (even if it's buggy) so you can verify refactoring doesn't change behavior.

The sequence should always be: Add tests → Refactor → Verify tests still pass. Never refactor without tests.

Large Refactorings Without Incremental Value

Attempting to fix all debt in a massive rewrite that delivers no value until completely finished.

Why it fails: Large refactorings take months, during which feature development stalls. Stakeholders lose patience. The refactoring never finishes, or it gets cancelled partway through, wasting all invested time. Even if completed, the "big bang" integration often reveals unforeseen problems.

Instead: Break debt work into incremental improvements that each deliver measurable value. Use the Strangler Pattern to refactor incrementally while maintaining system functionality. Each increment should provide value (faster builds, fewer bugs, etc.) to maintain stakeholder support.

Ignoring the Human Element

Treating debt purely as a technical problem ignores the team dynamics and organizational pressures that created the debt.

Why it fails: If the root cause of debt is unrealistic deadlines, insufficient code review, or lack of expertise, addressing symptoms without addressing causes leads to recurring debt. You pay down old debt while accumulating new debt at the same rate.

Instead: In retrospectives, discuss what led to debt being introduced:

Were estimates unrealistic, forcing corners to be cut?
Was there insufficient time for proper code review?
Did team members lack knowledge of better approaches?
Are there organizational pressures (deadlines, understaffing) forcing shortcuts?

Address these root causes to prevent recurrence. This might require difficult conversations about unrealistic timelines, insufficient staffing, or need for training. See our Retrospectives guide for facilitating these discussions.

Integration with Development Process

Technical debt management should be woven throughout your development lifecycle, not treated as a separate activity. Debt work should be as routine as feature work.

Sprint Planning

During sprint planning:

Review debt register: What high-priority debt should be addressed this sprint? Look at P0 and P1 items.
Allocate capacity: Reserve 20% of sprint capacity for debt work (adjust based on current debt load)
Pair debt with features: When planning a feature, address related debt in the same sprint (e.g., if adding payment functionality, refactor existing payment code to make the new feature easier to add)
Track debt introduced: Estimate what debt might be introduced by features planned this sprint and plan to address it

Daily Standups

In daily standups, debt work should be discussed like feature work:

"Yesterday I refactored the payment validation logic as planned"
"I'm blocked on the authentication refactoring because the test suite is too slow to run frequently"
"I discovered additional technical debt in the checkout flow - added TD-142 to track it"

This maintains visibility and ensures debt work receives the same attention as feature work. It also surfaces blockers (like slow tests) that might themselves be debt worth addressing.

Code Review

During code review, reviewers should:

Identify new debt being introduced and request fixes before merge
Suggest related debt that should be addressed while touching this code
Approve intentional debt when it's explicitly documented with a plan to address it
Verify that debt items claimed to be fixed are actually resolved

Sprint Retrospectives

In retrospectives:

Discuss what debt was introduced and why (process improvements to prevent recurrence)
Celebrate debt that was paid down (positive reinforcement)
Identify patterns in debt accumulation (e.g., "we always skip tests when under deadline pressure")
Adjust debt allocation if debt is growing faster than it's being paid down

Definition of Done

Your Definition of Done should include quality gates that prevent debt:

Code coverage thresholds (e.g., 80% for new code)
Mutation testing requirements (e.g., 75% mutation coverage)
Maximum complexity limits (e.g., cyclomatic complexity < 15)
Documentation requirements (ADRs for significant decisions, API documentation for public interfaces)
Dependency vulnerability checks (no critical or high CVEs)

Automated CI/CD checks enforce these gates, making debt prevention automatic rather than relying on human diligence.

Anti-Patterns

Common mistakes to avoid:

Tracking debt without addressing it: Creating debt items that sit in the backlog indefinitely provides an illusion of management without actual improvement. Either schedule debt for resolution or remove it from tracking.

Deferring quality with "we'll fix it later": This rarely happens. Build quality in from the start or explicitly schedule the fix before considering the work done.

Ignoring existing debt while preventing new debt: Existing debt continues accruing interest. Combine prevention with incremental paydown.

Refactoring without tests: This risks introducing bugs while improving code. Always add test coverage before refactoring.

Massive rewrites without incremental value: Large refactorings take too long and often fail. Use incremental approaches like the Strangler Pattern.

Treating debt as purely technical: Debt often stems from organizational issues (unrealistic deadlines, insufficient staffing). Address root causes in retrospectives.

Overview​

Core Principles​

Understanding Types of Technical Debt​

Code Debt​

Architecture Debt​

Test Debt​

Documentation Debt​

Infrastructure Debt​

Identifying and Cataloging Debt​

Code Smells and Static Analysis​

Complexity Metrics​

Manual Code Review Indicators​

Performance and Operational Signals​

Prioritization Frameworks​

Impact vs. Effort Matrix​

Risk Scoring Model​

Interest Payment Analysis​

Debt Paydown Strategies​

Dedicated Debt Sprints​

The 20% Time Rule​

Boy Scout Rule​

Incremental Refactoring (Strangler Pattern)​

Measuring Debt​

Code Quality Metrics​

Test Coverage Gaps​

Dependency Age and Vulnerabilities​

Build and Deployment Metrics​

Preventing New Debt​

Definition of Done Includes Quality Gates​

Code Review Standards​

Architecture Reviews​

Technical Debt Register​

What to Track​

Example Tracking Format​

Ownership and Visibility​

Communicating Debt to Stakeholders​

Translating Technical Terms to Business Impact​

Expressing Debt as Cost​

Risk-Based Communication​

Creating a Paydown Timeline​

Demonstrating Impact After Paydown​

Anti-Patterns to Avoid​

Perpetual Backlog Items​

"We'll Fix It Later"​

Only Tracking Debt from New Code​

Debt Work Without Test Coverage First​

Large Refactorings Without Incremental Value​

Ignoring the Human Element​

Integration with Development Process​

Sprint Planning​

Daily Standups​

Code Review​

Sprint Retrospectives​

Definition of Done​

Anti-Patterns​

Further Reading​

Internal Resources​

External Resources​

Tools and Platforms​

Related Guidelines​

Overview

Core Principles

Understanding Types of Technical Debt

Code Debt

Architecture Debt

Test Debt

Documentation Debt

Infrastructure Debt

Identifying and Cataloging Debt

Code Smells and Static Analysis

Complexity Metrics

Manual Code Review Indicators

Performance and Operational Signals

Prioritization Frameworks

Impact vs. Effort Matrix

Risk Scoring Model

Interest Payment Analysis

Debt Paydown Strategies

Dedicated Debt Sprints

The 20% Time Rule

Boy Scout Rule

Incremental Refactoring (Strangler Pattern)

Measuring Debt

Code Quality Metrics

Test Coverage Gaps

Dependency Age and Vulnerabilities

Build and Deployment Metrics

Preventing New Debt

Definition of Done Includes Quality Gates

Code Review Standards

Architecture Reviews

Technical Debt Register

What to Track

Example Tracking Format

Ownership and Visibility

Communicating Debt to Stakeholders

Translating Technical Terms to Business Impact

Expressing Debt as Cost

Risk-Based Communication

Creating a Paydown Timeline

Demonstrating Impact After Paydown

Anti-Patterns to Avoid

Perpetual Backlog Items

"We'll Fix It Later"

Only Tracking Debt from New Code

Debt Work Without Test Coverage First

Large Refactorings Without Incremental Value

Ignoring the Human Element

Integration with Development Process

Sprint Planning

Daily Standups

Code Review

Sprint Retrospectives

Definition of Done

Anti-Patterns

Further Reading

Internal Resources

External Resources

Tools and Platforms

Related Guidelines