How do software development teams manage technical debt? - An empirical study
Jesse Yli-Huumo, Andrey Maglyas, Kari Smolander · pdf · 2016-08-08 Reader 🖥️
Software development teams manage technical debt unevenly and mostly informally -- across eight distinct activities (identification, measurement, prioritization, prevention, monitoring, repayment, documentation, communication) teams sit at different maturity levels (unorganized, received, organized), and the key differentiator is not tooling but whether TD communication and documentation are treated as first-class practices, since every other activity depends on TD being visible and discussed rather than left in individual developers' heads.
theoretical · mixed — An interpretive, exploratory multi-case study (Journal of Systems and Software, 2016). Primarily expository/argumentative: it reports empirical findings from 25 interviews across 8 teams in one large organization and derives a descriptive framework, but its discussion section makes explicit normative claims about which TDM activities matter most and why.
Structure
| Part | Role |
|---|---|
| Background: the TD metaphor (Cunningham) and the eight-activity TDM taxonomy from Li et al. (2015a) | context |
| Research methodology: two-round, 17-interview, 25-person exploratory case study across 8 teams in one 5,600-employee organization | method |
| Per-team results (Cases A-H) and the cross-case summary (Table 4) | evidence |
| The TDM framework (Table 5): three maturity levels x eight activities x stakeholders x practices/tools | conclusion / original model |
| Discussion of RQ1.1-1.4: which activities are common/occasional/rare, maturity differences, and the four biggest challenges (tools, prioritization knowledge, mindset, time) | interpretation |
| Limitations and threats to validity; conclusion framing TDM maturity as CMM-like | qualification |
Key terms
- Technical debt (TD) Technical Debt
"A badly structured technical solution or architectural design in the system, incurred by either an intentional decision or an unintentional side effect, which causes omitted quality and productivity." Explicitly excludes social/people debt, which the authors treat as a *source* of TD rather than TD itself. - Technical debt management (TDM)
The eight activities (borrowed from Li et al. 2015a) that identify, measure, prioritize, prevent, monitor, repay, represent/document, and communicate TD -- treated as the complete inventory of what managing TD consists of. - TDM maturity (unorganized / received / organized)
A team's level of a given TDM activity: unorganized (not conducted, or only when the issue can no longer be avoided), received (acknowledged and conducted occasionally, by a few people), organized (recognized as essential, conducted continuously by the whole team). Explicitly modeled on but distinct from the Capability Maturity Model (CMM).
Propositions
- explicitTD communication is the most consistently organized TDM activity across the eight teams, and functions as the activity other TDM activities depend on.conf: high
- explicitA technically literate team manager, acting as a filter/middle-man between business stakeholders and the development team, is a major determinant of whether a team gets space and legitimacy to repay technical debt.conf: high
- explicitTD measurement and monitoring are the rarest, least mature TDM activities across teams, because without documented TD items there is no data to measure or monitor against.conf: high
- explicitIn practice, TD prioritization is done almost entirely by hunch and prior experience rather than by any cost/benefit or quantitative model, despite several such models existing in the literature.conf: high
- explicitSoftware architects, more than team managers or developers, function as the de facto central stakeholder across all eight TDM activities, because they hold the best overall view of the system's design.conf: high
- explicitTD identification done manually catches mostly code-level issues; architectural and design-level TD resists automated detection (e.g. SonarQube) and, where caught at all, is caught only by experienced humans deliberately reviewing the codebase.conf: high
- explicitHigher TDM maturity (performing all eight activities continuously) does not necessarily correlate with less actual technical debt -- a team that refactors only when forced may carry less debt than a team that performs every activity formally.conf: highextendsTechnical Debt Quadrant · p2 — Fowler's reckless/prudent distinction is a two-axis taxonomy of why debt is incurred; this paper empirically operationalizes the downstream management side (eight activities, three maturity levels) that Fowler's piece doesn't address -- showing that maturity in managing debt is a distinct axis from the debt's own reckless/prudent character.
- explicitTD prevention practices (coding standards, code review, Definition of Done) are well understood, cheap, and already set up in most teams, yet applied only occasionally because they are optional and compete with time spent on new features.conf: highsupportsFrom Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p1 — The finding that TD prevention is cheap, well-understood, and still neglected because it competes with visible feature work is the human-era precedent for Storey's claim that cognitive/intent debt (not technical debt) become the binding constraints once code-level debt is partly automated away -- the competing-priorities dynamic was already present before AI, just applied to a different debt layer.
- implicitTeams that maintain a dedicated TD backlog or list (separate from the general development backlog) have systematically better documentation and monitoring outcomes than teams that fold TD items into the general backlog or keep no record at all.conf: medium
- explicitUndocumented TD knowledge lives only in individual developers' private notes and memory, and is "sometimes forgotten" entirely -- documentation failure is a direct cause of TD items simply disappearing from the organization's awareness, not just being delayed.conf: highsupportsThe Intent Debt · p1 — This 2016 case study shows intent debt's core mechanism -- unexternalized rationale living only in a developer's head and "sometimes forgotten" -- predates AI agents entirely; it was already the primary failure mode of human-only TD documentation, which osmani-intent-debt's framework explains why agents make acutely worse (no tacit memory to fall back on).
- explicitThe biggest obstacle to adopting TDM tools and processes is not ignorance of best practice but a mindset problem: TDM work competes directly against visible feature delivery, and time spent on it is hard for developers or managers to justify without demonstrated near-term payoff.conf: high
- explicitThe maturity differences between teams were largest precisely in the activities owned by the development team itself (repayment, prevention, documentation, identification), and smallest in the activities owned by architects/managers (measurement, monitoring, prioritization) -- suggesting the hardest activities converge toward a shared (low) baseline regardless of team, while the easier, team-owned activities vary with local team culture.conf: medium
Arguments
TD communication should be treated as the first and cheapest TDM investment a team makes, prior to any investment in tooling. strength: medium
Explicit premises:
- Communication was the most commonly organized activity across the studied teams.
- Teams with poor TD communication struggled across the other seven activities.
- Simply making TD a recurring discussion topic already improves communication, with no tooling required.
Implicit premises:
- The other seven TDM activities only get resourced (time, budget, mandate) once their existence and cost are visible and discussed among stakeholders.
- Communication is a near-zero-marginal-cost intervention relative to measurement/monitoring tooling.
Inferences:
- A team deciding where to start TDM adoption should prioritize communication rituals over tool procurement, even though most TDM research and tooling investment targets identification/measurement.
A TDM maturity score is not a valid proxy for 'how much technical debt a team has' or 'how healthy a team's software is.' strength: high
Explicit premises:
- The authors explicitly disclaim that higher maturity reduces TD.
- A team doing minimal, reactive refactoring could plausibly carry less debt than a team running all eight activities formally.
Implicit premises:
- Maturity measures process discipline, not outcome; the paper never measured actual TD volume or software quality independently of the interview data.
- Because the case company's teams were compared only against each other, there is no external baseline for what 'low TD' looks like.
Inferences:
- Any dashboard or org-level metric built from a maturity-style framework (continuous measurement/monitoring/prioritization) risks rewarding process theater rather than actual debt reduction -- a caution that generalizes directly to AI-era 'agentic' TD/velocity metrics that similarly measure activity rather than outcome.
Narratives
- In Case A, management set aside every Friday for 'bug fixing' intended partly as TD repayment time, but developers reported that in practice the day was consumed by fixing actual bugs rather than doing architectural-level refactoring.
→ Illustrates the proposition that TD prevention/repayment practices are optional in name only -- informally allocated time for debt repayment gets captured by more urgent, visible work (bugs, features) unless the allocation is protected and specific. - Several second-round teams (C-H) assigned a fixed percentage (commonly 20%) of monthly development time to internal-quality work, tracked against defined KPIs, and reviewed in monthly retrospectives with specific numeric targets.
→ Supports the claim that systematic, scheduled, measured repayment (vs. ad hoc 'repay when it hurts') is what distinguishes higher-maturity teams -- and that this requires management-level commitment, not just developer goodwill.
Questions addressed
- ✅ How do software development teams manage technical debt in real-life practice?
Answered via the eight-activity, three-maturity-level framework derived from the cross-case analysis. - ✅ Are there maturity differences in adopting TDM activities between teams?
Yes -- maturity varies by activity and by team, with the largest variance in team-owned activities (repayment, prevention, documentation, identification). - ✅ What are the biggest challenges in TDM?
Four challenges identified: lack of tools (especially for architectural-level TD), lack of prioritization models that combine technical and business value, mindset/perceived waste of effort, and the time cost of TDM competing with feature work. - ⭕ Does higher TDM maturity actually produce less technical debt or healthier software?
The authors explicitly decline to claim this -- they note maturity and actual TD volume could be independent or even inversely related for a given team. - ⭕ Why do the maturity differences cluster the way they do -- i.e., is team size, distribution (co-located vs. multi-country), or tenure/experience actually driving which teams land at which maturity level per activity?
Gaps
- incompleteThe study records team size, geographic distribution, and interviewee tenure for all eight cases (Table 1-2) but never statistically or even qualitatively correlates these attributes with the maturity differences it reports -- despite finding substantial variance. A plausible explanation (smaller/co-located teams communicate TD more easily; larger/distributed teams default to tool-mediated, lower-touch practices) is never tested even informally, leaving the paper's central explanatory variable for 'why do teams differ' unaddressed.
Read next: Later corpus work connecting team size/topology (small-teams, durable-domain-teams) to coordination overhead would let you test whether this paper's maturity variance is actually a team-size/distribution effect in disguise. - incompleteThe paper's entire empirical picture assumes a world where code generation and TD accumulation proceed at a roughly human, team-paced rate -- manual identification, hunch-based prioritization, and optional documentation are treated as viable (if imperfect) coping strategies because the volume of debt being produced is bounded by how fast humans write code. The paper gives no basis for what happens to any of its eight activities once code generation volume is decoupled from human writing speed (i.e. coding agents), even though its own findings (documentation is the first casualty under time pressure; measurement/monitoring are already the rarest activities) predict exactly where an AI-era acceleration would break first.
Read next: The corpus's velocity-debt / debt-accelerator concept and the triple-debt (technical/cognitive/intent) framework pick up precisely where this 2016 baseline leaves off -- read this paper as the 'before' picture AI-era teams are accelerating away from. - uninformedThe framework assigns documentation/representation responsibility to "the development team, software architect(s)" as an undifferentiated group, with no examination of whether documentation that exists only as unstructured JIRA tickets or personal notes functions any differently from documentation written to be read later by someone who wasn't present for the original decision -- the distinction between 'a record exists' and 'the record externalizes the rationale a future reader needs' is never drawn.
Read next: The corpus's architecture-decision-records and intent-debt concepts name exactly this distinction (a record vs. an externalized, load-bearing rationale) and would sharpen this paper's flat treatment of 'documentation' as a single undifferentiated activity.
Related documents
- Technical Debt Quadrant
- The Intent Debt
- From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI
- Agentic Code Review
- AI coding creates two kinds of debt. You're only measuring one
- The AI-Native SDLC playbook
- AI Development Patterns
- Five studies that are changing how I think about AI in software engineering
- Software Engineering at Google
- Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review