最初的问题
上周，在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