I’m Sure It Will Only Take You A Few Days To Code

I’m Sure It WillOnly Take You A Few Days To Code

 

 

“So the site’s pretty simple, all itneeds to do is X, Y and Z. You seem like a good programmer so I’m sure it willonly take you a few days to put it together.”

I get emails like this from time totime. The people that write them are almost invariably not technical andworking on their first product. At first I got pretty annoyed when peopletalked like this. Who are they to go around estimating development times? Butthen I realized, even I am terrible at estimating how long my own projects are going to take. How can Iget mad at them if I can’t do it either?

The real reason I’m annoyed is not thattheir estimate is wrong. It’s that they assume that they can even make anestimate. That’s because as developers we unconsciously realize that the way alayperson naturally estimates complexity breaks down when it comes to software.

That’s not an excuse for being annoyed.But it brings up another more interesting question: why doesthe way we naturally measure complexity stop working when we apply it toprogramming? 

To answer this question let’s thinkabout how our brains estimate things. There are some things that are easy forsomeone with no experience to estimate and some things that aren’t.

Think about watching someone playguitar. Even if you’ve never played guitar you can probably infer from watchinga performance of Mary Had a Little Lamb that it’s simple and that the personplaying it does not need a great deal of skill to do so. It’s also pretty easyto watch someone play Pachabel’s Canon in D and infer that it is complex andwould take a long time to learn how to play.

Why are we good at instantly estimatingthe complexity of these two songs? It’s because of the way we judge whethersomething is difficult or easy. Our brains have a few built in tools to do thatand the first one is speed. In this case, it’s notes played per second. Notesplayed per second gives us a really easy, natural heuristic to estimate songdifficulty. And because playing a song on the guitar is a physical, sensoryactivity it’s simple for our brains to measure speed and convert it intocomplexity.

We also have another natural heuristic:size. Think about a tent versus a mansion. Even someone who has never been toarchitecture school can tell you that in general it’s a lot easier to designand construct a tent than it is to design and construct a mansion. Why? Becausewe naturally use physical size as an analog for complexity.

Obviously neither of these are reliable100% all of the time, but in most cases in life it gets the job done. That’sbecause in most cases we’re estimating something physical that our brains canrelate to efficiently and without prior experience.

Now let’s talk aboutsoftware. When a non-technical person attempts to estimate softwaredevelopment time they come armed with their two basic heuristics: complexity basedon size and complexity based on speed. But what they don’t realize is thatsoftware is different. Software is by nature not physical. It exists inthe ether. A tiny portion of it shows up on our computer screens from time totime. Because of this when it comes to building web apps (or any type ofsoftware for that matter) our basic heuristics break down.

The first one, speed, is essentiallyimpossible to estimate for the layperson offhand. So the natural heuristic theytend to use is size. Some go with number of pages, some go with number ofactions or number of features.

Sometimes this actually works! Ifyou’re talking about a static site with a bland design it can be very easy toestimate development time for the layperson. But in general size does nottranslate reliably into complexity when it comes to software.

Unfortunately, the only heuristic thatworks when it comes to software complexity is experience. And even that doesn’t work all thetime. As a programmer I know I can use my prior experience building similarthings to estimate how long each feature will take to implement. Then I add allthat up and come up with a rough estimate of when I’ll be done with theproject. But the fact of the matter is that in every project there are two orthree bottlenecks that crop up during development. These bottlenecks suck up aninordinate amount of programmer time that can’t be reliably predictedbeforehand. And so it throws your entire project off schedule by weeks ormonths.

That’s what someone without experiencemisses when they try to estimate complexity. They don’t realize that what worksin almost any other situation, doesn’t work at all when it comes to software.And so next time you hear “I’m sure this will only take you a few days to code”try not to be annoyed with whoever said it. Just take a deep breath, link themto this post and go on with your day.

If you liked this post you shouldprobably follow me on Twitter.Or check out my startup Airtime for Email.We help you market your products with your email signature.

 

参考译文：

“这个网站相当简单，所有你需要做的就是完成X，Y，Z。你看起来应该是技术很好，所以，我相信，你不需要花费太多时间就能把它搭建起来。”

 

我时不时的就会收到这样的Email。写这些邮件的人几乎都是跟技术不沾边的人，或正在研究他们的第一个产品。起初，当听到人们这样的话，我总是十分的恼怒。他们在跟谁辩论软件开发所需要的时间？但后来我意识到，即使我自己对自己的项目预测要花去多少开发时间,我也是一筹莫展。如果连我自己都做不好，我何必对那些人恼怒呢？

 

真正让我郁闷的不是他们预估的错误。问题在于他们竟然认为自己可以做出正确的估计。作为开发人员，我们经常会发现，在软件开发的问题上，一个外行人会很自然的把复杂的事情估计的很简单。

 

这并不是为我们的愤怒找借口。但这引起了另外一个有趣的问题：为什么我们天生的预测复杂性的能力在遇到编程问题时会失灵？

 

为了回答这个问题，让我们来认识一下我们的大脑如何估计事情的。有些事情对于一些没有经验的人也很容易预估正确，但有些事情则不然。

 

我们来想想观看一个人弹吉他。即使你从来没有弹过吉他，在观看了一场弹奏《玛丽有只小羊羔(Mary had a Little Lamb)》的吉他表演后，你也能大概推测出这很简单，一个人不需要太高的技术就能演奏出来。同样，当观看了有人演奏D大调的《卡农(Pachabel’sCanon)》后，你也很容易推测出，这很复杂，需要很长时间的练习才能演奏的出来。

 

为什么我们能够很迅速准确的预估这两首曲子的复杂性呢？这是跟我们用来判断一个事情简单和还是复杂的方法有关的。我们的大脑有一些现成的模式来完成这些事情，首先一个就是根据速度。这种情况下，大脑会辨别每秒钟演奏的东西。根据每秒钟演奏了多少东西，我们很容易有一个直观的判断曲子的复杂度。因为用吉他演奏一首歌是一种物理过程，一种感官上的活动，我们的大脑很容易依此来推测速度，继而转换成复杂度。

 

我们还有另外一个天生的推测依据：体积。想想把一个帐篷和一栋公寓放在一起对比。即使一个人从来没有学过建筑学，他也能告诉你通常设计和建造一个帐篷会比设计和建造一栋公寓要简单。为什么？因为我们天生的会使用物理体积作为事物复杂性的一个指标。

 

当然。上面说的这两种逻辑分析并不是总是100%的有效。但大多数情况下，人们就是这样干，而且很成功。大多数情况中，我们在对物理过程评估时，我们的大脑会对物理事物进行有效的关联，不需要依赖之前的经验。

 

现在让我们来谈谈软件。当一个不懂技术的人试图对软件开发时间进行评估时，有两个很基本的直观指标在辅助他们：以体积为指标的复杂度和以速度为指标的复杂度。但他们没有意识到，软件跟他们想象的不一样。软件本质上不是有形物质。没有体积和速度。它的极小的组成部分可能会时不时的在电脑屏幕上闪现。正因为如此，当面对开发一个web应用时(或任何类型的软件)，我们的基本直观感觉失效了。

 

这第一点，速度，很显然根本不可能被外行人拿来对软件进行评估。于是很自然的，他们倾向于使用体积指标进行评估。要么是根据描述文档的页数，要么是根据软件的功能用例数或特征数。

 

有时候，这种评估手段确实有效！当面对一个静态网站，没有特别的设计要求，外行人很容易用这种方法估计出开发时间。但是，通常情况下，对于软件开发，体积并不能真实有效的反映复杂度。

 

不幸的是，对于软件的复杂度，唯一有效的推测方法是依据经验。而且还不是时时都好用。作为一个程序员，我知道，根据我之前开发过的相似的功能特征，我可以估计出现在的这些功能特征各自要多少开发时间。然后，我把总时间加起来，这就得到了完成整个项目需要的大致时间。然而，事实情况中，每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗程序员的大量时间，你在遇到它们之前根本不会有所预见。它们会拖住整个项目，致使工期延后数周甚至数月。

 

这些是没有经验的人在评估复杂度时不会理解的。他们不明白在其他事情上都很灵的方法，为什么放到软件开发上就不灵了。所以，下一次当你听到有人说“我想你几天时间就能把它开发出来”时，不管是谁说的，都不要懊恼。深呼吸一下，告诉他这篇文章的地址，自己该干什么还干什么。