软件系统很容易产生杂物——内部质量的缺陷使得进一步修改和扩展系统变得比理想情况下更难。技术债务是一个由沃德·坎宁安 (Ward Cunningham) 创造的比喻，它描述了如何考虑如何处理这些垃圾，将其视为金融债务。添加新功能所需的额外努力是支付的债务利息。
想象一下，我的代码库中有一个令人困惑的模块结构。我需要添加一个新功能。如果模块结构清晰，那么我需要四天时间来添加功能，但是如果有这些杂乱的东西，我需要六天时间。两天的差额是债务利息。
债务隐喻最吸引我的是它如何构建我对如何处理这些债务的看法。我可能需要五天的时间来清理模块化结构，去除那些杂物，比喻为本金还清。如果我只为这一项功能做这件事，那没有任何好处，因为我需要 9 天而不是 6 天。但是如果我有两个更多类似的功能出现，那么我会通过首先删除 cruft 来更快地结束。
这样说来，这听起来像是处理数字的简单问题，任何拥有电子表格的经理都应该弄清楚选择。遗憾的是，由于我们无法衡量生产力，因此这些成本都无法客观衡量。我们可以估计完成一个功能需要多长时间， 估计如果去除残留物会是什么样子，并估计去除残留物 的成本。但是我们对这种估计的准确性非常低。
鉴于此，通常最好的方法是像我们通常处理金融债务一样，逐步还清本金。在第一个功能上，我将花额外的几天时间来去除一些杂物。这可能足以将未来增强的利率降低到一天。这仍然需要额外的时间，但是通过删除这些问题，我可以降低未来更改此代码的成本。像这样逐步改进的巨大好处在于，它自然意味着我们花更多的时间在那些经常修改的区域中删除 cruft，这些区域正是代码库中我们最需要删除 cruft 的区域。
将此视为支付利息与支付本金有助于确定要解决的问题。如果我有一个糟糕的代码库区域，那是一个噩梦般的更改，如果我不必修改它，这不是问题。我只在我必须使用软件的那部分时才触发利息支付（这是一个比喻失效的地方，因为金融利息支付是随着时间的推移而触发的）。因此，可以不理会粗糙但稳定的代码区域。相比之下，活动频繁的地区需要对垃圾零容忍态度，因为利息支付高得惊人。这一点尤其重要，因为 cruft 会在开发人员在不注意内部质量的情况下进行更改的地方积累 - 更改越多，cruft 积累的风险就越大。
债务的比喻有时被用来证明忽视内在质量是合理的。争论的焦点是，阻止垃圾堆积需要时间和精力。如果有迫切需要的新功能，那么也许最好承担债务，接受将来必须管理这些债务。
这里的危险在于，大多数时候这种分析都做得不好。Cruft 的影响很快，会减慢快速需要的新功能的速度。这样做的团队最终会用尽他们所有的信用卡，但仍然比他们努力提高内部质量时交付的时间晚。这里的比喻常常使人们误入歧途，因为动态与金融贷款并不真正匹配。只有当你保持在DesignStaminaHypothesis的设计回报线以下时，承担债务以加快交付才有效，并且团队在几周而不是几个月内达到了这条线。
是否应将不同种类的残渣视为债务存在定期辩论。我发现考虑债务是否是故意获得的以及它是谨慎的还是鲁莽的很有用 - 将我带到TechnicalDebtQuadrant。
进一步阅读
据我所知，Ward 在OOPSLA 1992的经验报告中首先引入了这个概念。wiki上也讨论过这个问题。
沃德·坎宁安 (Ward Cunningham) 进行了一次视频演讲，讨论了他创建的这个比喻。
戴夫·尼科莱特 (Dave Nicolette) 通过对我所说的 谨慎的故意债务进行了很好的案例研究，扩展了沃德对技术债务的看法
一些读者送来了一些类似的好名字。David Panariti 将丑陋的编程称为赤字编程。显然，他最初是在几年前开始使用的，当时它符合政府政策；我想现在又很自然了。
Scott Wood 建议：“当当前的技术水平超过产品的基础水平，以至于它开始失去与行业的兼容性时，技术膨胀可以被视为失去的基础。这种情况的例子将是语言到您的代码不再与主流编译器兼容的程度。”
史蒂夫麦康奈尔在这个比喻中提出了几个好处，特别是如何保持你的非故意债务让你有更多的空间在这样做有用的时候有意识地承担债务。我也喜欢他的最低付款概念（对于解决嵌入式系统而不是网站的问题来说非常高）。
Aaron Erickson 谈论安然融资。
Henrik Kniberg 认为，造成最大问题的是较旧的技术债务，并且通过定性债务上限来帮助管理它是明智之举。
Erik Dietrich 讨论了技术债务的人力成本：团队内讧、技能萎缩和人员流失。