削弱业务成果
不仅仅是开发团队会受到糟糕代码的影响，整个企业也会因此受损。
我们可怜的用户最终会为无法正常工作的软件买单。糟糕的代码可能会以多种方式毁掉用户的一天，无论是数据丢失、无响应的用户界面，还是任何类型的间歇性故障。这些问题可能仅仅是由于在错误的时间设置了一个变量，或者某个条件语句中的 “差一错误” 引起的。
用户看不到这些，也看不到我们写对的数千行代码。他们只看到自己错过的付款、花了两个小时输入的丢失文档，或者那个从未发生的绝佳的最后机会票务优惠。用户对这种事情几乎没有耐心。这种缺陷很容易让我们失去宝贵的客户。
如果我们幸运，用户会填写错误报告。如果我们非常幸运，他们会告诉我们当时在做什么，并提供重现故障的正确步骤。但大多数用户只会删除我们的应用程序。他们会取消未来的订阅并要求退款。他们会去评论网站，让全世界知道我们的应用程序和公司有多么无用。
此时，这不仅仅是糟糕的代码；它是一种商业责任。我们代码库中的故障和人为错误早已被遗忘。相反，我们只是一个在负面舆论中昙花一现的竞争对手。
收入下降导致市场份额减少、净推荐值（NPS）降低、股东失望，以及所有其他让高管夜不能寐的事情。我们的糟糕代码已经成为一个业务层面的问题。
这并不是假设。已经有多起事件表明，软件故障给企业带来了损失。Equifax、Target，甚至 Ashley Madison 网站的安全漏洞都导致了损失。Ariane 火箭的故障导致航天器和卫星载荷的损失，总成本高达数十亿美元！即使是导致电子商务系统停机的小事件，也会很快使成本上升，同时消费者信任度急剧下降。
在每种情况下，故障可能只是相对较少的代码行中的小错误。当然，它们本可以通过某种方式避免。我们知道人类会犯错，而所有软件都是由人类构建的，但也许只需要一点额外的帮助就能阻止这些灾难的发生。
早期发现故障的优势如下图所示：
在上图中，修复缺陷的成本随着发现时间的推迟而增加：
-
在编写代码之前通过失败的测试发现：
发现缺陷最便宜、最快的方式是在编写生产代码之前为功能编写测试。如果我们编写了期望通过测试的生产代码，但测试却失败了，我们就知道代码中存在问题。
-
在编写代码之后通过失败的测试发现：
如果我们先编写生产代码，然后再编写测试，可能会在生产代码中发现缺陷。这种情况发生在开发周期的稍后阶段。我们在发现缺陷之前会浪费更多时间。
-
在手动 QA 期间发现：
许多团队包括质量保证（QA）工程师。在开发者编写代码后，QA 工程师会手动测试代码。如果在这里发现缺陷，这意味着从开发者首次编写代码以来已经过去了相当长的时间。必须进行返工。
-
在生产环境中被最终用户发现：
这是最糟糕的情况。代码已经发布到生产环境，最终用户正在使用它。最终用户发现了一个错误。错误必须被报告、分类、安排修复开发，然后由 QA 重新测试，最后重新部署到生产环境。这是发现缺陷最慢且最昂贵的路径。
我们越早发现故障，修复它所花费的时间和金钱就越少。理想情况是在我们编写一行代码之前就有一个失败的测试。这种方法也有助于我们设计代码。我们越晚发现错误，它给每个人带来的麻烦就越多。
我们已经看到低质量代码如何导致缺陷并对业务产生负面影响。我们越早发现故障，对我们越有利。将缺陷留在生产代码中既难以修复又成本高昂，并且会对我们的业务声誉产生负面影响。