技术负债概念提出者Ward Cunningham认为：长期开发一个应用程序时，我们是通过不断添加功能进行的，但是却从未对其进行重新组织以反映我们对这些功能的理解，那么最终该程序将根本不包含任何理解，因而在其上继续工作编程所付出的努力将花费越来越长的时间。
知识管理在组织中是如此重要，但是他们很少经过关键的重构来反映当前的理解。
必要时需要进行大规模重构。如果组织的营业额足够大或产品中的功能不断增加，那么进行重写是最好的选择，这样您的团队对代码有个整体的了解。不能指望人们在繁忙的编程中会实现难以理解的需求，或者在已经离职人的遗留代码中提高工作效率。
使用一个通俗解释：如果吃完饭不洗碗不打扫厨房，那么慢慢地就吃不到下一顿饭，重构就是洗碗。
技术债务不是写得不好的代码：您编写代码是为了反映您对问题的*当前*理解。如果这种理解是“部分的”，那么您将承担债务，即使如此，您仍会交付软件（以了解更多信息）。但是，您必须偿还债务：您必须将新的知识纳入软件。
这就催生了两个阶段，第一个阶段是你部分理解业务的代码，第二个阶段是你偿还债务纳入新理解的代码，您必须满足第一个紧迫的阶段以后（先交付原型获得客户认可），才能获得后续第二个阶段所需的经济资源（客户肯定你没有走错方向，提供资源让你继续按照这个思路走下去）。因此，您需要做出战略决策，为第一阶段编写次优设计。之后，您可以偿还债务并在第二个阶段之前改进设计。
关键是必须*偿还债务。您支付的能力取决于代码的干净程度（因为您需要重构）。
- 干净的代码是技术债务的前提。
- 过度耦合的无法维护的代码库不是技术上的负担。只是一团糟。
但是，根据精益起步创业（Lean Startup）的方法，这种债务对于创业起步公司几乎是强制性的。但是正如您所说，对于科技创业公司来说，有必要编写简洁的代码以偿还债务。
对于开发人员无法消除的诅咒是：您只了解代码，但您却很少是领域专家，因此当按期限要求时，您会假设有关领域的知识，但是这种第一性假设后来被证明是错误的...
获得领域的经验确实是一个挑战，并且可以说是构建高质量软件的关键之一。这就是为什么人们喜欢强调领域域驱动设计（DDD）原因。