The Cost of Code?

代码成本

昨天在#SCNA(北美2010软件技术大会)的一个专题小组讨论会上，@chadfowler 提出了这个问题：“有多少项目是因为程序的原因而失败？”我想，他的潜台词是，造成项目失败的主要原因是业务问题，而非技术问题。

今天早上我把这个问题发布在了微博上。很快就有了回复，几乎所有人都认为导致项目失败的原因中，业务问题是罪魁祸首。

完全没错，项目会因为成本，需求，进度计划，管理等问题而失败。可同样没错的是，从来没有人在追查失败的原因时会深入到像程序代码这样底层的东西上。所以，Chad的观点—— 如果真像他想的那样——是有一定的参考价值的。
    我们可以从中得到结论：从长远的角度看，程序代码并不是那么重要，程序员的劳动也许只是些大量的些微小事。事实上，Chad在#scna上的演讲中希望我们去认真思考这个问题。如果我们按照他的观点去做，我们就应该降低对技术能力的重视，增加对业务，需求，预算，计划和管理工作的重视。

在我反驳这个观点之前，我要说，我碰巧知道好几个因为程序的原因而失败的项目。事实上，我还知道几个因为程序的原因而失败的公司。

相信和理解这种事情并不是难于上青天。我们都知道，当程序代码混乱时，它会变得越来越难以维护和改进。当这种成本超过了一个项目可以承受的能力后， 项目就失败了。当这种成本超过了一个公司所能承受的能力后，公司就倒闭了。在我知道的这些案例中，这些事情就是这样真实的发生着。很简单，就是代码的开销超过了它的商业模式的承受能力。

让我们在脑子里做这样一个推演。如果程序代码的生产和维护成本无限的昂贵，项目的哪部分会失败？很显然，由于程序代码过于昂贵，超过任何有限的商业模式的承受能力，所有项目都会失败。

那好，如果程序的生产和维护不会产生任何的代价，那会怎样？项目的什么部分会因为这种程序而失败？同样，答案很明显。如果这种程序代码不会产生任何成本，没有项目会因此而失败。

什么叫做没有成本代价？就是说当你需要它时你唾手可得。程序已经在那里了，即时的，功能齐全的，没有缺陷的。任何时候你想修改它，修改工作能立即完成，自动部署，马上生效。

就好象是你被强盗丢进了一个山洞里，在这个山洞里你发现了一个老式的PC机，带着一个很老式的键盘。你拿起键盘，擦了擦脏兮兮的Enter键。哦，一个精灵出现在了屏幕上，它给予了你能够生产零成本的程序代码的能力！从这时起，还会有什么项目会失败？

你要明白，没有第二个人拥有你这样的能力。没有第二个人能即时的生产出没有缺陷的想要的任意程序代码。没有第二个人能够不费时间的修改和部署变更的程序。你拥有绝对的竞争优势。你还有失败的可能吗？我想我的小狗Petunia也许会弄失败，但任何比它聪明的生物都会因此而成为亿亿万富翁。

 

如果我们有了这台神奇的PC机，我们就不会再有进度计划和预算问题。管理失误和需求不确定的成本会趋近于零。所有会导致项目失败的因素都会变的无关紧要。

可是我们没有这样神奇的PC机。程序代码的生产和维护会消耗资金。但如果我能拥有这个神奇精灵的一点点能力，我就能降低代码生产和维护的成本，同时我还能降低由于管理失误、需求不确定、工期紧张或者预算紧张所带来的成本和风险。通过降低事情的这些成本，我们降低了犯错的成本，增加了成功的几率！

为什么项目会因为需求不确定、管理混乱、计划不正确、预算有问题而失败？是因为犯错的成本太高。为什么犯错的成本很高？因为程序代码的成本高的可怕。如果程序代码不会带来成本，犯错的成本代价也就会趋近为零。

这种认识在各公司中还是有共识的。他们试图通过压缩程序员来解决这个程序成本问题。他们冒着巨大的风险花大价钱从地球的另一边雇佣具有各种不同文化 的编程人员。他们面对着时区和语言的问题，文化的不匹配问题。而选择这一切都是为了降低程序的成本。他们这样做，是因为他们知道这种成本压迫着管理的成本。他们这样做，是因为这种成本会导致项目失败。

不幸的是，这种策略并不像我们希望的那样奏效。可能有些这样事情做的不错，但大部分外包的效果令人失望。于是程序的成本仍然居高不下，同样，失败的风险也高居不下。

再回到我们最初的问题上。有多少项目因为程序代码的原因而失败？根据上面的讨论，所有的失败都是由于程序的成本导致的。有多少项目因为程序代码的原因而失败？全部。

更重要的是，唯一有效的能增加项目成功概率的方法是什么？是改进需求？管理工作？进度计划和预算？这些方法都有帮助，但对于导致项目失败的原因，他们都是次要的，都比不上程序的成本。

 

 

The Cost of Code?
uncle bob

In a panel at #scna yesterday, @chadfowler asked the question: "How many projects fail because of the code?" I think the point he was trying to make was that the primary causes of project failure are business issues, not technical issues.

I posed this question on twitter earlier today. The responses came quickly, and virtually all of them agreed that business issues are the more significant causes of project failure.

It's certainly true that projects fail because of cost, requirements, schedule, management. etc. It's also true that we seldom trace the cause of failure back to something as mundane as code. So Chad's point, if that's what it was, certainly has merit.

The conclusion that we might make from this is that code just isn't very important in the long run, and the the craftsmanship movement might just be a load of Yak Shaving. Indeed, Chad asked us to consider just that in his talk at #scna. If we follow that reasoning, then we should decrease our emphasis on technological prowess and skill, and increase our emphasis on business, requirements, budgets, schedules, and management.

Before I counter this argument, let me say that I do know of projects that have failed because of the code. Indeed, I know of companies that have failed because of the code.

This isn't actually very difficult to believe or understand. We all know that when the code is a mess, it becomes more and more costly to maintain and improve. If that cost exceeds what the project can afford, the project fails. If that cost exceeds what the company can afford, the company fails. In the cases that I am aware of, this is precisely what happened. The code was simply too costly for the business model to support.

So let's try a simple thought experiment. What fraction of projects would fail if the code was infinitely expensive to produce and maintain? Clearly all projects would fail because the code would be too expensive for any finite business model to support.

OK, so what if the code cost nothing to produce and maintain? What fraction of those projects would fail because of the code? Again, the answer is clear. No project would fail because of the code, if the code costs nothing to make.

What does it mean to cost nothing to make? It means that you would have the code you needed the instant you needed it. The code would simply be there, instantly, fully functional, free of defects. Any time you needed a change, the change would instantly be in effect, fully deployed, fully operational.

So let's say you are thrown into a cave by some thieves. In that cave you find a old beat-up PC jr, complete with the IR chicklet keyboard. You pick up that keyboard and rub a smudge off the enter key. Wooosh! a genie appears on the screen and grants you the ability to have zero cost code for the rest of your life! Would any of your projects ever fail from that point on?

Remember, nobody else has your ability. Nobody else can produce the code they want, instantly, and without defect. Nobody else can make and deploy changes in zero time. So you have a tremendous competitive advantage. Is there any way you could fail? I think my dog Petunia might fail, but anyone smarter than that should become a multi-trillionaire.


If we had that magic PC jr, there wouldn't be any schedule or budget issues. The cost of mismanagement and/or bad requirements would be close to zero. So all those things that cause projects to fail would become irrelevant.

But we don't have that magic PC jr. Code does cost money to produce and maintain. But if I, as a craftsman, can invoke a fraction of the power of that Genie to reduce the cost of producing and maintaining code, then I simultaneously reduce the cost and risk of mismanagement, of bad requirements, of tight schedules, and of tight budgets. By reducing the cost of the thing that's being managed, we reduce the cost of error and increase the chances of success!

Why is it that projects fail due to bad requirements, bad management, bad schedules, and bad budgets? They fail because the cost of error is huge. Why is the cost of error huge? Because the cost of the code is so horribly large. If code cost nothing to produce, the cost of error would be close to zero.

This realization has not been lost on the business community. They tried to solve it by reducing the hourly rate of programmers. They set up horrifically expensive and risky mechanisms in order to hire programmers who lived half a world away in a wildly different culture. They faced the issues of time zones and languages, and cultural mismatch in order to reduce the cost of code. They did this because they understood that the it is that cost that drives the cost of management error. They did this because it is that cost that makes projects fail.

Unfortunately this strategy didn't work as well had been hoped. Some folks have made it work; more or less. But the majority of the off-shoring efforts have been disappointing. And so the cost of code remains high, and therefore the risk of error is also high.

And that brings us back to the question at hand. How many projects fail because of the code? The argument above suggests that all failures are a direct result of the cost of code. How many projects fail because of code? All of them!

More importantly, what is the single most effective way to increase the chances of project success? Is it improving requirements? Management? Schedules and budgets? All those things would help, but they are all secondary to the thing that truly drives project failure: The cost of the code.