就增加人手这个解决方法来看，首先得要解决沟通问题。沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解，因此这部分增加的工作量随人员的数量呈线性变化 。 因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
书中所说的一个项目的估算是十分重要的。在开始一个项目的时候，我们总会对这个项目完成设定一个预估的时间，为了在指定时间，完成项目，团队只能无限突破各种的困难，并尽可能地提高工作效率。在阐述了第一个谬误后，作者又引出了第二个谬误“人月”。从本书的题目就可以知道，“人月”一定是本书的重中之重。成本的确和开发产品的人数和时间有关，但是进度却不是这样。我现在明白“人月”中的月指的是工程项目中的花费时间。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且 他们 之间不需要 相 互的交流。 这在割小麦或收获棉花的工作中是可行的；而在系统编程中近乎不可能。所以说，在系统编程中，人数与时间地互换是一种荒谬地观点。作者举出了一个十分浅显易懂地例子——无论多少个母亲，孕育一个生命都需要十个月。以为孕育生命这个进程来说，是绝对不可以分割给别人地，由于测试调试地次序问题，大部分项目都具有这个特点。
说实话，读了今天的人月神话的相关内容之后，我更加的理解主任对我们的严格要求，以及那种苛刻。在大二上半年java这门课程中，主任就会对我们进行时间阶段性的有限时间测试，还有无时间设置的极限测试。时间阶段测试培养的是我们这项目的时间要求，而极限测试，则培养了我们学习代码的能力和耐心。
这一章引发了一个具有实际性的问题：如何在有意义的进度安排内创建大型的系统？大量的技术人员一涌而至还是则少数的精炼者独当一面却忽略了项目的截止时间？针对这种现象，又如何的选择？如何的解决这一矛盾，从而保证最高效，最低成本的完成？
Mills的给出了明确的答复——明确的分工，手术团队大大小小的成员各司其职，分工明确。Mills建议大型项目分为小部分，每个小部分由一个团队解决，而团队则是以外科手术团队的方式来构建。外科手术团队因为是由一个人来完成问题的分解，其他人给予必要的支持的方式来运作。