The notion of Technical Debt (TD) in software development was introduced in 1992 by W. Cunningham, and since then refined and expanded, notably by S. McConnell in his taxonomy, Martin Fowler with his 4 quadrants, J. Highsmith and I. Gat etc. As a convenient metaphor to expose many ills of software development, technical debt has received lately a lot of attention from the agile community. As a result of its success as a rhetorical concept, the notion of debt becomes somewhat diluted. Is a visible bug or defect really a kind of technical debt? Are code smells technical debt? Is a new requirement, a new function or feature not yet implemented requirement debt? Is debt only about bad low quality code? How about architectural debt, incurred inadvertently, just because of the passing of time? Can’t we just walk away from the debt? In this presentation, I will organize the technical debt landscape, reconciling it with the notions of changes, improvement and evolution, and propose that economic theoretical models, such as Net Present Value, Total Cost of Ownership, Opportunity Cost, or Real Options Analysis can constitute the framework needed to reason about technical debt. We can then review in the light of this approach the tools and techniques proposed by various vendors (Sonar, Cast, SIG, ...) to help us identify technical debt.
Voting on Ideas
Vote for your favorite ideas by clicking on the up arrow.To undo an upvote, simply click the arrow again. This second click removes your vote.