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

dbbdggdbbdgg 2002-10-30 11:56:50

《人月神话》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认为由一个组织，其结构类似于外科团队的，由一些专家设计并完成全部项目的核心工作而由另外的人力在特定的

...全文