导读：外刊IT评论翻译了一篇《关于程序成本的讨论》以下是文章全部内容：
昨天在#SCNA（北美2010软件技术大会）的一个专题小组讨论会上，@chadfowler 提出了这个问题：”有多少项目是因为程序的原因而失败的？“我想，他是想说造成项目失败的主要原因是业务问题，而非技术问题。
今天早上我把这个问题发布在了微博上。很快就有了回复，几乎所有人都认为导致项目失败的原因中业务问题是罪魁祸首。
完全没错，项目会因为成本，需求，进度计划，管理等问题而失败。可同样没错的是，从来没有人在追查失败的原因时会深入到像程序代码这样底层的东西上。所以，Chad的观点 — 如果真像他想的那样 — 是有一定的参考价值的。
我们可以从中得到结论：从长远的角度看，程序代码并不是那么重要，技术人员的劳动也许只是些大量的些微小事。事实上，Chad在#scna上的演讲中希望我们去认真思考这个问题。如果我们按照他的观点去做，我们就应该降低对技术能力的重视，增加对业务，需求，预算，计划和管理工作的重视。
在我反驳这个观点之前，我要说，我碰巧知道好几个因为程序的原因而失败的项目。事实上，我还知道几个因为程序的原因而失败的公司。
相信和理解这种事情并不是非常的困难。我们都知道，当程序代码混乱时，它会变得越来越难以维护和改进。当这种成本超过了一个项目可以承受的能力后，项目就失败了。当这种成本超过了一个公司所能承受的能力后，公司就倒闭了。在我知道的这些案例中，这些事情就是这样真实的发生着。很简单，就是代码的开销超过了它的商业模式的承受能力。
让我们在脑子里做这样一个推演。如果程序代码的生产和维护成本无限的昂贵，项目的哪部分会失败？很显然，由于程序代码过于昂贵，超过任何有限的商业模式的承受能力，所有项目都会失败。
那好，如何程序的生产和维护不会产生任何的代价，那会怎样？项目的什么部分会因为这种程序而失败？同样，答案很明显。如果这种程序代码不会产生任何成本，没有项目会因为此而失败。
什么叫做没有成本代价？这是说当你需要它时你能立即得到。程序已经在那里了，即时的，功能齐全的，没有缺陷。任何时候你想修改它，修改工作能立即完成，自动部署，马上生效。
就好象是你被强盗丢进了一个山洞里，在这个山洞里你发现了一个老实的PC机，带着一个很老式的键盘。你拿起键盘，擦了擦脏兮兮的Enter键。哦，一个精灵出现在了屏幕上，它给予了你能够生产零成本的程序代码的能力！从这时起，还会有什么项目会失败？
你要明白，没有第二个人拥有你这样的能力。没有第二个人能即时的生产出没有缺陷的想要的任意程序代码。没有第二个人能够不费时间的修改和部署变更的程序。你拥有绝对的竞争优势。你还有失败的可能吗？我想我的小狗Petunia也许会弄失败，但任何比它聪明的生物都会因此而成为亿亿万富翁。
如果我们有了这台神奇的PC机，我们就不会再有进度计划和预算问题。管理失误和需求不确定的成本会趋近于零。所有会导致项目失败的因素都会变的无关紧要。
可是我们没有这样神奇的PC机。程序代码的生产和维护会消耗资金。但如果我能拥有这个神奇精灵的一点点能力，我可以去降低代码生产和维护的成本，同时我还能降低由于管理失误、需求不确定、工期紧张、预算紧张所带来的成本和风险。通过降低事情的这些成本，我们降低了犯错的成本，增加了成功的几率！
为什么项目会因为需求不确定、管理混乱、计划不正确、预算有问题而失败？是因为犯错的成本太高。为什么犯错的成本很高？因为程序代码的成本高的可怕。如果程序代码不会带来成本，犯错的成本代价也就会趋近为零。
这种认识在各公司中还是有共识的。他们试图通过压缩程序员来解决这个程序成本问题。他们冒着巨大的风险花大价钱从地球的另一边雇佣具有各种不同文化的编程人员。他们面对着时区和语言的问题，文化的不匹配问题。而选择这一切都是为了降低程序的成本。他们这样做，是因为他们知道这种成本压迫着管理的成本。他们这样做，是因为这种成本会导致项目失败。
不幸的是，这种策略并不像我们希望的那样奏效。可能有些这样事情做的不错，但大部分外包的效果令人失望。于是程序的成本仍然居高不下，同样，失败的风险也高居不下。
再回到我们最初的问题上。有多少项目因为程序代码的原因而失败？根据上面的讨论，所有的失败都是由于程序的成本导致的。有多少项目因为程序代码的原因而失败？全部。
更重要的是，唯一有效的能增加项目成功的机会的方法是什么？是改进需求？管理工作？进度计划和预算？这些方法都有帮助，但对于导致项目失败的原因，他们都是次要的，都比不上：程序的成本。
后续调查
Uncle Bob (@unclebobmartin)后来做了一次简单的微博调查，我和其他很多人都参与了。调查的结果是，赞成项目失败的责任主要归咎于业务问题、而非技 术问题的占了绝大多数。Bob感到这么多人选择这样的观点表明了从长远角度看，程序不是那么的重要，因此，技术人员也一样显的不那么重要。Bob认真了提出了一些很好的论据来说明为什么程序很重要，来说明事实上，程序不仅能使项目失败，而且会使整个公司倒闭。我在这里不做更多的复述，我强烈推荐你们去读一下Bob的这篇文章，“The Cost of Code?” ，Bob在这篇文章里的大部分观点我都赞同。程序的成本很大。但我不认为所有的项目的失败都归咎于程序， 但他用来说明这个观点的例子都很有价值。
原因和责任 证据确凿
一个人死了，一颗子弹击中了他的胸膛。一个项目失败了，只剩下一堆没有的程序码。对于我们来说也许事实很清楚，一颗子弹杀死了这个人。对于 我们来说也许事实很清楚，糟糕的程序杀死了这个项目。在没有举出其它可能的论证、在现有缺少证据的情况下，我承认这两种认定。人被一颗子弹杀死，项目被糟 糕的程序害死。
是的，从技术上讲，项目的失败归咎于程序。
扣动扳机的人
我们的悲剧并没有结束。我们不能够用消灭子弹来阻止谋杀，我们更不能用禁止对程序代码的依赖来挽救项目。虽然子弹和程序是原因，但它们都只是表象。
在大型项目中，要想找到一个受谴责的对象，你不能不提及那些自以为是的人。在大型项目中，通常都是众多的人为因素要对失败负责。如果我们要对大多数失败的项目进行考古发掘，我可以自信的说，我们会发现失败的原因都在人身上。我可以自信的说，我们会发现这些都是交流不畅的失败。这不是一种失败，是成百上千种的，大的或小的失败。缺乏远见，缺乏透明度。由于缺乏远见和透明度而导致的缺乏凝聚力。缺乏清楚的预期。责任不清。当不同意时缄口不言。 以非建设性的方式发表反对。讨论起来像打仗。用煽动性的语言制造分裂。避而不谈失误。用发邮件来替代打电话。用打电话来代替面对面交流。过度强调交货日 期。对时间和速度的认识截然相反。不重视周边工作。没热情——这个清单还有很多。
对于软件项目，程序是关键。你不可能制作一个没有代码的软件项目。程序代码越糟，项目的风险越大。当糟到一定程度，项目就会失败。更严重的是，公司也可能会因为这个项目而倒闭。
但我不会忘记，是我们写了这些程序。
是我们扣动了扳机。
原文链接：http://thecleancoder.blogspot.com/2010/10/cost-of-code.html
