程序员如何偿还技术负债软件系统常常建立在内部质量有缺陷的代码之上，因此比理想情况下更难修改和扩展系统。技术负债是WardCunningham提出的一个比喻，形容这个问题就像金融债务一样，添加新功能时，需要付出的额外努力就好像债务利息。
假设偶的代码库中有一个混乱的模块结构。此时，偶需要添加一个新功能。如果这个模块结构清晰，那么偶只需要4天时间就可以添加好这个功能，但是如今这个模块的结构很混乱，所以偶需要6天时间。多出来的这两天就是债务利息。
关于债务的这个比喻最吸引偶的地方在于，它让偶思考如何处理这个问题。假设偶可能需要5天时间来清理这个模块化的结构，改好不健全的功能，这就相当于支付本金。如果只有这个功能需要用到这个模块，那么就得不偿失，因为偶总共需要9天时间，如果偶继续容忍这个模块的话只需要6天。然而，如果有两个相似的功能都用到了这个模块，那么偶肯定会首先改好这个模块来加快速度。
如此说来，听起来这是个简单的数字问题，凡是有电子表格的经理都应该能够做出很好的选择。遗憾的是，大家并不能很好地衡量大家的生产力，因此这些成本都无法客观地衡量。大家可以估算完成一个功能需要多长时间，大家需要估算做新功能的时间（在改好模块后的情况下），以及改好这个模块的时间。然而，大家的估算的准确性非常低。
鉴于此，通常大家的做法是：背负着负债继续做新功能，并逐步支付本金。在做第一个功能的时候，偶会花额外的几天时间来修复一些不健全的功能。这可以将未来的利息降低到一天。虽然这之后大家仍然需要花费额外的时间，但是这些代码附带的负债会降低。这种逐步改进的好处在于，如果大家频繁地改动某个有待修改的负债，那么就证明这些代码正是最需要被清理的区域。
这种用支付利息代替支付本金的方式，可以帮助大家决定优先解决哪个负债。假设有一个非常可怕的代码库，修改这个代码库简直就是一个噩梦，如果偶没有必要动这个代码库，那就不是个问题。只有当偶用到这部分软件时，才需要支付利息（这是这个比喻与金融上的负债不同的地方，因为金融的利息支付是由时间决定的）。因此，大家可以不必理会那些稳定的负债。相比之下，活跃度非常高的区域需要非常及时地修改，大家应该采取零容忍的态度，因为这部分债务的利息非常高。这一点非常重要，因为开发人员往往只知道一味地更改代码，却不关注内部质量的时候，这些负债将不可避免地积累起来——代码变更越多，风险就越大。
有时，这种债务的比喻也可以判断是否应该忽略内部质量。关键在于大家需要付出时间和精力才能阻止负债的积累。如果有些新功能非常迫切，那么也许大家不得不继续背负债务，只有等到将来再来处理这笔负债。
然而，大多数时候大家的这种分析做得都不好。另一方面，技术负债的影响非常快，会迅速拖慢新功能开发的速度。不断积累负债的团队最终都会被自己的债务搞得一塌糊涂，大幅延迟交付，所以还不如趁早努力提高内部的质量。这个比喻往往会让人误解，因为这种发展趋势与金融贷款并不完全相同。
人们经常会争论是否应该将不同种类的质量问题视为债务。偶觉得大家应该考虑这些债务是有意造成的，还是一时不小心造成的。