在以往开发人员并不担心，他们创建一个文件开始按照自己的想法编程。然而对于当今大多数开发人员来说，那些随心所欲、不受阻碍的日子早已一去不复返了。如今，许多软件开发都在修改、扩展、增强和发展之中，开发人员经常地完成别人以前做的工作。而这会出现所谓的技术债务。
“技术债务”一词是指尚未完成的事情。所欠的债务是人们必须回过头来，通过修复或填补空缺进行纠正，这可能是在上周、上个月甚至几年之前所做的事情。
在计划阶段，该术语是经常被遗忘的工作。利益相关者已经在酝酿新功能，并增加更多的功能，但是如果有人不加推广，原有的增强功能将永远无法发挥全部潜力。丢失或损坏的代码会在错误的时间失败，从而使他们陷入困境。
该术语的棘手部分是“债务”一词，它表明是一种义务和契约，有时是道德的，有时是法律的。债务人如果不还债可能面临牢狱之牢，但是在软件世界中，技术债务可以说是另一种牢狱。
以下是有关软件堆栈存在技术债务的12个秘密。
1.技术债务并不是天生就坏
“债务”一词听起来很糟糕，但并不总是反映出错误的判断。技术债务几乎总是从一系列新的软件开发中产生，这些开发过程通过添加一系列新特性来扩展软件堆栈。开发人员可以并没有增加更多的功能，但可能专注的一点就是负面因素。技术债务实际上是开发过程中留下的阴影。
2.技术债务确实是无限的
技术债务清单对于软件人员似乎不堪重负，但实际清单却可能更多。它实际上是软件不执行操作的列表，并且这种列表是无限的。人们可能会关注以下事实：它无法正确导出PDF文件或某些CSS选择器过于通用，但它也没有实现所有最新的人工智能算法或使用量子安全加密算法。那么它能读懂人类的思想吗?关键是，技术债务无法计量或编纂，这很难达成目标。
3.并非总是欠着技术债务
技术债务通常让人寑食难安。有人可能会认为，需要扩展一些数据存档或重建一些API来接受不同的查询，但大多数企业在没有作出决定的情况下可能做得很好。
4. 没有人真正讨债
技术债务并不像金融债务那样，如果不偿还，债主就会上门讨债。技术债务纯粹是一种内部会计机制，可以帮助人们跟踪需要完成的工作。就像一个“待办事项”记事本一样。
5.技术债务有时可能像金融债务一样
技术债务的棘手问题是某些技术债务在财务方面面临严重的问题。如果API不支持JSON，则重要的客户可能会离开。也许新的竞争对手通过提供与NoSQL数据库一起使用来窃取客户的数据。企业面临的挑战是衡量这种财务风险，然后做出明智的业务决策。如果债务的负面影响远小于偿还债务的成本，那么忽略债务是有意义的。但是，如果成本很高，那么是时候开始解决这个问题了。
6.技术债务可能是政治幻想
许多想要解决某些技术债务的人都坚定地处于某个政治阵营中，他们使用“债务”一词，因为它听起来比“技术愿望清单”更具说服力和诚意。这些可能对企业的未来发展和正在开发的软件很重要要。如果企业想在新泽西州获得更多的合同，那么，确保其软件在新泽西州的客户中运行良好可能是一件好事。如果这不是企业目标的重要组成部分，那么可能不需要偿还债务。
7.技术债务有时像皮疹一样消失
许多人可能得过皮疹，但因为其自身原因能够自我愈合可能对此忽略。技术债务通常也会自行消失。在当今，支持某些基本文件格式似乎很重要，但是有时会出现一种新的文件格式取代了原来的文件格式，并且由于每个人都可以忘记了它，因此不必支持原有的文件格式。在这种情况下，技术债务就会消失。
8.技术债务很难确定
团队中有人称，“技术债务”真的是债务吗?还是仅仅是某人想要的功能?到底欠用户什么呢?因此很难确定技术债务。
9.技术债务通常只是表面上的文章
有时，技术债务栏中的一个功能只不过是表面上的文章。对于管理人员来说，这始终是一个问题。有些问题需要精心编写当前软件堆栈的大部分内容，而某些问题可以通过对当前代码库进行一些巧妙的重新打包而消除。面临的挑战是如何判断听起来像是技术难题的东西，并且为了提供成本最低的功能做出切实可行的决策。
10.技术债务从未清算
编剧之所以喜欢技术债务，是因为他们可以推动主角的发展，并拥有令人满意的解决方案。例如在电影中，Nick Cage以前发誓这一生中必须偷走50辆车。而在偷窃了49辆之后，他仍然欠债。当他偷了第50辆车时，其债务已清偿，但他因此而入狱。
技术债务并不一样。可以肯定，一旦开始接受XML文件，就不会再收到明确要求。对XML输入的请求将被这个新特性的技术支持所取代。新的代码产生了新的问题，技术债务用新的代码来解决。
11.技术债务不是数字，因此难以衡量或跟踪
虽然货币债务可以用数字衡量的，而技术债务是无法衡量的。当然，敏捷团队将尝试计算实现某点所需的“点数”。精明的管理人员将能够以小时为单位估算开发人员的时间。但是这些全都是猜测，任何事情都可能发生。
12.技术债务可能是一个机会
有一个笑话是，如果某人欠银行10万美元，那么就会遇到麻烦，但是如果欠银行1亿美元，那么银行可能就会遇到麻烦。有些开发人员可能会谈论技术债务，但它更像是客户与供应商之间的游戏。
如果某人可以在其他地方开展业务，需要获得这个业务。那么最好修复其代码。但是，如果某人确实需要软件堆栈并且无法轻松迁移，那么技术债务可能确实是向用户加价销售的技术机会，但用户会为新功能支付多少费用?
