简介
《人月神话》内容源于作者Brooks在IBM公司任System计算机系列以及其庞大的软件系统OS项目经理时的实践经验。
摘抄：
- 程序员不愿意为设计书写文档的原因，不仅仅是由于惰性。更多的是源于设计人员的踌躇--要为自己尝试性的设计决策进行辩解。
- 由于介质的易于驾驭，我们期待在实现过程中不会碰到困难，因此造成了乐观主义的弥漫。而我们的构思是有缺陷的，因此总会有bug。也就是说，我们的乐观主义并不应该是理所应当的。
- 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
- 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流。
- 当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
- 对于软件任务的进度安排，以下是我使用了很多年的经验法则： 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试。
- 最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异！简言之，$20,000/年的程序员的生产率可能是$10,000/年程序员的10倍。数据显示经验和实际的表现没有相互联系（我怀疑这种现象是否普遍成立。）
- 由一个人来进行问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
- 要表达一件待完成的事情，常常需要对基本元素进行意料不到的复杂组合。
- 概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
- 实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。
- 不变只是愿望，变化才是永恒。
- 普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。
- 程序维护中的一个基本问题是--缺陷修复总会以（20－50）%的机率引入新的bug。所以整个过程是前进两步，后退一步。
- 巧匠因为他的工具而出名。
- 带来坏消息的人不受欢迎。
- 计划日期是项目经理的工作产物，代表了经协调后的项目整体工作计划，它是合理计划之前的判断。估计日期是最基层经理的工作产物，基层经理对所讨论的工作有着深刻的了解，估计日期代表了在现有资源和已得到了作为先决条件的必要输入（或得到了相应的承诺）的情况下，基层经理对实际实现日期的最佳判断。
- 流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。
- 现实中，流程图被鼓吹的程度远大于它们的实际作用。我从来没有看到过一个有经验的编程人员，在开始编写程序之前，会例行公事地绘制详尽的流程图。在一些要求流程图的组织中，流程图总是事后才补上。一些公司则很自豪地使用工具软件，从代码中生成这个"不可缺少的设计工具"。我认为这种普遍经验并不是令人尴尬和惋惜的对良好实践的偏离（似乎大家只能对它露出窘迫的微笑），相反，它是对技术的良好评判，向我们传授了一些流程图用途方面的知识。
- 程序变动总是不能及时精确地反映在文档中。 我认为相应的解决方案是"合并文件"，即把文档整合到源代码。
- 考虑到流程图方法的落后和高级语言的使用占统治地位，把程序和文档放在一起显然是很合理的。
- 没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
- 那些想看到完美方案的人，其实在心底里就认为它们以前不存在，以后也不可能出现。
- 我认同英国剧作家、侦探小说作者和神学家桃乐丝·赛尔丝看待创造性活动的观点，创造性活动包括（1）概念性结构的形式规格化，（2）使用现实的介质来实现，（3）在实际的使用中，与用户交互5。在软件开发中，我称为"必要（essence）"的部分是构思这些概念上的结构；我称为"次要（accident）"的部分指它的实现过程。
- 在系统工作中所遇到的大多数困难是组织结构上的一些失误征兆。试图为这些现实建模，建立同等复杂的程序，实际上是隐藏，而不是解决这些杂乱无章的情况。
- 我认为系统复杂性是无数细节的函数，这些细节必须精确而且详细地说明--或者是借助某种通用规则，或者是逐一阐述，但决不仅仅是统计说明。仅靠若干人不相干的工作，是不大可能产生足够的一致性，能用通用规律进行精确描述。
- 虽然没有通天大道，但是路就在脚下。
- 我们理解的也好，不理解的也好，描述都应该简短精练。
- 将做事方式调整到追求完美，是学习编程的最困难部分。
- 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
评论
读这本书以后已经过去了一段时间了，书中提出了很多软件开发中遇到的问题，但是解决问题的方法在现实中很难实施，正如作者所说的“在软件开发的过程中，只有适度改进，没有包治百病的银弹”