编码，快与慢：开发者和过度自信心理学

本文翻译自：http://blog.hut8labs.com/coding-fast-and-slow.html?reddit

今天我要讨论的是，当一个开发者对一个项目做时间估测时，他会想到什么，为什么会很难调整，并且我会发表些个人观点来指出，即使我的预测和以前一样很不可靠，会怎么去编写软件。

首先，说一个故事吧。在大学时（写上日期会使我看起来不至于太荒谬），我是一名年轻的开发者，也已经积累了一下编码经验。作为一名初级人员，我认为自己可以写出解决任何问题的代码，并且比任何人期望的都要快。我可以在一个多星期的时间里学习一门新语言并能写出一个像样的东西来（或者说，我是如此的相信自己）。

因此，我有自己的项目。客户经理问，在短时间内，客户想要的会是什么？我们讨论了这个问题，然后我说：“应该3个星期就可以完成。”“听起来很好，”他说。于是我开始写代码。你能想象出这个项目到底花了多长时间吗。四周？或五周？呃，实际上：三个月。

关于那段时间，我记得很清楚——在我心中，我的形象就是“一个好的程序员”，但可恶的是，我失败了。并且也会失眠。我仍然记得和客户经理解释时心中那种不好的感觉，一遍又一遍的说我仍然没有什么东西可以展示。

在那段黑暗的时期，我决定以后再也不要犯这样的错误。

不幸的是，在我的职业生涯中，我认识到：自己总是在犯这样的错误。

实际上，我甚至意识到：我们都在犯这样的错误。

最近，我读到了Kahneman的“思考，快与慢”，这是一项大范围调查：人类认知心理学的的神奇力量与其（可预测的）失败。

我最喜欢的就是过于自信这个因素。这个就与开发者做评估的方法有关系。

为什么你会评估失败，第一部分：写软件=当你开始时，学习一些你并不了解的东西。

首先，我相信，有两个原因导致我们做预测时的失败。第一个是不可缺少的因素：写软件需要你让一些东西详细精确到你可以告诉计算机怎么完成它。问题是，当你开始时隐藏在背后的那些你并不完全了解的部分，通常会有一些问题出现并且完全让你崩溃。

例如. 一个和第三方服务的连接不可靠...所以你不得不写一个失败时重连的跟踪程序；或者数据库不能辨识某些编码类型的字符...然后你不得不重新构建自己的架构；又或者，真正经典的是：当你向客户展示自己的产品时，他们认为那不是他们真正想要的，需要做一点点的不一样...，但是那又很难实现。

当你第一次遇到这样的事情时，你会想：“下一次在这个阶段时我更加小心就是了”。但这是最失败的。为什么？关键原因是，如你在上面看到的例子那样，如果你能看到那些背后隐藏的细节，你就已经是在写代码了。关于这一点，真的是没有办法的。（如果，当你读这个的时候，你正在解决这样的问题，我不得不告诉你，真的真的没有办法的。全面的规格说明也不是一个划算的注意。下面我要说的就是一些比较好的方法。）

说到这里时，也变得越来越有趣了。每一个进入到真正的编程世界几个月的人都会遇到我在上面描述的问题。（我现在也正面临这样的问题，被问到这个多久能做好，这周？下周？真不知道怎么说，因为真心不愿意自己拖延自己的计划。——译者）

但是，我们仍然制定着这些让人匪夷所思的计划。糟糕的是，我们也相信我们自己的预测。当我说出自己的预测时，我也仍然相信我自己的。

等下，我是在建议所有的开发者都去陷入一个同样的，可以预测的错误的思路上去吗？

是的，那正是我要说的。

为什么你会评估失败，第二部分：过度自信

Kahneman花费了一些篇幅讨论了专家在做预测时存在的这个问题。很多情况下，这些预测被证明是毫无用处的。特别是，在许多情况下，下面三件事都是正确的：

1 — “专家”的一些对于未来的预测是如此的不可靠，也基本没有意义。

2 — 看起来没有什么东西能够打击到专家的自信。

最后一个：即使专家在以前失败的证据面前努力坦然面对，即使专家非常了解人类认知上的瑕疵，他们依然对自己的预测极为自信。

在讲述了关于他自己的失败的“一个令人吃惊的故事”后，如Kahneman解释的：

“在未来的评判中你将会有的自信将不会因为你读了这个文章而有所改善，即使你相信这个文章里的每一个单词。”有趣的是，在一些情况下，专家的预测也是很准确的——下面我会解释的，并说明怎么应用到你自己的开发过程中。但是在那之前，我会说一些关于过度自信的细节，这样你或许可以能认识到自己的问题。

犯错是什么样的感觉：系统1&系统2，3周和3个月的问题

在“思考，快与慢”中，Kahneman说到一个很好的心理方法，操纵我们思想的两个系统的内部作用：系统1和系统2。我的总结就是“系统2负责认真的，理性的，分析性的思维，系统1则主导快速的，启发式的，模块匹配式的思维”。

重要的是，好像事情慢慢演变到系统2不得不做很多的工作。从进化的角度来讲，系统2就像产蜂蜜那样慢，并且很珍贵，它应该在非常非常少的环境中有效利用。毫无疑问，你看到了问题所在：没有思考，你的思维如何进入到系统2？从这方面来说，各种各样的心理学的“认知基本论”中许多都可以解释，当一个优雅的工程方案实施到残酷的现实世界时：怎样实时分配注意力。

为了说明这个问题，我会简明的引用我的一个朋友Edmun Jorgensen的回复，他在邮件中的回复如下：

“当我问自己“这个项目要花费多久？”，系统1没有主意，但是它引出了另一个问题“在这件事上我有多自信，”再转移到原来的问题上，就因人而异了，比如，鲍勃的自信程度会让他认为是3周，苏的自信程度会导致5周。”

如果你渐渐意思到你有两个差别很大的时间预测就举起你的手。例如，对我来说“3周”和“3个月”，前者意味着“看起来有点复杂，但是我认为自己基本上知道怎么做”，后者就是“哇，这很难，我不确定会有什么问题，但是我确定我可以解决。”

我认为Edmund完全正确。

（要是像开始说的那样，我的“3周”工程花费了5-15周，我的“3个月”工程通常就是1-3年，这种情况下，我想极少有人愿意雇佣我了吧）。

好，让我们停止如此过度自信吧

你或许会想，“好，我已经意识到Dan（原文作者）的问题所在了，所以我们可以让系统2来为我们的时间预测做更好的决定。”

恭喜你，你刚好给自己挖了个坑。

那正好就是“编码前全面的说明书”做到的：不允许团队根据直觉来做预测，需要他们认真分析，将时间分段，然后做出一个详细的计划书。

但是那总是会失败。

真正的麻烦是在两个预测失败的原因的轮番上演：人类的过于自信，和真正的软件工程中不确定性的问题。那种不确定是如此的苛刻以至于甚至是仔细的，理性的系统2也不能做出精确的评估的。

幸运的是，有一个方法可以加强你自己的认知并且处理真实世界的各种不确定性。

首先，如何加强认知。

当专家是正确的时，你该如何利用

Kahneman和他的研究者们已经能够辨别专家的判断哪些方面也不完全是糟糕的。他说：“想要知道你是否可以相信一个直觉的判断，你应该问两个问题：这个判断产生的环境是否是足够的常见来强有力的支撑这个判断吗？专家有足够的机会去接触这些规律性吗？”

一个“足够的机会”就是说许多的实践机会和紧凑的反馈圈。

现在，6-18个月的软件项目在所有这些标准下只能悲惨的遭遇失败。正如我前面讨论的那样，环境并不是如此常见。此外，专家没有获得关于预测的大量实践和快速的反馈。如果有些事情需要一年或更多，这个反馈圈也会是太长而不能验证你的直觉。

然而，在软件开发中有一个评估的形式适合那些0-12小时的任务，假如可以立即执行的话。那样的话，事情会不一样：

l   尽管仍有许多的不确定性，仍旧有一些“在你的开发环境中规律性”的希望。两个4小时的任务比两个6小时的项目有更多的共同性。

l 在两年的时间内，你可以做上百个这样的评估。

l 你可以快速获得反馈。

我曾处于的最高效的团队，他们都是在短的时间段内工作，就是将每件事，基本上分为0,2,4，或者8个小时（8个小时的工作总是会不容易完成，因此，我们尽量将其分的更小）。我们会快速评估并且有时——我们甚至不用计划板。

那时，你正在用系统1来思考——它有机会去被训练，可以看到很多例子，并且有很多有意义现有模式。多亏了这种“短跑”式的形式，你可以快速获得评估质量的反馈。

等下，等下，等下，那我们就做上千个4小时的计划吧！

我怎么能确定你可以做出这样的一些预测，但是就是不能把他们融合成6-18个月的计划呢？错误就不会出现吗？

基本上，我认为那样的预测是准确的，当他们是错的时候，也不知道会错成什么样子？以数学的形式来说，我觉得实际的时间会成幂级分布。坦白的说，也就是那些流水瀑布式的项目评估给我的感觉。

你或许会想：你究竟怎么能评估出是花费4个小时还是一两个月？

这总是会发生的：你已经在做一件事情的最后一步，发现一些讨厌的模块完全改变了方式。例如：在最近的一次启动中，为了排除我们的系统中的某一个地方的失败，我们在IMAP服务器上放了一个负载均衡器。这样，当一个服务器挂掉时，负载均衡器就会平稳的移到另一个上面，这个过程对于客户来说是透明的。

那看起来就是一个类4小时的任务。

但是实际操作时，却发现，IMAP服务器不像HTP服务器那样一直保持连接状态。散落一，如果我们不得不在两台服务器上保持连接状态或者写一个状态监测代理的负载均衡器。

而这看起来就是一个3个月的项目了。

还有另一个原因：在一个可怕的糟糕的评估的消耗上也会有严格的限制。

我们只能如此糟糕吗？

那我们该怎么办？仅仅接受我们的项目注定的失败吗？那样我们就会破坏商业合作关系，因为我们总是不能兑现我们的承诺？

首先就是接受做出长期的准确的评估是基本上不可能的。一旦你那样做了，你就会有一个极其困难的挑战：怎么能让你的开发团队产生巨大的价值，即使你不能做出有效的决策？

我们所讨论的基本上就是为什么各种敏捷开发已经占据了世界的解释。在我的下一篇文章里会更详细：“没有最后期限！软件开发没有评估，说明书或者其他的谎言”。