《人月神话》书评

《人月神话》20周年纪念版评论集

Brian Kernighan

我唯一一本读过一遍以上的书，是Fred Brooks的《人月神话》，实际上我每过一两年都重读一遍。部分原因是这本书文笔很好，部分原因是书中的忠告很有价值，即使是25年以后。当然，现在很多细节上的地方，和我们做事情的方法，都有不同。我们的工作更自动化，计算机的“马力”更强劲，但书中依然有许多好的忠告，我非常推崇这本书。这是我唯一能想起来的你能从中体会到乐趣和思想的计算机科学书籍。

Ed Yourdon

有些书对于读者和作者象是年金，它们年复一年的分红。《人月神话》就是这么一本书。我直到在1994年接到Brooks教授的电话，才真正完全赏识它。

原因来自他的电话，电话中他说，他的出版商请他修订他在1975年第一次出版的这本书。我立刻表示了我的一点妒忌、羡慕；因为我的出版商从未叫我修订一本出版接近20周年的书。确实，我甚至表示了这样的意见：当代的软件工程师不会考虑阅读这本如此古老的书，因此，可能无法卖出一本。“哦，不”，Brooks教授回答道，“《人月神话》到目前为止，每年稳定的卖出10000本。”

嫉妒、羡慕和突然的现实：什么是我们拥有的象年金一样的东西。我高兴地说，自此书出版至今，我已读过1975版至少四遍；在接到Brooks电话后，我再次将它从书架上拿下来，重读了一遍。但这次，是有特殊目的的：实际的原因来自于他的电话，Brooks教授告诉我，目的是发现自这本书1975年出版以来，计算机领域是否有有意义的事件发生。

我必须申明，这样的问题是相当难以回答的。Brooks继续告诉我，他现在已基本离开软件工程社团，将他的大部分专业精力投身于虚拟现实领域的研究。所以，在准备再版这本书时，他想知道：什么已经改变了，什么还没有？他的原书中哪些是正确的，哪些是错误的，哪些是不切题的。

当然，我不是向他提供同样信息的唯一的人；我的一些同僚、大量的业界领袖、作者、顾问和摇旗呐喊者都被邀请回答这个问题…。我们所有人很高兴地做了。并且，象你所期望的一样，我们的输入被Brooks教授处理、分析、过滤、综合进那个非凡的新版本——它是真正的国际财富。

原书的内容仍在那儿，现在新增了四章。它们是Brooks教授对他的思想的反思和对我们的反馈的反应。新增的第一章由恰到好处地浓缩的原书主题组成；包括可以被称为书的中心论点的东西：大型编程项目忍受管理问题，这些问题因为劳力的分配而与小项目有本质上的差别；软件产品的概念完整性是如此关键；概念完整性是困难的但可达到的。第二章小结了二十年后Brooks对这些主题的观点。第三章是他1986年首发于IEEE Software的经典报告：《没有银弹》的重印。最后一章是对Brooks1986年的断言 “在未来十年，依然没有银弹”的思考。

年轻的软件工程师、吝啬的研究生、懒惰的软件老手常请我标示出当前为止最好的软件图书。“如果我带着仅有的一本计算机书在沙漠荒岛上，”他们问，“应该是哪本书？”这是个荒谬的问题，但人们坚持要个答案。假如你真的被放逐到这样的小岛（或者你决定躲藏到这样的地方去避免2000年软件崩溃的恐惧！），《人月神话》应该紧随着你。

Jason Bennett

背景

在我提交我的关于《人月神话》的书评前，我意识到没有介绍此书的第一版是我的疏忽。那是1975年。程序员辛苦的在最早的哑终端上工作，这些终端连着来自IBM的笨重主机。也许，如果足够幸运，程序员可以工作在一台小型计算机，它来自于业界的新星公司DEC，和它们的PDP系列计算机上。FORTRAN和COBOL是主要语言，夹带着一些PL/1。C是地平线上的亮点，刚刚开始离开Bell实验室走它自己的路。在整个工业范围中，汇编语言仍在广泛的应用。进入Frederick Brooks的书，工业界的原作之一。Brooks在反思他在IBM的时间，特别是他在1960年代中期工作于System/360和它的操作系统，OS/360（独特的名字，不是吗？）的一段。Brooks试图指出哪些做对了，哪些没有，特别是如何构造和管理全部程序。他因此开始书写软件项目管理的第一个条约，一个软件工程不可缺少的部分。二十五年后，我们仍然读这本书，学习它。在业界，大部分书六个月后就无用了，这本书则是空前的。记住，虽然，最终会有书能达到它的水平。

哪些是好的？

你可能很想知道，为什么这本书能持续如此长的时间。答案是简单的：书中的技术对大众的教训来说是次要的。简单说，Brooks指出下列几点：

1．编程必须进入到软件工程，以便持续改进技艺的状态；

2．任何好的工程产品，必须是概念和体系结构的完整结合；

3．软件开发中的焦油坑（the tar pit）可以通过尽责、专业的过程得以避免；

书中有如此之多的经典语录，以致这篇简单的书评不能全部包括。当然，最著名的是Brooks定律：加人将延迟工程（隐义：这样做没有帮助）。在MMM（《人月神话》）中外科开发团队、第二系统效应、文档的重要性等均被覆盖，有些还是第一次出现。通过这本书，Brooks覆盖了所有因素，这些因素是成功完成一个主要软件项目必须做的；同时，在书的各部分中，他给出了一致的软件工程与项目管理的坚实的基础。事实上，这是第一本主要的正确汇集工程师需要的关于大型软件项目开发知识的书，书中相关知识来自于对已完成项目的看法。除了原书，Brooks 1986年的随笔《没有银弹》也被包括进去，同时带着Brooks在这本书出版二十五年后的思想。这些随笔每篇都值得一读，因为它们给出了当前工业所处位置的精确评价。可以这么说，容易的部分已在我们身后，让我们从这儿开始实际的工作。

哪些是有害的？

关于这本书哪些是有害的，答案是：人们没有读它。没有特别的好理由，他们仅仅是太忙于读最新的关于今天时尚的书了。当然，具有讽刺意味的是，今天的时尚可能是明年的笑话，而MMM（《人月神话》）将从现在开始下一个十年。如果，学校发给你这本书，再次读它（你可能不是第一次:-））。如果你从没听说过它，明天开始读。

书中哪些是对我们的有用的？

为什么我们每一人都应该读这本书？对于一串半组织化的小组哪些项目管理是要紧的？在我们为世界大同努力奋斗时，我们是否做的不好？嘿，是或不是。

首先，我们没有商业软件的压力。如果Apache明天发布而不是今天，没问题。每个人可能是坏的，所以我们不会做的更糟。因为如此，大部分开放源码项目，依赖一个或几个领导者，他们追踪着每件事和版本。我们没有许多拥有大量不同文档的项目。

其次，我们也依赖于低的期望值。没有人对我们有成功的预期，所以，对于这个运动，任何一个成功都是个胜利。现在，所有的眼睛都盯着我们。如果一个发布版延迟一个月发布，每个人都会说我们在保持时间表上做得不如微软。如果我们因为我们的可怜的设计而重写了一个应用，我们将不能提供有效的替代品。我们将不得不做得比其他人更好以证明我们自己，并且我们不能做面向特定平台环境的产品。如果开放源码社区比工业界学习MMM学得更好，那么，我们将获胜。

再次，作为一个工业，我们必须提升我们软件的期望。我们要为精确的时间表努力奋斗。我们需要避免第二系统的影响。我们需要知道为什么你不能加人到已经延误的项目去加速开发。长话短说，我们需要仔细工作以及时产出合格的软件，而不是仅仅将原料放在那儿。

Francis Glassborow

我第一次接触这本书在近二十年前。作为一个学校老师，我毫不怀疑这本书应是我的天才计算机专家的小伙子们需要读的。也许我的成功不能表示它的价值，也许人们不知道它。

计算机图书常常在用旧前很长时间就已过时了，但这部书是一个值得注意的例外。作者描述了管理的失败导致延误了在恰当时候交付的问题，在今天――《人月神话》首次出版以来二十周年后，依旧在发生。加倍的工作力量在今天和他那时一样不能解决时间（表）的流逝。

如果，你已经拥有了老版本，你仍然会为带有额外的四章的新版感到高兴；如果你以前从未读过它，把其他事放在一边，立刻补上这重要的一课。象老版本对暴露关于延迟六、七十次的IBM感兴趣一样，这个版本增加了一些关于微软的注释（尽管如此，每晚重建开发项目的策略不能解释为何Windows95的M8 beta版的版本是950版）。

Chris Larson

自Frederick P. Brooks, Jr. 出版经典著作《人月神话：软件工程随笔》已经20年了。在这部注重实效、明晰的书中，Brooks剖析了许多工程管理的神话，这些神话来自他在年轻的软件工业中有意义的实践。典型的，他抨击了在项目中增加人手可以促进项目的完成的幻想。带着实例、幽默、严密的逻辑，Brooks展示了这些神话实际上如何给软件项目带来灾难并导致延迟。

你不能用人力换取时间

他的思想恰到好处地应用于文档项目的管理。有多少次查看文档项目的经理思考通过增加人手缩短时间表？这是个简单的导致陷入的谬误，但Brooks清晰地表达了这样的思想－“人力可以与时间互换”的实际效果。

Brooks说，“导致大量软件项目进入失控的原因是时间表的缺漏，这比所有其它因素的组合还多。”他给出了几个原因。首先，Brooks责备可怜的估计技术，它错误的“搞乱了前进中的努力。”因为估计的不确定性，经理们缺少“礼貌的倔强”去支持那些看上去比其它需要更长的时间线的步骤。一旦时间（表）流逝，倾向于加入更多的人力，而这就像“火上浇油”，会导致一个新的灾难生成的循环。

当然，一个基本的错误就是假定人力可以严格的和时间交换。Brooks指出，这个公式仅在项目成员不需要和其他人交流的项目中成立，比如：拾棉花。

然而，一旦项目中包含连续任务和依赖关系时，可以交换的思想立刻就土崩瓦解了。“交流的努力，”Brooks说，“必定导致加入大量要做的工作……。三个工作者要求的成对交互交流三倍于两个；四个六倍于两个。”这个交流的时间（不包括培训时间）吸收了许多增加人力分担任务带来的好处。

那么，答案是什么？

Brooks认为由一个组织，其结构类似于外科团队的，由一些专家设计并完成全部项目的核心工作而由另外的人力在特定的途径上支持他们的努力，来执行产品开发可以治愈上述病症。

Brooks说到，这条仅有的路是在一个项目早期完成“概念完整性”的通途。大部分关于这些完整性的重要的表述通过这个规范发生，“那是一本计算机手册加上性能规范……第一批文档中的一篇产生计划中的一个新产品，最后的文档完成它。”

文档是关键

Brooks继续雄辩的支持文档，列出用户需要的每一项，以免只见树木不见森林：程序的目的、环境、选项、逻辑、“运行时间、”等等。并且认为：“大部分文档需要在程序编写前起草，因为它把基本的计划决策具体化了。”

作为技术交流者，我们需要听到来自工程方面的更多的各种各样的支持。尽管Brooks的环境――运行于大机上的大型编程项目――已经转换到我们今天的分布式计算环境，Brooks的逻辑和清晰的思想依旧吹走了仍然威胁卷入项目管理中的迷雾。

Frank Chance

介绍

出版于1975年的《人月神话》是软件开发方面的经典作品。1995年版包括了令人感兴趣的新的几章，但原来的随笔依然是这本书的心脏与灵魂。在这本书中，Brooks解决了如何组织和管理大规模编程项目的问题。这些项目要求成百上千的程序员，产生几百万行代码（想想SAP、Oracle数据库引擎、Windows2000）。这部书由一系列简明的随笔组成。在这篇评论中我将讨论开篇随笔――我的最爱之一。

焦油坑

Brooks将大系统编程作比喻作史前的焦油坑来开始他的第一篇随笔：“记忆中，我们看到恐龙、猛犸象、剑齿虎正在挣脱沥青的魔爪。挣扎得越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，它们最终都沉没了。大系统编程在过去的十年间就像焦油坑，许多大而强有力的野兽在其中已经惨烈地失败了。大部分已实现并在运行的系统，很少有达到目标、时间表和预算的。大和小、厚重和细实，一个接一个的团队卷入了沥青（陷阱）。没有什么事情似乎会导致这个困难――任何特殊的手掌都能被拉出来。但同时并相互作用的因数的相互聚集导致运动越来越慢。每个人似乎都惊讶于问题的难缠，难于面对它的本质。”

记住，这些话写于1975年。今天它们仍然可用吗？考虑一下WindowsNT5.0。第一次计划于1997年发布，随后延迟到1998年早期，1998年末，然后是1999年（为此它被重新命名为Windows2000）。这儿是一些公开的估计：

	5,000程序员。
	35,000,000 行代码。

显然，NT5.0是个大系统编程项目。同样显而易见，Brooks的焦油坑在今天同1975年一样普遍！

让我们继续NT5.0的例子。假设最糟糕的情况，全部35,000,000 行代码都是新编的。有理由假设开发工作大致在1994年开始。所以我们有：

	5,000 程序员 X 5 年 = 25,000 程序员年
	35,000,000 行代码 / 25,000 程序员年 = 1,400 行／程序员年。

如果你是个程序员，或者你只接受过编程课程的教育，这个数字（1,400行每年）似乎令人惊异的低。我们当中的大部分人都能在一两天内堆积出接近一千行的代码。什么使得Microsoft的程序员一整年才产出1,400行代码？

两种可能性跃入我们的脑海：

Microsoft 雇用了5,000名不合格的程序员去开发NT 5.0。

或者

写一个大规模的程序系统产品远难于堆砌出单一的程序。

Brooks将讨论认为后一个答案是正确的。他由定义术语开始：

（1）程序

一个独立的程序是我们两天编程狂欢的结果。它是准备自己运行于我们编程的那台机器上的。如果我们加上文档、通用化代码、编写测试用例、使得代码可以由其他无关的编程人员来维护，我们就有了：

（2）程序产品

另外，如果我们接受我们的程序，并且完整地定义了它的接口使得它达到预定义的规范，并且测试了它和大量的其它组件的交互作用，我们就有：

（3）程序系统组件

并且如果我们都做了（加上文档、通用化代码、编写测试用例、使得代码可维护、定义了接口、测试了交互作用），我们就有：

（4）程序系统产品组件

Brooks用手边的三倍规则说明在上述每个步骤中的工作要求：

（2）＝3倍（1）的人力

（3）＝3倍（1）的人力

（4）＝9倍（1）的人力

或者，换句话说，开发一个独立的程序仅仅要求开发一个程序系统组件的1／9的人力。

回到Microsoft的例子，如果我们将这个9倍的因子乘以1,400行每程序员年的生产力测量，我们得到12,600行每程序员年（举例来说，假设我们掌握每一程序员，并且使得他们独立工作，堆砌在单一的程序上）。在一篇独立的随笔中，Brooks引用一个发现这点的经理的话说，平均他的每个程序员仅能将他的一半时间用于开发――其它时间由文书工作、会议和各种其它任务所占据。把这些因素考虑到Microsoft的例子中，我们达到了25,200行每程序员年。那么，Microsoft的程序员开始看来非常可敬。另一个测量自1975年来有了很小的改变，Brooks引用的估计是1,000行每程序员年。如果上面引用的1,400行每程序员年是精确的，那么，它表现了在1975年到1995年20年间，生产力仅仅提升了1.75%每年。这个结果证实了Brooks的另一个假定――程序员的生产力相对是个常量，它不受开发所用的语言的影响。因此，实际的生产力收获来自于迁移到高级语言编程，这些语言每行表达了更多的实际工作。尽管目标是大系统项目，Brooks的解释常常被广泛的应用。例如，这个第一篇随笔用标有“手艺的快乐”和“手艺的悲哀”的小节来结束。在悲哀中，他讨论了荒废的问题：

“…这个人们已经工作了很长时间的产品，显然在完成前将被废弃。同事和竞争者已经在热烈地用新的和更好的主意反击。人们的孩童般想法的取代已经不仅仅在构思，而且付诸时间表。这一切总是似乎比它的实际更糟糕。新的和更好的想法通常在完成之前不被应用；它仅仅被谈论。真老虎永远不能和纸老虎相比。”

小结

Brooks的随笔涉及到了大系统编程所固有的多种挑战，但对任何投身于软件开发的人来说读这本书都是有用的。题名的随笔（《人月神话》）讨论了许多编程任务的不可分割性，和为什么增加人力到软件项目中无法产生效用。我的另一篇最爱是“贵族、民主和系统设计”（概念完整性的讨论）和“计划和投放之路”（在付运前多次交付的明确计划的益处）。一些问题已经因为技术的进步而废弃，例如关于如何在一个大型团队中分发写好的文档。然而，你可能惊讶Brooks面对的许多问题今天如何阻止我们。另外的益处是Brooks简洁、清晰的作品读起来令人愉快。如果你是个程序员，如果你和程序员一起工作，如果你管理程序员，你应该阅读这本书。

TAL COHEN

人们说在计算机世界中每件事都在迅速的变化，然而，在二十多年间，一些重要的事情依旧没有改变。

如果某个工作可以由十个人在一个月内完成，人们说这个工作要求十个人月（man-months，也叫“person-months”）。简单算术表明，如果你分配二十个人去作同样的工作，它应在五个月内被完成。（译注：应该是半个月）我想这个逻辑在许多项目中大概都是正确的，否则，经济学家将不会那么令人喜爱。

然而，在软件设计的世界，这个承诺是个彻底的谬误。没有那条途径可以产生它。一个能由一个程序员在两个月内完成的程序，也许会花去两个程序员三个月的时间。早在1975年，当软件工程还是非常年轻的专业时，Frederick Brooks敏锐地观察到人月概念仅仅是个神话。

在70年代，软件工程项目管理的问题背景是：大部分经理是受的经济领域的教育而不是计算机，并且他们熟悉的理论不能简单的用于软件项目。事实上，没有用于软件设计项目的相同的理论。因为直到今天，大部分软件项目仍不能按照时间表发布，所以我们有个大胆的暗示：这个问题象许多Brooks在书中谈到的那些问题一样，仍未解决。

在20周年纪念版的序言中，Brooks写到：

让我高兴和惊讶的是，《人月神话》在20年后依旧流行。

实际上，这真令人羞愧。它指出了在二十年间，软件工业没有学到一些严重的教训，它仍在付着学费。软件工程依然被认为和其它工程专业相比是个很陌生的艺术。真的，我是第一次接纳软件编写中存在艺术的观点。它是一种美丽的、精巧的艺术，仅仅能被那些掌握同样艺术的人所欣赏。我相信，当一个真正的代码艺术家完工时，它比建筑更加迷人、比油画更加引人入胜、比音乐更加令人思潮澎湃。然而，一个建筑师不会让房屋设计的艺术外观将他从房屋可以经受住最起码的地震的保证中转移出来。这个事实正渐渐的被大部分软件专家――那是些认为自己是艺术家而拒绝承认自己是工程师的人，所理解。（一个有趣的解决方案，是由我的好朋友提出的，他认为他自己是个“软件架构师”。）

Brooks的工作是简单的而且对于那些被认为在软件业务领域是个专家的人是必需的，尤其对于在这个领域从事管理工作的人。这部书不仅仅指出了问题，而且也提出了些有趣的解决方案（例如：“外科团队”）。它指出了这个领域的每个专业人士都应该知道的一些非常重要的缺陷（例如“第二系统”效应）。最后，它提供了许多重要的见解和案例研究。

书中大部分材料和今天依然相关，就象它在原书写出来的时候。尽管，众所周知，部分材料已经过期时。在20周年纪念版中，相对于原文――叫做“经典”――的修订，Brooks聪明地决定加入修改的章节。那些用来讨论暴露于90年代灯光下的出现的问题。我个人认为，在读完前面的每一章后应读第18章中有关的部分。第18章的标题是“人月神话的主题：是或非？”，它包括了从1到17章的修改信息。

最后，这个新版本包括重印的Brooks的著名随笔，“没有银弹”，那是在都柏林IFIP86会议上的特邀论文，后来在Computer杂志上发表。在这篇文章中，Brooks推测在他的文章出版（1986年）后的十年，不会发现有技术可以大大增强软件开发过程。九年过去了，Brooks悲哀地回顾：他还是正确的。