昨天在#SCNA(北美2010軟件技術大會)的一個專題小組討論會上，@chadfowler 提出了這個問題：”有多少項目是因為程序的原因而失敗的？“我想，他是想說造成項目失敗的主要原因是業務問題，而非技術問題。

　　今天早上我把這個問題發布在了微博上。很快就有了回復，幾乎所有人都認為導致項目失敗的原因中業務問題是罪魁禍首。

　　完全沒錯，項目會因為成本，需求，進度計劃，管理等問題而失敗。可同樣沒錯的是，從來沒有人在追查失敗的原因時會深入到像程序代碼這樣底層的東西上。所以，Chad的觀點——如果真像他想的那樣——是有一定的參考價值的。

　　我們可以從中得到結論：從長遠的角度看，程序代碼并不是那么重要，技術人員的勞動也許只是些大量的些微小事。事實上，Chad在#scna上的演講中希望我們去認真思考這個問題。如果我們按照他的觀點去做，我們就應該降低對技術能力的重視，增加對業務，需求，預算，計劃和管理工作的重視。

　　在我反駁這個觀點之前，我要說，我碰巧知道好幾個因為程序的原因而失敗的項目。事實上，我還知道幾個因為程序的原因而失敗的公司。

　　相信和理解這種事情并不是非常的困難。我們都知道，當程序代碼混亂時，它會變得越來越難以維護和改進。當這種成本超過了一個項目可以承受的能力后，項目就失敗了。當這種成本超過了一個公司所能承受的能力后，公司就倒閉了。在我知道的這些案例中，這些事情就是這樣真實的發生著。很簡單，就是代碼的開銷超過了它的商業模式的承受能力。

　　讓我們在腦子里做這樣一個推演。如果程序代碼的生產和維護成本無限的昂貴，項目的哪部分會失敗？很顯然，由于程序代碼過于昂貴，超過任何有限的商業模式的承受能力，所有項目都會失敗。

　　那好，如何程序的生產和維護不會產生任何的代價，那會怎樣？項目的什么部分會因為這種程序而失敗？同樣，答案很明顯。如果這種程序代碼不會產生任何成本，沒有項目會因為此而失敗。

　　什么叫做沒有成本代價？這是說當你需要它時你能立即得到。程序已經在那里了，即時的，功能齊全的，沒有缺陷。任何時候你想修改它，修改工作能立即完成，自動部署，馬上生效。

　　就好象是你被強盜丟進了一個山洞里，在這個山洞里你發現了一個老實的PC機，帶著一個很老式的鍵盤。你拿起鍵盤，擦了擦臟兮兮的Enter鍵。哦，一個精靈出現在了屏幕上，它給予了你能夠生產零成本的程序代碼的能力！從這時起，還會有什么項目會失敗？

　　你要明白，沒有第二個人擁有你這樣的能力；沒有第二個人能即時的生產出沒有缺陷的想要的任意程序代碼；沒有第二個人能夠不費時間的修改和部署變更的程序。你擁有絕對的競爭優勢。你還有失敗的可能嗎？我想我的小狗Petunia也許會弄失敗，但任何比它聰明的生物都會因此而成為億億萬富翁。

　　如果我們有了這臺神奇的PC機，我們就不會再有進度計劃和預算問題。管理失誤和需求不確定的成本會趨近于零。所有會導致項目失敗的因素都會變的無關緊要。

　　可是我們沒有這樣神奇的PC機。程序代碼的生產和維護會消耗資金。但如果我能擁有這個神奇精靈的一點點能力，我可以去降低代碼生產和維護的成本，同時我還能降低由于管理失誤、需求不確定、工期緊張、預算緊張所帶來的成本和風險。通過降低事情的這些成本，我們降低了犯錯的成本，增加了成功的幾率！

　　為什么項目會因為需求不確定、管理混亂、計劃不正確、預算有問題而失敗？是因為犯錯的成本太高。為什么犯錯的成本很高？因為程序代碼的成本高的可怕。如果程序代碼不會帶來成本，犯錯的成本代價也就會趨近為零。

　　這種認識在各公司中還是有共識的。他們試圖通過壓縮程序員來解決這個程序成本問題。他們冒著巨大的風險花大價錢從地球的另一邊雇傭具有各種不同文化的編程人員。他們面對著時區和語言的問題，文化的不匹配問題。而選擇這一切都是為了降低程序的成本。他們這樣做，是因為他們知道這種成本壓迫著管理的成本。他們這樣做，是因為這種成本會導致項目失敗。

　　不幸的是，這種策略并不像我們希望的那樣奏效。可能有些這樣事情做的不錯，但大部分外包的效果令人失望。于是程序的成本仍然居高不下，同樣，失敗的風險也高居不下。

　　再回到我們最初的問題上。有多少項目因為程序代碼的原因而失敗？根據上面的討論，所有的失敗都是由于程序的成本導致的。有多少項目因為程序代碼的原因而失敗？全部。

　　更重要的是，唯一有效的能增加項目成功的機會的方法是什么？是改進需求？管理工作？進度計劃和預算？這些方法都有幫助，但對于導致項目失敗的原因，他們都是次要的，都比不上：程序的成本。

　　[英文出處]：The Cost of Code?