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