“这个网站相当简单，所有你需要做的就是完成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 ]

我们都知道在Larry Page上位CEO之后，Sergey Brin的重心就转向一个神秘的Google X组织，领导着一些神秘的项目。那么这些项目都是什么呢？

• 自动驾驶汽车： 这可能是最先被曝光出来的Google X项目，现在Google自己也自爆了大量的信息，并试图加快发售和立法的过程。即便是盲人也可以“驾驶”汽车出行了，而且它为汽车增加了一种新的使用方 法：你可以叫汽车自动带你儿子去上学先，再让汽车自己空驶回家，接你去上班，再让它空驶回家，载着你老婆去超市买菜。“一家只买一辆好”。
• 由Google主办的Solve for X大会：这是Google将很多最聪明的人圈在一块堆儿召开的一个大会，试图一起协力解决一些世界上最难的问题。Sergey Brin会作为主持人来主持这场大会。
• 号称Project Glass的智能眼镜：尽管官方只是发布了一个演示视频，但据猜测应该是一款通过微型投影设备将影像投影到视网膜上的眼镜，可随时连接互联网与使用者互动，还内置摄像头
• 有来自Google总部的流言把Sergey Brin形容为蝙蝠侠，但我们还不清楚这种比喻是基于他秘密开发的什么项目，难道是个人空中飞行神马的？
• Google+：Brin去年的任务是解决社交问题，其最终的成品显然就是Google+这货
• 机器人：哦不，我说的不是Android（机器人）系统，而是真正的机器人，来自纽约时报的消息，这是一种只有打印机一般大小的机器人，Brin在前年曾经参加过一次这种机器人的相关会议
• Google自己的基础架构：在去年的Web 2.0大会上，Brin说他每周会花一天时间进行协调工作，另外四天则专注于Google的基础架构。估计主要是Google服务的后端相关事务，我们知 道Brin有自己的代码库，只有他自己可以访问这些代码，而很巧合的是这个代码库就叫做GoogleX

当然既然是秘密的Google X项目，就肯定有很多我们依然不知道的秘密，据说Google X有一大票的项目在推进。Brin则像一个疯子一样一心扑在这些有着改变世界野心的项目之上。熟悉他的人说，Brin是个健身狂人，除了疯狂健身，他就是在鼓捣那些疯狂的项目。

去年，Google以125亿美元收购摩托罗拉移动，今天这宗收购终于派上了用场。据彭博社报道，Google要求微软每年就摩托罗拉所拥有的WiFi和视频技术支付40亿美元专利，否则就要求微软停售Xbox。微软则回应说这不公平并向美国法院提起诉讼。

这场官司的结果可能会导致如下影响：

• 微软每年向摩托罗拉（Google）支付上十亿美元的专利费
• 可能削弱其它公司如高通对其授权专利费用的控制
• 可能影响微软从亚洲（制造商）进口Xbox到美国销售的能力
• 也许最终导致Android硬件制造商不用向微软支付专利费

如果微软与Google不能就此达成一个协议，法官可能会禁止微软从亚洲制造商那进口Xbox到美国销售。

对 于摩托罗拉（Google）的这个诉求，微软回应说这个费用太过高昂并且不公平。一位法官将就微软的诉求进行判断，而它的判决可能会影响其它公司在一些标 准专利上的收费情况。微软的诉求并非没有道理，Google的这项请求确实太过于高昂，因为类似WiFi这样的标志性专利收取的专利授权费往往在每台设备 几美分左右。这已形成一种惯例叫：FRAND（fair, reasonable, and non-discriminatory terms），也就是公平、合理以及非歧视条款。

但是这场战争却是由微软首先挑起的，微软要求Android/Linux设备制造商向其支付每台设备5-15美元的专利授权费，而不是几美分。Barnes & Noble拒绝支付该费用，直到上周才在法庭解决了这个问题。

如今，Google通过收购摩托罗拉移动也给微软来了个绝地反击。Geekwire的 Todd Bishop在其Twitter透露了摩托罗拉（Google）的底线诉求：微软本应该通过协商达成一个2.25%的专利授权，而不是向美国法院提起诉讼。摩托罗拉的律师告诉法官“别忘了这是它们（微软）挑起的战争，而不是我们”。

文章来自 36氪