Stakeholder Criteria in Technical Debt Decision-Making: A Practitioner-Informed Taxonomy
Based on a qualitative study of 11 software practitioners in Brazil, this paper proposes a practitioner-informed taxonomy and conceptual model that categorizes stakeholder criteria for technical debt decision-making into six families, distinguishing how these criteria function as permission mechanisms for debt acquisition versus authorization mechanisms for repayment.
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
Imagine building a house. Sometimes, you need to move in quickly because the family is expecting a baby, or the landlord is raising the rent. So, you decide to skip installing the fancy, expensive insulation in the attic and just put up some thin, cheap panels for now. You know it's not perfect, and you know you'll have to fix it later, but you need to move in now. In the software world, this is called Technical Debt. It's taking a shortcut today to save time, knowing it will cost you more effort (and maybe money) to fix later.
This paper asks a simple but tricky question: How do people actually decide when to take these shortcuts, and how do they decide when to finally pay the bill?
The authors found that these decisions aren't just about math or code. They are a messy mix of business pressure, team feelings, and office politics. To help us understand this, they created a "menu" (a taxonomy) of the reasons people use to make these choices.
Here is the breakdown of their findings, using simple analogies:
1. The Two Sides of the Same Coin
The paper highlights that taking on debt (the shortcut) and paying off debt (fixing the mess) are two very different conversations, even though they talk about the same things.
- Acquisition (Taking the Shortcut): Think of this as a "Permission Slip." The team is asking, "Is it okay to skip the insulation right now?" The reasons they use are like permission slips that say, "Yes, go ahead, because the baby is due tomorrow!"
- Repayment (Fixing the Mess): Think of this as an "Authorization Request." The team is asking, "Can we stop building the new kitchen to fix the attic insulation?" This is much harder. They need a "Yes" from the boss to stop doing new work and start fixing old problems.
2. The Six Families of Reasons (The Taxonomy)
The researchers interviewed 11 software professionals in Brazil and found that everyone uses six main types of reasons to make these decisions. Think of these as six different "lenses" through which they view the problem:
Stakeholder-Facing Value (The "Customer's Smile"):
- What it is: Will the client be happy? Will the product launch on time?
- The Analogy: If the shortcut gets the house ready for the family's birthday party, it's a "Yes." If the bad insulation makes the house too cold for the guests, it's a "Fix it now!"
Delivery and Resource Pressure (The "Ticking Clock"):
- What it is: Deadlines, budget, and how tired the team is.
- The Analogy: "We have to move in Friday, so we can't wait for the insulation." But later, "We can't fix the insulation because we are too busy painting the walls."
Technical Integrity and Systemic Risk (The "Structural Soundness"):
- What it is: Is the code (or house) going to collapse? Is it safe?
- The Analogy: "If we don't fix the foundation, the whole house might fall down." This is the engineer's voice. But often, the boss only listens if the house is actually shaking, not just because the engineer says it might shake.
Decision Basis and Epistemic Style (The "Proof vs. Gut Feeling"):
- What it is: How do we know this is the right choice? Do we have data, or are we just guessing?
- The Analogy: Taking a shortcut is often based on a "gut feeling" or urgency ("I feel like we can do this"). Paying it back often requires "hard proof" ("Look at this chart showing the house is losing heat every day").
Governance and Legitimation (The "Office Politics"):
- What it is: Who has the power to say "Yes"? Is this decision allowed by company rules?
- The Analogy: You might know you need to fix the roof, but if the landlord (the organization) hasn't signed the paperwork, you can't do it. You have to convince them it's a valid expense.
Human and Team Sustainability (The "Team's Mood"):
- What it is: Is the team burning out? Are they frustrated?
- The Analogy: "If we don't fix this leaky roof, the workers will quit because they are sick of getting wet." Sometimes, fixing the debt is just to keep the team happy and working efficiently.
3. The Big Discovery: The "Permission vs. Authorization" Gap
The most important thing the paper found is that it is much easier to get permission to take a shortcut than it is to get authorization to fix it.
- Why? When you take a shortcut, you are promising a future problem to get a present win (like a happy client or a meeting a deadline). The "Permission Slip" is easy to sign because the reward is immediate.
- The Trap: When you try to fix the debt later, you are asking to stop doing new, exciting work to fix old, invisible problems. The "Authorization" is hard to get because the reward is invisible (preventing a future disaster) and the cost is immediate (stopping current progress).
4. How Decisions Actually Happen
The paper suggests that these reasons don't just sit in a list. They go through a process to become a real decision:
- Interpretation: Someone has to decide what a problem means (e.g., "Is this a code bug, or is it a business risk?").
- Translation: The tech team has to explain the problem in business language (e.g., instead of saying "The database is slow," they say "Customers will leave if the site is slow").
- Legitimation: Finally, the organization has to agree that this is a valid reason to spend time and money.
Summary
This paper doesn't give a formula for how much debt to take. Instead, it gives us a map of the conversation that happens in software teams. It shows that deciding to take shortcuts or fix them isn't just about "good code" vs. "bad code." It's a complex dance between deadlines, happy customers, tired workers, and office politics.
The main takeaway is that we are very good at justifying shortcuts (because the reasons are loud and immediate), but we are very bad at justifying fixes (because the reasons are quiet and future-focused). Understanding this gap helps teams have better, more honest conversations about their technical debt.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.