Nearly two decades ago, Ward Cunningham introduced us to the term "technical debt" as a means of describing the long term costs associated with a suboptimal software design and implementation. For most programs, especially those with a large legacy code baseline, achieving zero absolute debt is an unnecessary and unrealistic goal. It is important to recall that a primary reason for managing and eliminating debt is to drive down maintenance costs and to reduce defects. A sufficiently low, manageable level of debt can minimize the long-term impact, i.e., "low debt interest payments". In this article, we define an approach for establishing program specific thresholds to define manageable levels of technical debt.
No takes yet. Share an insight, caveat, or question.
Robert J. Eisenberg (2012) studied this question.
Synapse has enriched 5 related papers. Consider them for comparative context: