人月。成本的确随开发产品的人数和时间的不同， 有着很大的变化， 进度却不是如此。 因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之
间不需要相互的交流
。 这在割小麦或收获棉花的工作中是可行的；而在系统编程
中近乎不可能 。
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助
。无论多少个母亲， 孕育一个生命都需要十个月。 由于调试、 测试的次序特性， 许多软件都具有这种
特征。
对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。 因此， 相同人月的前提下， 采用增加人手来减少时间得到的最好情况， 也比未
调整前要差一些 。沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术、 项目目标以及总体策略上的培训。 这种培训不能分解， 因此这部分增加的工作量随人员的数量
呈线性变化
。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别和其他部分单独协作，
则工作量按照
n(n-1)/2
递增。一对一交流的情况下，三个人的工作量是两个人的三倍，四个人则是两个人的六倍。 而对于需要在三四个人之间召开会议、 进行协商、 一同解决的问题，情况会更加恶劣。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作
用。
因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，
实际上是延长了，而不是缩短了时间进度。