时常收到这样的电子邮件：“这个网站非常简单，只需完成X、Y、Z任务。你看起来技术娴熟，因此我相信你不需要花费太多时间就能搭建起来。”发件人通常是些对技术不甚了解的人，或是正在研发其首个产品的创业者。
起初，听到这样的言论，我总是感到有些恼火。谁在妄议软件开发所需的时间呢？但随后我意识到，即便我能对自己的项目预测所需开发时间，也无法保证预测的精准。如果连我都无法保证，我又何必对那些发邮件的人感到愤怒呢？
真正令我困扰的并非他们对项目时间的误判，而是他们似乎相信自己能够做出准确的评估。作为开发者，我们经常会发现，在软件开发的议题上，外行人往往会本能地将复杂的事情简单化处理。
这并不是为了给我们的愤怒寻找借口。但它引发了一个有趣的问题：为什么我们在面对编程问题时，天生的预测复杂性的能力会失效？
为了解答这个问题，我们需要了解我们的大脑是如何评估事物的。有些事物对于没有经验的人来说也很容易准确预估，但有些则不然。
以观看吉他演奏为例。即使你从未弹奏过吉他，观看一场弹奏《玛丽有只小羊羔》的吉他表演后，你也能大致判断这不需要太高的技巧。同样地，观看有人演奏D大调的《卡农》后，你同样能轻易推断出这首曲子复杂，需要长时间的练习。
为什么我们能迅速准确地预估这两首曲子的复杂性呢？这和我们判断事物简单或复杂的方法有关。我们的大脑有一些既定的模式来完成这件事。其中之一就是根据速度判断。大脑会辨别每秒演奏的内容。根据每秒钟演奏的内容数量，我们能直观地判断曲子的复杂度。因为弹奏吉他是物理过程，是感官活动，所以我们的大脑能够根据速度轻易做出判断。
我们还有另一个天生的判断依据：体积。想象一下将帐篷和公寓放在一起对比。即使一个人从未学习过建筑学，他也能大致判断设计和建造帐篷比设计和建造公寓更简单。为什么？因为我们本能地使用物理体积作为评估事物复杂性的指标之一。
上述两种逻辑分析并不总是百分之百准确。但在大多数情况下，人们就是这样做的，并且相当成功。在评估物理过程时，我们的大脑经常能做出有效的关联，无需依赖过去的经验。
现在让我们谈谈软件。当不懂技术的人试图评估软件开发时间时，他们可能会依赖两个直观指标：以速度为指标的复杂度和以体积为指标的复杂度。但他们没有意识到软件与他们想象的不同。软件本质上是无形的，没有体积和速度的概念，其微小的组成部分可能只是偶尔在电脑屏幕上闪现。在面对开发web应用时（或任何类型的软件），我们的基本直觉往往会失效。
对于外行人来说，他们无法用速度来评估软件，于是便倾向于使用体积作为评估指标。这也许是基于描述文档的页数、软件的功能用例数或特征数等等。
有时这种评估方法确实有效，例如在面对没有特殊设计要求的静态网站时。但通常情况下，对于软件开发而言，体积并不能真实反映其复杂度。
不幸的是，评估软件复杂度的唯一有效方法依赖于经验，而且并不总是准确。作为程序员，我能根据之前开发过的相似功能特征来估计每个功能特征的开发时间。然而在实际操作中，每个项目都会遇到一些瓶颈问题，这些问题会消耗程序员大量时间并且无法预见。它们可能会使整个项目延误数周甚至数月。
这些瓶颈问题是缺乏经验的人在评估软件复杂度时无法理解的。他们不明白他们所用的方法在其他事情上有效，为何在软件开发上却失灵了。当下一次有人告诉你“我想你几天就能把它开发出来”时，无论对方是谁，都不要感到沮丧。深呼吸一下，分享这篇文章给他们看，然后继续你的工作。
（本文转载自 |
