《人月神话》内容源于作者Brooks在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验。
这本书是按照整个计算机软件系统的开发流程一步一步来写的，展现了整个系统的开发目的，过程，以及消亡，不可实现的原因。
这本书作为软件工程学习的参考背景书目，对软件工程的学习有很大帮助。
首先，开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。
成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：
某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
调试、测试的次序特性，许多软件都具有这种特征。
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，
实际上是延长了，而不是缩短了时间进度。
对于编程：
有其乐趣和苦恼。创建事物的快乐，开发对其他人有用的东西的乐趣，将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力，面对不重复的任务，不间断学习的乐趣，权威不等同于责任实际情况看起来要比这一点好一些；真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外人们通常期望项目在接近结束时。
我有一个同学的网名就叫我编程我快乐。
开发一个软件：
我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。
文档的重要性：
每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。
良好的工作手册和组织架构可以开发出更加符合用户的需求：
就像我们的软件工程项目一样，需要有用户，用户需要使用他时，需要参考一些东西来实现么，而不能每个用户都有专业的指导老师，这就是用户手册的重要性。
项目总结:
这本是就是作者在开发一个耗资巨大的软件失败后按照记忆写的一本书，可以说成是一个巨大的项目总结。项目总结暴露出整个项目的整体，整个开发过程中出现的问题。可以为以后的工作减少许多不必要的损失。。。总结可以使人深思，查明自己的能力，知道自己的地位。这就是总结。