當預期跟現時不符合時會令人失望，而我們對於軟體的品質的期望非常的不實際，但很多人還是對於 bug 很失望甚至憤怒。他們不需要這樣。

唯一可以穩定且廣泛可以確保軟體品質的方法是更少的程式做更少的事。但這種方式在商業軟體或甚至程式都非常少見（雖然他們很多人這樣自己宣稱）。

你想過市場會怎麼反應如果 iPhone 7 最大的改進是減去三分之一的功能以降低 bug？對，跟我想的一樣。人們會要開發團隊修正這錯誤的方向，這不是他們會買的東西。

這裡有個爭論：Apple 這麼有錢，他們為什麼不僱用更多的開發者跟測試人員來修正所有的 bug？引述 Frederick Brooks 說的：沒有軟體開發這樣做，更大的團隊通常只會讓問題變更大。

bug 在軟體中是無可避免的。當然有很多技術和方法保證可以降低多少這種該死的東西，但要完全避免只有在漫畫般誇張的劇情中有可能發生。

在我們接受這個簡單的事實：software = bugs，我們才可以開始了解為什麼修理 bug 甚至可能不是最重要的事情。bug 出現只是軟體會成功的其中一項變數，但絕對不是最重要的一項（除了一些攸關生命的系統）。

沒用的軟體可以完全沒有 bug，但它仍然是沒有用處的。有用（Useful）的軟體可以忍受 bug 但仍然有高價值。一個軟體的價值取決於它做事的品質而不是它解決的 bug。

有時候二分法並不是黑白分明的。有個兩個軟體解決一樣的問題，你覺得其中比較少 bug 的比較好，這很合理。但連這麼簡單的狀態通常都不被市場接受（laughably disproven）的。使用率、整合、品牌、有趣這也都是頂尖品質（trump quality）的因素。

有這麼多對未來更重要的因素，不是每個 bug 都得到「把手邊的事情放下，我們一定修理這個」的優先等級，這真的讓人很驚訝嗎？當然不，但遇到 bug 的使用者仍然這樣認為。

這真的讓人困惑到極點，當使用者不斷要求且貶低軟體開發者去修理一些很小 bug 只因為他們碰到這個 bug，只因為這可能導致一點點的問題。

bug 的價值取決於受影響的使用者的時間、這件事的重要性。

很多使用者的資料因為這個 bug 遺失嗎？如果是，那這該死的重要！現在馬上修！很多使用者對此有點困惑或懊惱？可能應該之後趕快找時間修。一些使用者需要多花三十秒才能達到他們想要的，這不像是要趕快修的東西。

在企業裡的軟體部門是這樣分類 bug 的。他們不會放下所有事情來處理這該死的 bug。隨著整體規模愈大，伴隨來的效應也是。大型的軟體會有幾百個或是幾千或是幾萬個不同重要性的 bug。這很正常。這是預期中的。

這不是要大家放棄軟體品質，實際上相反。這是叫大家對於世界不如他們預期時，丟掉高情緒化的反應。讓開發者丟臉或質疑他們的專業度（不管他們是什麼意思！(whatever that means!)）或是強迫開發者趕快做任何事，包括使用者，這更糟糕。

所以下次你遇到一個惱人的 bug，在你發出一篇憤怒的 tweet 之前給自己五分鐘，讚嘆現代軟體的奇蹟，想想那數億行讓 CPU 正常運作的程式碼，好讓你享受這電腦的光輝（splendors）。給這些人跟機器一些同情吧。

原文：Software has bugs. This is normal.