如果问100个软件公司的CEO，问他们是否愿意发布含有bug的软件。他们会说什么？50个根本不愿意回答，会说一些软件bug是这个行业中一个需要解决的大问题等不着边的话；40个会说“当然不会！”，并立即给他们的投资者打电话说这是诬陷，会追究法律责任。9位会低着头说“无能为力”。而这后一位会直盯着你的眼睛说“当然会。”

　　我不知道这后一位是如何领导一个软件公司的，因为他明显学过经济学。

　　软件不可能没有bug，如果你希望发布一个完美的软件，你必须解决藏在代码里的所有bug。（想把它们挡在门外？不可能，单元测试，敏捷方法，scrum，以及任何当今你能想到的方法论，都不能防止bug进入你的代码库。如果我错了，我相信你会在评论里告诉我。）

　　正如你期望的，你在修补bug中投入越多的时间和资金，你能解决越多的bug。但是，不幸的是，我们的来自经济学的死对头，受益递减法则，同样适用于这个过程。专业的讲，这个法则指在投入生产要素后，每单位生产要素所能提供的产量增加发生递减的现象。用通俗的话讲，这是说，你能从这个过程中得到的并不等同于你所有投入的。相反，你的产出会随着投入到增加形成一条迅速下降的曲线，曲线的末端、投入到轴线上，终成为一条长尾。

　　举个例子，假如一个程序有100个bug，我们知道这需要投入100分的努力来找到并修复这所有100个bug。受益递减法则告诉我们，头40分努力将会找到70个bug，而接下来的30分努力能找到20个bug，剩下的30分努力能找到后的10个bug。这是说，头70个bug（很简单的bug）很便宜，容易找到，算起来每个bug只消耗40/70=0.571分努力。接下来的20个bug（藏的较深的bug）要昂贵的多，每个消耗30/20=1.5分努力，而后的10个bug（真正难发现的bug）惊人的昂贵，每个消耗30/10=3分努力。消灭这后的10个bug要比消灭起初的70个bug，每个bug需要投入的时间或资金要多出5倍。从付出的努力看，消灭大多数bug（70%-90%）和消灭所有bug，它们的成本有巨大差别，从数字上看相差两倍之多。

　　而在现实中，实际情况比这更糟糕。因为你不知道何时能干掉这后一个bug---没有一个像上面例子那样的倒计数——你不得不不断的去寻找更多的bug，即使是它们已经全部被干掉了，你也要去证明它们确是全部被干掉了。如果你想消灭所有的bug，你还要计算你的成本。

　　所以，消灭一个程序中所有的bug是一件代价很大的事。不妨让我们花一分钟这样思考一下：一个软件公司终决定要这么做。软件公司并没有设定像“发布没有bug的软件”的目标——他们设定的目标是“11月19号发布”——于是，这个目标改变了公司的测试计划和开发计划（不论有没有计划），这必然意味着的预算的增加。现在，你想象一下，谁会为这多出的预算买单？公司？（嗨！）如果你没有在软件公司工作过，让我来给你一点提示：非也。软件公司会把成本转嫁到客户身上。因此可以得出，你喜欢的软件都是你支付的起的软件。我得到的消息是：你喜欢有bug的软件。（开源软件也是如此。除非你愿意花更多的钱或等更长的时间。很有可能你会接受去忍受次等的软件事实。）

　　现在澄清一下，我并不是说软件公司应该发布有大量严重bug的软件。我是说他们的软件里可以有少量的小bug。

　　如何知道一个bug是大还是小？你应该思考谁会遇到它，当遇到时会发生什么样的坏情况。如果一个用户，进入第三层菜单，打开一个高级配置窗口，选中三个复选框，在敲击“A”键时得到了一个奇怪的错误信息，这是小bug。它埋的很深，当碰到它时人们会说“靠”，然后改为点击按钮，然后会愉快的做其它事情去了。如果在使用你的程序中一个常用的操作时崩溃，那这是个大bug。大部分人遇到这样的bug时都会愤怒不已。

　　所以，我要提出一个判断你的软件何时满足发布条件的黄金法则。这个黄金法则内容是，你应该不断的测试并修复软件中的bug，直到发现这些bug是：

　　不会让你的公司蒙羞。

　　不会激怒你的客户。

　　相比起让一些用户遇到这些并不在于的bug的代价，你的要找出程序中所有bug并确保全部纠正的做法代价实在太高。前提条件是，不要让用户做你的测试员——如果你这样做，必定会跟黄金法则冲突——宁愿相信所有的bug并非生来平等，有些能影响一个产品的发布，而另一些则不然。不要害怕发布的产品中有bug。如果你开发的是人们想要的好软件，一些bug的存在并不会打搅他们，尤其是当软件升级操作简便时，比如通过SaaS或Web应用。

　　如果你的软件测试符合黄金法则，那么，你的客户迫切得到的是你的软件，而不是希望你去修改那些小bug。所以，准备发布吧！

　　哦，别忘了去问那后一个CEO关于炒股的技巧。经济学家的公文包里总有好的数据。