完美軟件的經濟學分析
如果問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關于炒股的技巧。經濟學家的公文包里總有最好的數據。
[本文英文原文鏈接：The Economics of Perfect Software ]
自: 外刊IT評論 http://www.aqee.net/