最初的問題

　　上周，在SCNA(北美2010軟件技術大會)的一個專題小組討論會上，Chad Fowler (@chadfowler)問道，“有多少項目是因為程序的原因失敗的？”。按當時的情形，我想他的觀點是，項目的失敗歸咎于業務問題，而非程序。會議室里很安靜。可以看出，全體成員認為他說的是有道理的。我相信大家是都同意Chad的觀點的。項目的失敗，罪不在于程序，在于業務問題。

　　后續調查

　　Uncle Bob (@unclebobmartin)后來做了一次簡單的微博調查，我和其他很多人都參與了。調查的結果是，贊成項目失敗的責任主要歸咎于業務問題、而非技術問題的占了絕大多數。Bob感到這么多人選擇這樣的觀點表明了從長遠角度看，程序不是那么的重要，因此，技術人員也一樣顯的不那么重要。

　　Bob認真了提出了一些很好的論據來說明為什么程序很重要，來說明事實上，程序不僅能使項目失敗，而且會使整個公司倒閉。我在這里不做更多的復述，我強烈推薦你們去讀一下Bob的這篇文章， “The Cost of Code?” (外刊IT評論網提供了這篇文章的中文全文翻譯)，Bob在這篇文章里的大部分觀點我都贊同。程序的成本很大。但我不認為所有的項目的失敗都歸咎于程序，但他用來說明這個觀點的例子都很有價值。

　　原因和責任

　　證據確鑿

　　一個人死了，一顆子彈擊中了他的胸膛。一個項目失敗了，只剩下一堆沒有的程序碼。對于我們來說也許事實很清楚，一顆子彈殺死了這個人。對于我們來說也許事實很清楚，糟糕的程序殺死了這個項目。在沒有舉出其它可能的論證、在現有缺少證據的情況下，我承認這兩種認定。人被一顆子彈殺死，項目被糟糕的程序害死。

　　是的，從技術上講，項目的失敗歸咎于程序。

　　扣動扳機的人

　　我們的悲劇并沒有結束。我們不能夠用消滅子彈來阻止謀殺，我們更不能用禁止對程序代碼的依賴來挽救項目。雖然子彈和程序是原因，但它們都只是表象。

　　是有人扣動了扳機。

　　在大型項目中，要想找到一個受譴責的對象，你不能不提及那些自以為是的人。在大型項目中，通常都是眾多的人為因素要對失敗負責。如果我們要對大多數失敗的項目進行考古發掘，我可以自信的說，我們會發現失敗的原因都在人身上。我可以自信的說，我們會發現這些都是交流不暢的失敗。這不是一種失敗，是成百上千種的，大的或小的失敗。缺乏遠見，缺乏透明度。

　　由于缺乏遠見和透明度而導致的缺乏凝聚力。缺乏清楚的預期。責任不清。當不同意時緘口不言。以非建設性的方式發表反對。討論起來像打仗。用煽動性的語言制造分裂。避而不談失誤。用發郵件來替代打電話。用打電話來代替面對面交流。過度強調交貨日期。對時間和速度的認識截然相反。不重視周邊工作。沒熱情 … 這個清單還有很多。

　　對于軟件項目，程序是關鍵。你不可能制作一個沒有代碼的軟件項目。程序代碼越糟，項目的風險越大。當糟到一定程度，項目就會失敗。更嚴重的是，公司也可能會因為這個項目而倒閉。

　　但我不會忘記，是我們寫了這些程序。

　　是我們扣動了扳機。

　　[英文出處]：Code as a Cause of Project Failure