2025 年 3 月 9 日，同事 Scott Porad（CTO、VP 工程）在 LinkedIn 上发帖询问“还有哪些其他类型的债务，如技术债务？”，他列出了一些，然后请求其他人发表意见，列表逐渐变长且有趣，引发作者深入思考该隐喻。

• 他列出的债务类型：包括金融债务（原始类型）、产品债务（产品中的差距影响收入或导致支持成本）、运营债务（运营团队因软件不支持而执行的手动流程）、流程债务（软件开发过程中被跳过的有价值步骤导致质量或速度问题）、组织债务（未配备的关键角色导致质量或速度问题）。

• 其他人补充的债务类型：

  • 技术类：数据、用户体验/设计、后端，甚至过度依赖开源而不“回馈”，文档也在此类。
  • 程序类：手工执行的流程耗费团队时间、金钱或精力，“轻量级流程”焦点隐藏的事物。
  • 心理类：做出的假设后来被证明是错误的，过去正确的假设现在不再适用，组织是否在追逐正确的问题，人员缺少哪些知识。
  • 文化类：人类群体形成的文化是否服务于业务或阻碍业务。
  • 人才类：缺乏对初级人才的投资或拒绝认可团队中有经验的资深人才的价值，人员数量不足等。
  • 支持类：如营销（忽视营销实践导致品牌和客户关系受损）、法律（未识别法律/监管必要性使公司陷入法律风险）。
• 债务的隐喻起源：2000 年代后期 NFJS 巡回赛中 Mike Clark 提出，Wikipedia 称 Ward Cunningham 于 1992 年创造该术语，将短期决策比作债务，投资可重构代码，技术债务官方定义为选择便捷解决方案导致未来额外工作成本。Ward 称首次发布代码像负债，少量债务可加速开发但需及时偿还，否则会增加未来成本和复杂性。Martin Fowler 也涉足该领域，将债务分为故意（如汽车贷款、抵押贷款）和意外（如信用卡债务），并比作沿两个轴的象限。
• 债务与进化/迭代的关系：作者意识到有时承担债务是因为不知道未来，如初创公司需要“转型”，否则前期投资可能白费，陷入沉没成本谬误。大多数“债务获取”案例中，决策者面临是否尽快发布的困境，隐含着后期可能错过机会的风险，而“后期”部分很少被提及。在“债务结果”图表中，讨论和焦虑主要集中在选择债务/便捷性导致失败的结果上，而选择无债务/“正确”导致成功的结果很少被讨论。
• 总结：债务隐喻有效，适用于多种类型的债务，Fowler 的象限有助于分类债务决策，但依赖个人描述差异，事后分析是一种特权，债务本身不一定坏，只有无意/鲁莽的债务才会引发焦虑。