人月神话的英文是 《Man-Month Mythical》，人月其实是软件工程管理工程量的单位，一个人每月的工作量，其实是想说明是使用人月的方式来估算大型项目是不靠谱的，只是一个神话的方式。而作者Frederick P.Brooks,Brooks被认为是“IBM 360系统之父”，他担任了360系统的项目经理，以及360操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans和Erich Bloch在1985年荣获了美国国家技术奖。早期，Brooks曾担任IBM Stretch和Harvest计算机的体系结构师。
开篇以焦油坑引出，焦油坑，让陷入其中的猛兽越挣扎越是难以挣脱束缚，陷入坑底。而大型的系统开发就是这样的焦油坑，各种问题纠结在一起，让人越陷越深，没有办法看清事情的本质。在其中，不要做一个纯粹的乐观者。《人月神话》中什么是人月？是使用的在估计和进度安排中的工作量单位。作者认为用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。 人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之 间不需要相互的交流。
“孕育一个生命需要十月怀胎，所以不管有多少个母亲，时间都是一样的”，阐明增加人手来弥补项目被拖延的进度，有时候是不现实的。从这里开始慢慢透漏出，人月是神话的韵味。
保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型。具体的实现人员可以细化概念，
很少有人类的活动要力求完美，程序却像是神的咒语，以一个个音节、一个个停顿层层构建出前所未有或已经存在的事物。
但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东西，导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。这就是外科手术式的开发队伍。
团队不是一拥而上，而是以外科手术方式来操刀。
打个比方就像一个主治医师操刀对问题进行分解，而其他成员提供各种支持。主导手术的码农就这样成长为传奇中的人物。
想想此书成熟的年代，那些靠敲汇编语言，在狭小的屏幕，纸带存储，小的可怜的内存完成复杂工作的前辈。
想想那些动辄就是议论重新设计语言，实现编译器的前辈。而如今有了各种各样的工具，如今的我们站在前辈们的肩膀上。
作者风淡云轻的写此书。堪称举重若轻。
现代程序员的软硬件工具更加强大，有更多的乐趣，比以前更少的苦恼和麻烦。
实在应该珍惜。