Introduction
The metaphor of technical debt in software development was introduced two decades ago by Ward Cunningham to explain to nontechnical product stakeholders the need for what we call now “refactoring.” It has been refined and expanded since, notably by Steve McConnell in his taxonomy, Martin Fowler with his four quadrants, and Jim Highsmith and his colleagues from the Cutter Consortium with their model of the impact of technical debt on the total cost of ownership.
Consequently, the concept of technical debt in software development has become somewhat diluted lately. Is a new requirement, function, or feature not yet implemented “requirement debt”? Do we call postponing the development of a new function “planning debt”? The metaphor is losing some of its strength.
Organizing the Technical Debt Landscape
Figure 1. The technical debt landscape. On the left, evolution or its challenges; on the right, quality issues, both internal and external.
Figure 2. Four colors in a backlog.
The element areas reconcile four types of possible improvements—the tasks to attend to in the future to increase value, such as adding new features (green) or investing in the architecture (yellow), and to reduce the negative effects on value of defects (red) or technical debt (black).
A Unified Theory?
Kevin Sullivan suggested that a simple model for tackling technical debt represents a software development endeavor as a sequence of changes, most of them improvements.9 At a given point in time, the past set of changes is what defines the current state of the software. Some of these past changes are the events that triggered the current debt: the change or the way it was implemented isn’t quite right from the current perspective.
The main issue facing the software development organization is how to decide about future changes: What evolution should the software system undergo, and in which sequence? This evolution is, in most cases, constrained by cost: the resources available to apply to making these changes, most likely driven by value, as viewed by external stakeholders.
The decision-making process about which sequence of changes to apply could be the main reconciling point across the whole landscape shown in Figure 1, from adding new features and adapting to new technologies to fixing defects and improving the quality, intrinsic or extrinsic. Because this decision process is about balancing cost and value, perhaps economic or financial models could become the unifying concept behind the whole landscape.
A few have already been explored to some degree:
- Net Present Value (NPV) for a product, from the finance world;
- Opportunity cost;
- Real option analysis (ROA), or valuation;
- Total cost of ownership (TCO) for an IT system.
These four models were discussed in a recent ICSE workshop on technical debt,9 with one of them (NPV) offering the most promise: it’s better formalized than opportunity cost and simpler and less proprietary than TCO, while ROA can be seen as a probabilistic extension to NPV.
Reference:
Technical Debt: From Metaphor to Theory and Practice
Philippe Kruchten, University of British Columbia, Vancouver; Robert L. Nord and Ipek Ozkaya, Software Engineering Institute
Quote:
“Improving daily work is even more important than doing daily work.” Gene Kim,
