軟件故障的代價可以通過不同的方式來感知，例如，以上市公司的股票價格或在小公司中的股票價格，這可能意味著倒閉。

我經常看到組織發布軟件的方式與玩俄羅斯輪盤賭一樣安全——與客戶的安全性，私人數據和安全性進行賭博，更不用說可靠性了。他們還賭博自己公司的聲譽和底線。IEEE幾年前發布了一份出色的公共故障清單，您可以確定軟件仍在故障。

我喜歡這種有點嚇人的類比的原因是，我經常聽到人們說諸如“該軟件已經存在很長時間并且沒有出現問題”或“我們一直以這種方式做到這一點，有效”——但當然，這是一種不好的計劃方式。一家專注于軟件工程的公司正在尋找構建和發布故障更少的更好軟件的方法。這意味著即使到目前為止做錯了事，也要通過做正確的事來積極地計劃成功。

哈佛大學的研究人員發現，大約一半的IT軟件項目都會失敗。有很多其他人的數字，而且這個估算值并不是最高的，所以讓我們花點時間。這就像在房間里打3枚子彈的俄羅斯輪盤賭一樣——失敗的機會為50-50。我不喜歡這些困難，當然也不會賭博我公司的未來。

讓我們看一下人們每天發布軟件時所進行的一些令人討厭的賭博。如果您愿意，請使用輪盤賭槍的子彈：

1.古老的“臭蟲”

我們都知道我們會發布帶有錯誤的軟件，因為完美無瑕的軟件將永遠被制造出來。但這絕不是解決我們所知錯誤的借口。關于技術債務的說法很多，但都非常抽象，但這是軟件中債務的一種實際實用度量。如果那里有錯誤而您沒有解決，則最好有充分的理由認為它沒有關系。為每個版本計劃一些時間，不僅要添加新功能，還要使總體情況變得更好。花一些時間來完善您的軟件。

2.舊代碼中的新錯誤

舊代碼很棘手。我見過一些公司的政策是“無論如何都要對其進行清理，都要清理”，而其他一些公司的政策則是“僅觸摸您必須具備的條件，并且只有在存在現場報告的錯誤時”。兩者都是有趣的政策，但是最重要的是要了解在舊代碼中發現新錯誤時所涉及的風險。我曾與一家硬件供應商合作，他們在如何處理一些舊代碼上的新工具的輸出方面苦苦掙扎。在他們的情況下，這是一個模棱兩可的范圍問題，仍然讓我想知道他們的編譯器如何允許這種瘋狂。他們陷入了沖突——一方面，他們擁有了這個新工具；另一方面，除非現場提供了錯誤報告，否則他們不應該接觸舊代碼。

了解您打算對遺留代碼執行的操作很重要，同時也要充分了解其對組織的風險。如果代碼很關鍵，那么年齡可能并沒有您想的那么重要。如果不贊成使用該代碼，則可能是您在浪費時間測試您不打算解決的問題。

3.安全是測試而不是開發的一部分

對于組織而言，忽略安全性是非常令人沮喪的事情。在某些情況下，他們認為可以在應用程序中測試安全性（不能），而在其他情況下，他們認為安全性問題不適用于他們的代碼（可以）。為了擺脫這種持續不斷的安全失敗的麻煩，組織必須使用可靠的AppSec最佳實踐來強化代碼，這在靜態分析工具中已得到了廣泛的應用，而靜態分析工具不僅僅可以進行流程分析。如果您不知道從哪里開始，那么簡單地采取MISRA規則并從今天開始編寫的任何代碼開始遵循它們就不會受到傷害。

4.永遠失敗，不斷通過的測試套件

我看到的一種極為常見和危險的做法是擁有一個龐大的測試套件，并依靠通過的測試數量的簡單度量。例如，您通常具有80％的通過率，因此您認為這會很好。問題在于，無法知道今天通過的80％是否與昨天通過的80％相同。很可能會因為80％（有）隱藏了新的實際故障，因為其他問題已解決，從而使故障數保持平衡。保持您的測試套件干凈，或者告訴您的內容不多。我會嚴重質疑您可以輕松忽略的測試失敗的價值。為什么不跳過該測試——這是一種更誠實，更有用的方法。

5.發布日歷

日歷仍然可能是最常見的關鍵發布標準。人們選擇了一個日期，現在要發布，因為該日期到了。當然，有一些外部問題會影響您的發布時間表，但僅僅是因為日期已到，并不意味著可以將拙劣的軟件推銷給毫無戒心的即將成為客戶的客戶。準備就緒/安全/穩定/良好時釋放。如果日歷是固定的約束，請確保您的流程將按時到達。

綜上所述

您可以先釋放多少次才能付清代價？以我們的俄羅斯輪盤賭為例，最多六個，也許只有一個。讓我們竭盡所能，以確保我們將交付具有最佳成功機會的最佳軟件。