
doi: 10.1109/ms.2011.150
Ward Cunningham coined the term technical debt as a metaphor for the trade-off between writing clean code at higher cost and delayed de livery, and writing messy code cheap and fast at the cost of higher maintenance efforts once it's shipped. Joshua Kerievsky extended the metaphor to architecture and design. Technical debt is similar to financial debt: it supports quick development at the cost of compound interest to be paid later. The longer we wait to garden our design and code, the larger the amount of interest. Discussions of the metaphor have distinguished different types of technical debt and how and when to best pay them off. Most agree that, sooner or later, technical debt will come due. But is this assumption universally true? If it's better to pay interest, what factors influence the decision to service the debt? And if we decide to retire it, what approach should we take?
| selected citations These citations are derived from selected sources. This is an alternative to the "Influence" indicator, which also reflects the overall/total impact of an article in the research community at large, based on the underlying citation network (diachronically). | 31 | |
| popularity This indicator reflects the "current" impact/attention (the "hype") of an article in the research community at large, based on the underlying citation network. | Top 10% | |
| influence This indicator reflects the overall/total impact of an article in the research community at large, based on the underlying citation network (diachronically). | Top 10% | |
| impulse This indicator reflects the initial momentum of an article directly after its publication, based on the underlying citation network. | Top 10% |
