《人月神话》主要讨论的便是人和月之间的关系。并且怎样处理系统开发的预估，正如作者所说“在众多软件项目中，缺乏合理时间进度是造成项目滞后的最重要原因。”
那么这些问题来源于哪里？作者给了明确的答案：
首先，我们对估算技术缺乏有效的研究。过于乐观
第二，我们采用的估算技术隐含的假设人和月可以互换，错误的将进度与工作量相互混淆
第三，由于对自己的估算缺乏信心，软件经理不会持续估算工作。
第四，对进度缺少跟踪，监督
第五，当意识到进度的偏移时，下意识的反应是增加人力。
我们程序员，在创造软件时需要创造性，创造性活动分为三个阶段：构思，实现，交流。1，其作为一个构思，模型，出现在作者的脑海中和时间空间无关。2，在现实的时间和空间中实现他们。3，其余作者的思想相互沟通，从而创作过程得以结束。但由于物理介质和思路中隐含的不完善性，实际实现起来需要花费大量的时间和汗水。
在很大程度上我们的构思是由缺陷的，因此总有bug。因此bug是不可避免的。
成本的确随开发产品的人数和时间不同，有着很大的变化，进度却不是如此。人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话，他暗示者人员数量和时间是可以相互替换的。
某个任务分给参与人员。并且他们之间不需要任何的交流。这在割小麦中是可行的，但在系统编辑中近乎不可能。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。
其中这里在用人来弥补时间的时候存在巨大的问题，沟通所增加的负担由两个部分组成，培训和相互的交流。培训不能分解，主要是相互交流。
软件开发的沟通，交流的工作量非常大，他很快会消耗任务分解所省下来的个人时间，从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
不为系统测试安排足够的时间是一场灾难，因为延迟发生在项目快完成的时候，直到项目的发布日期，才有人发现进度上的问题。因此，坏消息没有任何预兆，很晚才出现在客户和项目经理面前。
我们有两种解决方案：
1， 开发并推行生产率图表，缺陷表，估算规则等等，而整个组织最终会从这些数据的共享上获益。
2， 在基于可靠的基础估算之前，项目经理坚持他们的估计，确信自己的经验和直觉总比从期望派生出的结果要强很多。
Mills建议大型项目的每一个部分由一个团队解决，但是该队伍以类似外科手术的方式组建，而并非一拥而上。有一个人来进行问题的分解，其他人给予她所需要的支持，以提高效率和生产力。
做重要的是首席程序员，副手。
首席程序员：需要极高的天分，十年的经验和应用数学，业务数据处理或其他方面的大量系统和应用知识。
副手：能完成任何一部分工作，但是相对具有较少的经验，只要作用是作为设计的思考者，讨论者，评估人员。
Mills概念的真正关键是“从个人艺术到公共实践”的编程观念转换。她所有的团队成员，展现了所有计算机的运作和产物，并将所有的程序，数据看作是团队的所有物，而非私人财产。