《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。在《人月神话（英文版）》中，既有很多发人深省的观点，又有大量软件工程的实践，为每个复杂项目的管
理者给出了自己的真知灼见大型编程项目深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。《人月神话(英文版)》适合任何软件开发行业的从业人员阅读
，对软件开发人员、软件项目经理、系统分析师更是必读之作。
对于软件项目进度的估算往往会根据项目的紧急程度而得出过于乐观的结果，这一方面是因为所有的编程人员都是乐观主义者，我们往往会认为“这次肯定能运行”或者是“我已经找出了最后一个bug
”，另一方面则来源于市场的压力，这种情况在国内环境更甚。我们对于进度估算的第一个错误假设就是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。而这个假设往往是一厢情
愿的，对于创造性工作来说，创造者常常是在实现过程中，才发现在构思设计时候的不完整性和不一致性，从而反馈到的构思设计上，处理这种问题的时间和复杂程度会随着项目的结构以及任务的大
小而呈现非线性增加的关系。所以对于大型软件项目来说，“一切都将运作良好”就是一件概率非常小的事情了。
在软件项目中我们往往用人月这个指标在衡量项目的工作量。但是人月这个指标实际
上是一个危险的带有欺骗性的神话。它暗示着人员数量和时间是可以互相替换的。只有在将任务分解给参与人员后他们之间不需要互相交流的情况下，人数和时间才是可以互换的。在实际软件项目中
，只要项目具有一定规模，不论是设计、开发、测试、部署各个阶段都会有分解任务给不同人员，而且这些阶段本身也属于一种任务的分解，在不同人员间分解任务就不可避免的引发额外的沟通成本
——培训和相互沟通。因为软件开发本质上是一项系统工作——错综复杂的关系下的一种实践，沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。简单来说就是，3个人要干
3个月的事情不是说安排9个人就能1个月干完了。而且，在进度落后的项目中增加人手的做法，往往只会使进度更加落后。这就是去除了神话色彩的人月。
面对软件项目的“焦油坑”以及“人月神话”，作者给出的一个解决办法是——“外科手术队伍”。有研究表明，同样有两年经验而且受到同样培训的情况下，优秀的专业程序员的生产率是较差程序员的10倍。在软件项目中，一个小型的、精干的队伍是最好的，这样既减少了沟通成本，又提高了生产率。但是对于真正意义上的大型系统来说，小型精干的队伍往往意味着太慢。这就是矛盾的所在对于效率和概念的完整性来说，最好由少数精干的人员来设计和开发，而对于大型系统来说，则需要大量的人手，以使产品能在时间是满足市场的需求。
在软件项目中的“外科手术队伍”有一个类似于外科医生的首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制主架构源代码，测试以及书写技术文档。首席程序员还拥有一个副手，他主要作用是作为设计的思考者、讨论者和评估人员。与传统的两人队伍每人负责一部分工作的设计和实现不同，“外科手术队伍”中的这两个人需要一起了解所有的设计和全部的代码。其他的程序员以及管理者，文档编辑人员等围绕着主架构的设计来具体实现功能以及推进项目。这种队伍的好处就在于既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
作者特别强调软件系统的概念完整性，为了确保这种完整性也是需要由一个首席程序员或者具有共识的小型团队来从上至下的对系统结构进行设计。
我们要认识到的是软件开发中存在着两种困难，一种是根本的——软件特性中固有的困难，另一种是次要的——目前存在的，但并非与生俱来的困难。对于前一种困难来说，没有银弹。而后一种困难可以通过软件工程管理或者技术的进步来克服。
在软件开发中存在着4个天生的根本困难——复杂度、一致性、可变性和不可见性。
复杂度是说在规模上，软件实体可能比以往人类创造的其他任何实体都更加复杂。一方面，来自于计算机本身的复杂性，还有软件系统的状态的繁多。另一方面，软件系统的各种元素还是以非线性递增的方式在交互，使得软件复杂度比非线性增长还多得多。而且由于复杂度，软件团队成员的沟通成本也非常的大，也产生了一系列的技术上的困难，同时还会引发很多管理上的问题。
一致性说得其实是软件兼容性，我们开发的软件往往为了保持一些必须遵循的人为惯例和系统，必须为这些接口保持其一致性。
只要是从事软件行业的人应该都能体会到软件的可变性，因为应用、用户习惯、自然社会规律、计算机硬件等的各种变化都会无情地持续地强迫着软件也要随之变化。在软件行业中有一句话就是，唯一
不变的可能就是变化的需求。
不可见性是说软件在客观存在上不具有空间的形体特征，无法可视化。无论是流程图还是时序图等等软件工程中使用的图表都无法像地图或者电路图一样在整体上给予所
有使用者完整的概念。从而使得软件设计人员和开发人员之间在设计上的一些概念无法完整而清晰的进行沟通交流。
现代软件工程中通过高级语言、分时系统、面向对象程序设计、使用开源库、敏捷开发等新的理论实践不断在克服软件开发中的次要困难，同时也减轻了一些根本困难。但始终不能消除软件复杂度这样的根本性困难。因为随着软件工具能力不断的提升，软件开发中需要面对的复杂度其实也是在不断提升的。所以，我们在软件生产效率上的提升需要的是逐步的进步，而不是期待一个一蹴而就的突破。
Freder ick P.Brooks，Jr.曾荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。
Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献
，他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖（NationalMedal of TecPlnoIogy）。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。
Brooks博士创立了北卡罗莱纳大学的计算机科学系，并在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。Brooks博士 [1] 的教学和研究方向是计算机体系结构、
分子模型绘图和虚拟环境设计。
