即使拥有现今计算机所能达到的令人眼花瞭乱的高速度，计算技术还是无法让商业生产率呈指数上升，因为软件无法支撑它的底线。
评论——我们都很熟悉摩尔定律。它是技术时代的伟大诺言所赖以存在的一条原则。
然而，即使今天的计算机拥有令人眼花缭乱的高速度，计算技术还无法如摩尔定律所许诺的那样，让商业生产力、收益率和创新呈指数上升，为什么会这样？
这是因为软件无法支撑起它的底线。
软件没有让商业生产率呈指数增加，也没有让我们发挥速度更快和功能更强的硬件的全部潜力，而是在不断变得更加复杂、臃肿、笨重和迟钝。
大多数IT计划都会失败，这已不再是秘密。软件难以编写、难以理解、难以配置、难以运用、难以管理、难以维护，也日益难以证明它的正确性。我们花费了数十亿美元来构建、实现、修复软件，甚至与我们的软件为敌，然而我们要求的回报很少，温顺地接受我们的投资得不到质量或者性能的保证这一事实。
但我们必须面对这一点：我们需要软件。我们因它而强大，不论它们有什么缺点，软件就是软件。它的问题就是我们的问题，作为今天软件的创新者、开发者和使用者，我们应该对它现在所处的尴尬境地负有责任，并勇敢承担起改变软件（编写）方法的重任，从而带动它们的复兴。
不幸的是，大多数公司和解决方案提供商仅仅把注意力放在开发过程的某一个领域里，结果限制了它们解决软件危机的努力。许多人接受挑战，编写更好的（更快的）代码，而另外一些人则在探寻应用程序管理的解决方案，从而让我们满是漏洞的软件可以“自我治愈”。剩下的则投入到了那些提供含糊不清的“让IT像商业那运转”的许诺的管理技术上。
其实，软件并没有发挥它的潜能。
IT项目会失败，是因为我们经常不计后果地遗弃软件开发过程的方法。我们把那些经过检验的工程学原理以及其他准则所依附的过程扔出了窗外。我们的计划松懈，没有什么标准和设计原则。
如果我们的确为自己的应用软件设计了蓝图，那么去构建它的团队却很少遵守它。当创建（代码）的时候，我们偏离了为自己设定的规范。我们把代码编写者同构建师隔离开来，我们把质检人员和维护团队同代码编写者隔离开来，我们把整个团队同最终产品拥有者（软件的使用者）对最终产品的期望和需要的理解隔离开来。
