一个错误就可能让一个项目“死定了”。往往带来不可知因素的时间陷阱。
记录于Bugzilla 中的第44 个缺陷，最初于2003 年1 月19 日登记，描述信息是“ 当修改窗体大小时出现闪烁”。。安德森认为这是个小问题，不过还是应该查实和修正。可直到将近六个月之后的今天，他仍然没能修正。问题不在自己和同事编写的代码上，出错的根源在于一个称作wxWidgets 的软件里面，Chandler 小组采用该软件作为项目的构造块。安德森要么等着wxWidgets的开发者修正代码，要么就得绕过问题所在。
软件项目难以按进度安排实现，这种情况极为常见。在软件开发的世界里，进度延误普遍到人们特意生造出—个委婉词来描述它：slippage（失速）。
软件时间自我扭曲再头尾相接，如同莫比乌斯环。一般令人费解。进度忽而突飞猛进，忽而不知何故驻足道中。在你以为大功即将告成之时，却又山穷水尽， 花上整半年时间，一无所得。
布鲁克斯法则：向已延误的项目中补充人力，只会使其继续延误。
布鲁克斯写道，软件开发者通常都是乐天派，他们认定每个缺陷都可以被迅速修正，且修正旧缺陷必能减少新缺陷的数量。
布鲁克斯发现，在实际开发中，编码只占软件项目开发时间的1/6, 有一半时间用于测试和修正缺陷。但只有少数项目经理会真正按照这种思路来安排开发人员的工作时间。
所谓“人月", 是一种科学管理概念，它假定生产力可被拆分为不连续、无差异、可替换的单元。
布鲁克斯观察到，“只有在任务能分派给许多互相之间无须沟通的工作者时，人和月才是可互换品。
布鲁克斯法则暗示最理想的开发组规模是一个人——无须停下工作与同事沟通的单个开发者。
软件开发过程中，不是人员投入量越大效率越高，往往会适得其反，，只有每一个单独工作的人的工作量，才能用人月这一衡量标准来衡量。所以说在以后的合作开发中，合理的安排人员对项目的开发最为重要。