不懂技术的人不要对懂技术的人说这很容易实现

站长苏飞

不懂技术的人不要对懂技术的人说这很容易实现

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[英文原文：I'm Sure It Will Only Take You A Few Days To Code ]


站长评论：软件时间的评估，离不开经验和自身对技术的掌控能力。忠心的希望领导们把这个工作交给程序员自己来衡量。然后再让一个技术大牛帮助他矫正。而不是找一个不懂技术的孩子在那里指手画脚的

站长苏飞

原文

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

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

The real reason I’m annoyed is not that their estimate is wrong. It’s that they assume that they can even make an estimate. That’s because as developers we unconsciously realize that the way a layperson 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 does the way we naturally measure complexity stop working when we apply it to programming?

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

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

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

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

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

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

The first one, speed, is essentially impossible to estimate for the layperson offhand. So the natural heuristic they tend to use is size. Some go with number of pages, some go with number of actions or number of features.

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

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

That’s what someone without experience misses when they try to estimate complexity. They don’t realize that what works in 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 them to this post and go on with your day.

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

gaide168

上次有一货叫开发双色球软件, 要求80%的中奖率

站长苏飞

gaide168 发表于 2014-8-8 15:41
上次有一货叫开发双色球软件, 要求80%的中奖率

有这能力还给他开发干嘛，自己坐等钱来了

水手

gaide168 发表于 2014-8-8 15:41
上次有一货叫开发双色球软件, 要求80%的中奖率

有这能力？谁还做程序猿？~有这能力，早去做救世主了~