所有项目的失败真的都该归咎于程序吗？
今天，我读到了两篇有趣的文章：@unclebobmartin写的The Cost of Code 和 @DocOnDev 写的 Code as a Cause of Project Failure (读者可以分别在这里和这里阅读它们的中文版。)。
他们在用各种的论据来证明所有项目的失败都是由于程序的原因。他们主要的论点是：如果程序没有成本，轻巧易改变，项目就不可能失败。是的。但这些是极端情况，很显然在现实中是不可能的。我们并没有生活在一个能够时空穿梭的自由世界里(很遗憾)。现实生活里，程序是有成本的，而且很大，而且相信下个世纪也将会是这样，所以这种论证证明不了什么。理想世界里不需要程序。理想世界里即使没有计算机和其他复杂的东西，你也可以瞬间找到解决方案。所以我不认可他们的论据。在现实里，程序不是项目失败的主要原因。
程序是有成本的。程序是昂贵的。但我们并不是卖源代码，我们卖的是解决方案。如果不需要程序代码就能产生解决方案，那是再好不过了。我们以一个处理现实目标的行业为例。汽车行业并不是出售碳物质和铁块的 – 那是汽车。他们出售的是一种解决交通问题的方案。时空穿梭机是一个理想的方案，但很遗憾，这种方式除了能传输电子外，什么都传输不了。我们买汽车是为了能从A处到B处。我们买的是一种解决方案。
程序 != 解决方案
我认为失败的项目的主要问题是他们要么提供了糟糕的解决方案，要么根本就不是个方案。没有人现在还提供驿站马车，那已经不是一种有效的解决方案。如果一个项目不能解决任何问题，它就会失败。如果一个项目能解决某些问题，但做的很烂，不可用，那也是失败。你可以用最简洁的代码创造出世界上绝对最优美的架构。你可以做到100%的测试覆盖率，功能相互完全不依赖，继承关系平滑，方法没有二义。所有的优点你都具备，但如果你的程序不能有效的解决用户的问题，项目仍然会不幸的失败。
你也许会争辩说，整洁的代码可以让你快速的进行重构，一切都可以改变。但通常，如果程序解决了错误的问题，你需要完全重写它。你不可能在驿站马车上改造来使它跟汽车竞争。
另一方面，如果项目解决了正确的问题，但有缺陷，这时整洁的代码非常的重要。没有整洁的代码你不可能做迅速的调整。但你不可能按人们的需求改变更多的东西。
别误会我，我相信整洁的代码是很重要的事情，但在软件开发的活动中它不是最重要的资源。