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