当你从零努力开始朝着积极方向前进时，随着你考虑越来越多的因素，也就有了越来越少的可能性，其中，很多可能性将是错误的、有 bug 的，只有很少一部分是正确的。朝着极限前进，会增加你编写正确解决方案的机会。
总结一下
找到某项任务的正确解决方案，需要记住并应用一定数量的条件。漠视或不了解其中一种，将导致 bug 的产生。和掌握并应用所有相对知识相比，引入 bug 常常更容易，因为某些相关知识没被应用的情形有很多，而考虑了所有因素的情形少之又少。
观点被证明了吗？我想说，证明过了。
更多的思考。首先，修复软件 bug 不等同于找到了正确的解决方案：需要额外的时间，首先甄别出代码中让人不爽的地方，然后思考并找到更好的解决方案。
但是，找到正确的解决方案，要比修改代码 bug（程序错误的规律）投入更多的努力，这个事实加剧了状况的恶化。因此 bug 对项目造成的损失就等于：按照错误方案编写代码所消耗的时间，加上后续寻找和甄别错误的时间，再加上团队/公司所遭受的道德或财务上的损失。这样：
推论 1：修改 bug 比起一开始就不引入 bug，需要更多的努力（常常不成比例）。
bug 存在一个至关重要的、且常被忽略的副作用，那就是一段时间以后，新员工总体优势的下降，并因此引起了 bug 产生率的进一步增加，等等。产品最初的原型阶段，常常由一组技术底子好的优秀程序员完成，一旦过了这个阶段，就进入了相对乏味和修复 bug 的工作阶段。此时，团队开始进入成本削减的螺旋上升和产品质量下降的阶段。新员工竞争力相对低些（因为没有人愿意做无聊的工作和修复 bug），因此带来了更多的 bug 等等。过了一段时间，如果管理方面不做一些非常规测量（也从没做过），软件团队就达到了某种均衡，50% 的时间花在了修复代码上（正如这项研究所展示的，尽管研究没有提到最初的原型阶段，不过，有趣的地方在于，那时候产生的 bug 也不多），更多的早期优秀员工/创始人离职、或不再写代码了。所有这些因素一定导致了一种结果，催生了第一个 bug 和糟糕的最初设计。
推论 2：低竞争优势的团队成员给团队工作造成的危害，远远大于团队竞争优势缺乏和薪水降低所带来的危害。
最终，就像某个物理系统进入混沌状态、且处于「无人值守」的境地一样，软件项目步入了杂乱无章，典型的软件血汗工厂，充斥着得意忘形的团队、不可维护且 bug 林立的代码库、财务损失、了然无趣。到达混沌比远离混沌要容易得多。
推论 3：在产品生命周期的各个阶段，只有有意识的协作努力，才能使 bug 最少，也才能为享受编程和削减开发成本提供保障。因此，任何编程「方法论」，如果在最后没有论证出减少的 bug 产生率，那么，不管它说得多么天花乱坠，都是扯淡。
推论 3.1：如果你独自编程，那也挺好。只要确保别把 bug 和 「让人厌烦」的工作悄悄带入你的项目，就没有雇佣更多人的必要。
源自公众号 自动化软件测试