Kruchten Philippe, Nord Robert L., Ozkaya Ipek. Technical Debt: From Metaphor to Theory and Practice

IEEE Software, 2012. — 4 p.Philippe Kruchten, University of British Columbia, Vancouver
Robert L. Nord and Ipek Ozkaya,
Software Engineering InstituteThe 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.
From the original description—“not quite right code which we postpone making it right”—various people have used the metaphor of technical “debt” to describe many other kinds of debts or ills of software development, encom- passing broadly anything that stands in the way of deploying, selling, or evolv- ing a software system or anything that adds to the friction from which soft- ware development endeavors suffer: test debt, people debt, architectural debt, requirement debt, documenta- tion debt, or just an amorphous, all-encompassing software debt. 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.
Furthermore, once we identify tools such as static code analyzers to assist us in identifying technical debt, there’s a danger of equating it with whatever our tools can detect. This approach leads to leaving aside large amounts of potential technical debt that’s un- detectable by tools, such as structural or architectural debt or technological gaps. Gaps in technology are of particular interest because the debt incurred isn’t the result of having made a wrong choice originally, but rather the result of the context’s evolution—the passing of time—so that the choice isn’t quite right in retrospect. Technical debt in this case is due to external events: tech- nological obsolescence, change of en- vironment, rapid commercial success, advent of new and better technologies, and so on—in other words, the invisible aspects of natural software aging and evolution. You could even argue that “gold plating” an architectural design, making the system more flexible and adaptable than it actually needs to be, can be a form of technical debt, if this added flexibility hinders future development without actually being exploited.