“这个网站相当简单，你需要做的就是做X、Y、Z。你看起来技术应该不错，所以，我相信我，你不需要花太多时间来建造它。”我不时收到这样的电子邮件。写这些电子邮件的人几乎总是非技术人员或正在开发他们的第一个产品。起初，当我听到人们这么说时，我总是很恼火。他们在和谁争论软件开发所需的时间？但后来我意识到，即使我预测了我的项目需要多少开发时间，我也无能为力。如果我自己都做不到，我为什么要生那些人的气呢？真正让我沮丧的不是他们的失算。问题是他们认为他们可以做出正确的估计。作为开发人员，我们经常会发现，在软件开发方面，外行人自然会把复杂的事情想的简单一些。这不是为了原谅我们的愤怒。但这提出了另一个有趣的问题：为什么我们天生的预测复杂性的能力在涉及编程问题时会失败？要回答这个问题，让我们来看看我们的大脑是如何估计事物的。对于一些没有经验的人来说，有些事情很容易预测正确，但有些事情则不然。让我们想想看一个人弹吉他。即使你从来没有弹过吉他，但在观看了《玛丽有只小羊羔(Mary had a Little Lamb)》的吉他表演后，你可能会猜测它很简单，不需要太多技巧就可以弹奏。同样，当您观看某人在D大调中演奏《卡农(Pachabel’s Canon)》时，很容易推测它很复杂并且需要大量练习才能正确。为什么我们可以快速准确地估计出这两块的复杂度呢？这与我们判断一个事物是简单还是复杂的方法有关。我们的大脑有一些现成的模式来完成这些事情，第一个是基于速度。在这种情况下，大脑会辨别每一秒正在播放的内容。根据每秒钟演奏多少东西，我们很容易对这首曲子的复杂程度有一个直观的判断。因为用吉他弹奏歌曲是一个物理过程，是一种感官活动，我们的大脑很容易据此推断出速度，然后将其转化为复杂度。我们还有另一个自然的投机基础：成交量。想想将帐篷比作公寓楼。即使是从未学过建筑的人也能告诉您，设计和建造帐篷通常比设计和建造公寓更容易。为什么？因为我们自然而然地把物理体积作为衡量事物复杂程度的指标。当然。上面提到的两种逻辑分析并不总是100%有效。但在大多数情况下，这就是人们所做的，并且取得了巨大的成功。在大多数情况下，当我们评估物理过程时，我们的大脑会有效地将物理事物联系起来，而无需依赖以前的经验。现在让我们谈谈软件。当非技术人员试图估算软件开发时间时，他们会得到两个基本直观指标的帮助：规模方面的复杂性和速度方面的复杂性。他们没有意识到的是，该软件并非他们所想的那样。软件本身并不是有形的。没有体积和速度。它的微小组件可能会不时地在计算机屏幕上闪烁。因此，在开发Web应用程序（或任何类型的软件）时，我们的基本直觉会失败。这一点，速度，显然是外行无法评价软件的。所以很自然地，他们倾向于使用量指标来进行评估。通过描述文档的页数，或者通过软件的功能用例或特性的数量。有时候，这种考核方式真的很管用！当面对一个没有特殊设计要求的静态网站时，外行人很容易使用这种方法估算开发时间。然而，一般来说，对于软件开发而言，规模并不是复杂性的真实有效反映。不幸的是，当谈到软件复杂性时，最好的猜测方法是凭经验。而且它并非一直有效。作为一名程序员，我知道基于我之前开发过的类似功能，我可以预估这些功能中的每一个需要花费多少开发时间。然后，我将总时间相加，得出完成整个项目所需的大概时间。然而，在现实中，每个项目在开发过程中都会遇到两三个瓶颈。这些瓶颈会无差别地消耗程序员大量的时间，在遇到它们之前你是绝对不会预见到的。他们可以拖延整个项目，将进度推迟数周甚至数月。这些是没有经验的人在评估复杂性时不会理解的事情。他们不明白为什么在其他事情上行之有效的方法在软件开发中却行不通。所以下次你听到有人说“我觉得你可以在几天内开发这个”，不管是谁说的，都不要难过。深吸一口气，告诉他这篇文章的地址，以及要做什么。
