昨天在#SCNA(北美2010软件技术大会)的一个专题小组讨论会上，@chadfowler 提出了这个问题：”有多少项目是因为程序的原因而失败的?“我想，他是想说造成项目失败的主要原因是业务问题，而非技术问题。
今天早上我把这个问题发布在了微博上。很快就有了回复，几乎所有人都认为导致项目失败的原因中业务问题是罪魁祸首。
完全没错，项目会因为成本，需求，进度计划，管理等问题而失败。可同样没错的是，从来没有人在追查失败的原因时会深入到像程序代码这样底层的东西上。所以，Chad的观点 — 如果真像他想的那样 — 是有一定的参考价值的。
我们可以从中得到结论：从长远的角度看，程序代码并不是那么重要，技术人员的劳动也许只是些大量的些微小事。事实上，Chad在#scna上的演讲中希望我们去认真思考这个问题。如果我们按照他的观点去做，我们就应该降低对技术能力的重视，增加对业务，需求，预算，计划和管理工作的重视。
在我反驳这个观点之前，我要说，我碰巧知道好几个因为程序的原因而失败的项目。事实上，我还知道几个因为程序的原因而失败的公司。
相信和理解这种事情并不是非常的困难。我们都知道，当程序代码混乱时，它会变得越来越难以维护和改进。当这种成本超过了一个项目可以承受的能力后，项目就失败了。当这种成本超过了一个公司所能承受的能力后，公司就倒闭了。在我知道的这些案例中，这些事情就是这样真实的发生着。很简单，就是代码的开销超过了它的商业模式的承受能力。
让我们在脑子里做这样一个推演。如果程序代码的生产和维护成本无限的昂贵，项目的哪部分会失败?很显然，由于程序代码过于昂贵，超过任何有限的商业模式的承受能力，所有项目都会失败。
那好，如何程序的生产和维护不会产生任何的代价，那会怎样?项目的什么部分会因为这种程序而失败?同样，答案很明显。如果这种程序代码不会产生任何成本，没有项目会因为此而失败。
什么叫做没有成本代价?这是说当你需要它时你能立即得到。程序已经在那里了，即时的，功能齐全的，没有缺陷。任何时候你想修改它，修改工作能立即完成，自动部署，马上生效。
就好象是你被强盗丢进了一个山洞里，在这个山洞里你发现了一个老实的PC机，带着一个很老式的键盘。你拿起键盘，擦了擦脏兮兮的Enter键。哦，一个精灵出现在了屏幕上，它给予了你能够生产零成本的程序代码的能力!从这时起，还会有什么项目会失败?
你要明白，没有第二个人拥有你这样的能力。没有第二个人能即时的生产出没有缺陷的想要的任意程序代码。没有第二个人能够不费时间的修改和部署变更的程序。你拥有绝对的竞争优势。你还有失败的可能吗?我想我的小狗Petunia也许会弄失败，但任何比它聪明的生物都会因此而成为亿亿万富翁。
如果我们有了这台神奇的PC机，我们就不会再有进度计划和预算问题。管理失误和需求不确定的成本会趋近于零。所有会导致项目失败的因素都会变的无关紧要。
可是我们没有这样神奇的PC机。程序代码的生产和维护会消耗资金。但如果我能拥有这个神奇精灵的一点点能力，我可以去降低代码生产和维护的成本，同时我还能降低由于管理失误、需求不确定、工期紧张、预算紧张所带来的成本和风险。通过降低事情的这些成本，我们降低了犯错的成本，增加了成功的几率!
为什么项目会因为需求不确定、管理混乱、计划不正确、预算有问题而失败?是因为犯错的成本太高。为什么犯错的成本很高?因为程序代码的成本高的可怕。如果程序代码不会带来成本，犯错的成本代价也就会趋近为零。
这种认识在各公司中还是有共识的。他们试图通过压缩程序员来解决这个程序成本问题。他们冒着巨大的风险花大价钱从地球的另一边雇佣具有各种不同文化的编程人员。他们面对着时区和语言的问题，文化的不匹配问题。而选择这一切都是为了降低程序的成本。他们这样做，是因为他们知道这种成本压迫着管理的成本。他们这样做，是因为这种成本会导致项目失败。
不幸的是，这种策略并不像我们希望的那样奏效。可能有些这样事情做的不错，但大部分外包的效果令人失望。于是程序的成本仍然居高不下，同样，失败的风险也高居不下。
再回到我们最初的问题上。有多少项目因为程序代码的原因而失败?根据上面的讨论，所有的失败都是由于程序的成本导致的。有多少项目因为程序代码的原因而失败?全部。
更重要的是，唯一有效的能增加项目成功的机会的方法是什么?是改进需求?管理工作?进度计划和预算?这些方法都有帮助，但对于导致项目失败的原因，他们都是次要的，都比不上：程序的成本。（欣才PHP培训机构）
