💻 computer science

A Practical Guide to Establishing Technical Debt Management (TDM Guide for Practitioners)

This white paper translates dissertation research into a practical, flexible guide for teams to establish tailored technical debt management systems, distinguishing between universally adopted "best practices" and optional "nice-to-haves" while emphasizing collaborative process design.

Original authors: Marion Wiese

Published 2026-03-04

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Marion Wiese

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The "House of Cards" Guide: A Simple Explanation of Technical Debt Management

Imagine you are building a house. You have a deadline to move in, and the weather is turning bad. You decide to skip the foundation inspection, use cheap nails instead of bolts, and prop up a heavy beam with a stack of books instead of a proper pillar.

That stack of books is "Technical Debt."

It got you into the house quickly, but now, every time you want to hang a picture or add a room, you have to worry the whole thing might collapse. You have to spend extra time shoring up the books before you can do anything new. That extra time and effort? That's the interest you are paying on your debt.

This white paper by Marion Wiese is essentially a homeowner's manual for software teams. It teaches them how to stop building with stacks of books, how to find the weak spots in their current house, and how to pay off the debt before the roof caves in.

Here is the guide broken down into simple, everyday concepts.

1. The Problem: Why Do We Have Debt?

In software, "Technical Debt" isn't just "bad code." It's any shortcut taken to finish a task quickly that will cost you more time later.

The Metaphor: Think of it like taking a shortcut through a muddy field to get to work faster. You save 5 minutes today, but tomorrow your shoes are caked in mud, and you spend 20 minutes cleaning them.
The Trap: Sometimes we take shortcuts on purpose (to meet a deadline). Sometimes we do it by accident because we are tired or don't know better. The paper calls these "Conscious" vs. "Unconscious" debt.
The Visibility Problem:
- Developers see the muddy shoes (the code is messy).
- Managers see the time saved (we finished the sprint!).
- The Business sees the delay (why is the new feature late?).
- The paper argues: Everyone needs to see the whole picture. If the business doesn't understand that "speed today = slowness tomorrow," they will keep asking for shortcuts.

2. The Solution: The "Debt Manager"

You wouldn't let everyone in the house decide where to put the furniture without a plan. You need a Technical Debt Manager (TD Manager).

Who are they? They are the "House Inspector" or the "Homeowner's Association President."
What do they do?
- They remind everyone: "Hey, we can't just stack books under the beam again!"
- They keep a list of all the "stacks of books" (the debt).
- They make sure the team actually fixes the debt, not just talks about it.

3. The Process: How to Fix the House

The paper suggests a four-step cycle to manage this debt, similar to managing your personal finances.

Step A: Prevention (Don't Take on New Debt)

Before you build a new room, ask: "Are we going to use cheap nails again?"

The Checklist: When planning a new feature, the team must ask: "Will this make the code harder to change later?"
The "What If" Game: The team must look for alternatives. Instead of saying, "We'll just hard-code this value," they should ask, "Is there a better way that won't break in six months?"

Step B: Identification (Find the Weak Spots)

How do you know where the debt is?

The "Who Pays?" Test: The paper gives a simple rule:
- If the team suffers (it takes longer to code) but the customer doesn't care, it's Technical Debt.
- If the customer suffers (the app crashes) and the team fixes it, it's just a Bug.
The "Red Flag" Words: If a ticket says things like "Quick fix," "Hack," "Temporary," or "I'll clean this up later," it's probably debt.

Step C: Prioritization (Which Debt to Pay First?)

You can't fix the whole house at once. You need a strategy.

The "Low-Hanging Fruit" Chart: Imagine a graph.
- X-Axis: How hard is it to fix? (Effort)
- Y-Axis: How bad is it if we don't fix it? (Risk/Priority)
- The Goal: Fix the things that are High Risk but Easy to Fix first. These are your "Low-Hanging Fruits."
The ROI (Return on Investment): Ask the business: "If we spend 2 days fixing this, we save 10 hours of work every month." That's a good deal!

Step D: Repayment (Paying the Bill)

How do you actually fix it?

The "Pay as You Go" Method: Every time you work on a feature, spend 10-20% of your time fixing the debt in that same area. (Like paying a little extra on your mortgage every month).
The "Sprint Tax": Dedicate one day a week or one sprint a month only to fixing debt.
The "Rewrite": Sometimes, the house is so rotten you have to tear it down and build a new one (Rewriting the system).

4. The Tools: Keeping Score

You can't manage what you don't measure.

The "Debt Tracker": Every piece of debt gets its own ticket in the project management software (like Jira or Azure DevOps).
The "Resubmission Date": This is a clever trick. If a piece of debt isn't urgent right now, don't delete it. Set a date 6 months from now to check on it again. Maybe the business situation will change, and it will become urgent later.
Visuals: The paper suggests using charts to show the boss: "Look, our 'Interest Bill' (time spent fixing old mistakes) is getting huge. We need to pay it down, or we can't build new rooms."

5. Common Mistakes (What Not to Do)

The paper warns against several traps:

"We'll Remember It": Don't say, "We'll all remember to check for debt." Someone needs to be responsible for checking.
"The Perfect List": Don't try to track 50 different things about the debt. Start with just the basics (How hard is it? How risky is it?).
"The 'Very' Trap": Don't just say "Very High Priority." Define what that means. Does "Very High" mean "The server will catch fire tomorrow"? Be specific.

6. The Big Picture: Scaling Up

If one team fixes their house, great. But what if the whole neighborhood (the whole company) is full of houses with stacks of books?

The Community of Practice: Create a group where different teams meet to share their "Debt Management" tips.
The Top-Down Approach: If the teams won't do it, the bosses need to mandate it. "We are allocating 20% of our budget to fixing the foundation."

Summary: The Takeaway

Technical Debt isn't a "bug"; it's a lifestyle choice.

Short-term: Shortcuts feel good.
Long-term: They become a burden.

This guide tells teams: Stop ignoring the mess. Create a system to find the mess, measure how bad it is, and pay it off systematically. If you do this, you stop paying "interest" (wasting time) and start building a house that can actually grow.

The Golden Rule: It is always cheaper to fix the foundation now than to rebuild the whole house later.

Based on the white paper "A Practical Guide to Establishing Technical Debt Management" by Marion Wiese (March 2026), here is a detailed technical summary covering the problem, methodology, key contributions, results, and significance.

1. Problem Statement

Technical Debt (TD) is a pervasive issue in software engineering where expedient short-term design or implementation choices lead to increased long-term costs (interest) and reduced maintainability. The core problems identified in the paper include:

Invisibility to Stakeholders: Developers, IT managers, and business stakeholders often have mismatched perspectives. Developers see the code issues but lack business context; business managers see delays but do not see the underlying technical causes.
Lack of Standardized Management: Teams often lack a structured process to identify, document, prioritize, and repay TD. TD is frequently treated as an afterthought or "unconscious" debt incurred due to time pressure or lack of awareness.
Tooling Gaps: Standard issue tracking tools (e.g., Jira, Azure DevOps) lack native support for TD-specific attributes (e.g., interest rates, contagion, ROI), making visualization and prioritization difficult.
Unconscious Accumulation: Teams often incur TD unintentionally due to poor estimation practices (e.g., Planning Poker failures), lack of alternative analysis, or pressure to meet deadlines without assessing quality trade-offs.

2. Methodology

The guide is not a theoretical framework but a practical, empirically derived guide based on the author's dissertation and a collaborative study with three software teams from different companies.

Empirical Basis: The authors worked with three teams to adapt and establish a TD management system tailored to their specific needs.
Differentiation of Practices: The guide distinguishes between:
- Best Practices: Approaches adopted by all three teams (mandatory for success).
- Nice-to-Haves: Approaches used by at least one team (optional based on context).
Process-Oriented Approach: The methodology moves beyond simple identification to a full lifecycle management approach: Prevention $\rightarrow$ Identification $\rightarrow$ Documentation $\rightarrow$ Prioritization $\rightarrow$ Repayment $\rightarrow$ Monitoring.
Quantitative & Qualitative Metrics: The methodology introduces specific metrics for TD, including "Interest" (effort to fix), "Interest Probability" (frequency of occurrence), "Contagion" (how debt spreads), and "Return on Investment" (ROI) for repayment.

3. Key Contributions

The paper provides a comprehensive toolkit for establishing TD management, structured into four main areas:

A. Organizational & Role Definition

TD Manager Role: Introduces a dedicated "Technical Debt Manager" responsible for process coordination, tool configuration, acting as a "voice of reason," and bridging communication between technical and business stakeholders.
Tool Integration: Recommends using existing Issue Tracking Tools (Jira, Azure DevOps, GitLab) but extending them with a specific "Technical Debt" issue type and custom attributes.

B. Prevention & Identification

Conscious Decision Making: Proposes modifying issue templates (User Stories, Bugs) to include mandatory fields (Checkboxes/DoR) that force teams to ask: "Does this create TD?", "What are the alternatives?", and "What are the risks/drawbacks?"
Identification Matrix: Introduces a decision matrix to classify issues as TD based on who suffers (Team vs. Customer) and who is willing to pay for the fix. This helps distinguish between internal technical debt and functional requirements.
Indicators: Lists linguistic and procedural indicators of unconscious TD (e.g., phrases like "We'll do it later," "It's not important," or skipping refinement).

C. Management & Prioritization Framework

The core contribution is a structured method for evaluating and prioritizing TD items using specific attributes:

Attributes for Assessment:
- Risks of Non-Repayment: Consequences if left unfixed.
- Repayment Effort: Estimated in Story Points (SP) or Person Days (PD).
- Contagion: Whether the cost of repayment increases over time (e.g., an API with more consumers).
- Interest Probability/Frequency: How often the "interest" (extra work) is incurred.
- Interest: The effort required to pay the "interest" when it occurs.
Prioritization Strategies:
1. Educated Guess: Team consensus.
2. Mean Value: Calculating an average score based on weighted attributes (Interest, Probability, Pain Factor).
3. Return on Investment (ROI): Calculating the break-even point in months: $ROI = \frac{\text{Repayment Effort}}{\text{Monthly Interest Burden}}$ . This translates technical debt into business language understandable by management.
Resubmission Dates: A mechanism to prevent TD items from being permanently ignored. Items are re-evaluated on a specific date if the business context changes.

D. Repayment Strategies

The paper categorizes repayment methods into three scenarios:

Ignore: Accepting the debt (paying interest) if repayment is not economically viable.
Rewrite: Eliminating debt by replacing the system/component (e.g., migration, shutdown).
Refactor: Active repayment strategies including:
- Low-hanging fruit: High priority, low effort.
- Contingent/Quota: Allocating a % of sprint capacity to TD.
- Evolution-based: Fixing debt while modifying the affected component for a new feature.
- Polluter Pays: The team incurring the debt during a feature update must repay it immediately after.

4. Results & Findings

Process Viability: The study confirmed that a structured TD management process can be successfully implemented in agile teams without disrupting delivery, provided a "TD Manager" is appointed.
Visualization Impact: Interactive visualizations (e.g., "Low-hanging fruit" scatter plots, component heatmaps) significantly improved stakeholder awareness and planning. However, the authors note that standard tools often lack the flexibility for these visualizations, requiring external BI tools (Power BI, Tableau).
Common Pitfalls: The study identified typical failure modes, such as:
- Using too many attributes initially (over-engineering).
- Failing to distinguish between "cross-cutting concerns" (e.g., documentation) and specific components.
- Setting resubmission dates too soon (e.g., "next week") rather than waiting for business context changes.
- The "Anchoring Effect" in estimation (Product Owners giving estimates), which leads to underestimation and subsequent TD.

5. Significance

Bridging the Gap: The guide successfully translates academic concepts of Technical Debt into actionable, day-to-day engineering practices. It provides a common language for developers and business managers to discuss technical quality.
Scalability: It offers a roadmap for scaling TD management from a single team to an entire organization, suggesting a "Community of Practice" (CoP) approach to foster intrinsic motivation and knowledge sharing.
Economic Justification: By introducing the ROI and Interest Burden calculations, the paper empowers teams to argue for technical refactoring using financial logic familiar to management, moving the conversation from "clean code" to "risk mitigation and cost reduction."
Preventative Focus: Unlike many guides that focus solely on cleaning up existing debt, this paper places significant emphasis on prevention through modified issue templates and conscious decision-making frameworks, addressing the root causes of debt accumulation.

In summary, this white paper serves as a definitive, practical handbook for organizations seeking to institutionalize Technical Debt management, moving it from an ad-hoc activity to a strategic, data-driven process.