项目缺陷列表：不确定的因素太多，你所需要的时间取决于他人所花的时间；黑洞式缺陷——即无法确定修正所需时长的时间——在Bugzilla中应该用特别警示词标记出来。
如何安排多个程序员真正完成开发任务。无论是整天不断地往Buzilla里添加条目，还是不停开会推动进度，软件时间始终像是一条大蛇，而且似乎无法征服。软件项目难以按进度安排实现，这种情况极为常见，而且为众人所宽容。在软件开发世界里,进度延误普遍到人们特意生造出一-个委婉词来描述它: slippage(失速)。每个领域都存在延误现象。司法诉讼程序蜗行般的进度尽人皆知;建筑承包商要是按期完工，就会招来怀疑的目光。然而，软件时间自我扭曲再头尾相接，如同莫比乌斯环般令人费解。进度忽而突飞猛进，忽而不知何故驻足道中。在你以为大功即将告成之时，却又山穷水尽，花上整半年时间，一无所得。感觉像是这样:在软件开发项目中暗藏有一条线缆。线缆系紧时，进展迅速。线缆断开时，工作停滞。局中人上下求索，想找到断点所在;观局者先是试图指点迷津，尔后耐心尽失，猛批一通。
对软件时间导致的问题产生的诊断：布鲁克斯法则就这样产生了,听起来既是原则也是悖论:往已延误的项目中补充人力，只会使其继续延误。布鲁克斯观察到，"只有在任务能分派给许多互相之间无须沟通的工作者时，人和月才是可互换品。”对于软件而言，项目各有差异、工具不断升级，每当团队中加入一个新组员，老组员就得放下手边的工作，帮助新组员进入角色，每位组员都要等待重新分派任务，好让新组员有事可做。在你意识到这-切之前， 已经远远落后于进度了。布鲁克斯发现，在最坏的情况下,这会导致灾难般的延误循环，一种“再生性进度灾难"。每次重新安排进度计划，都导致雇用更多人力，于是又不得不重新安排进度。布鲁克斯对此心存恐惧:疯狂在兹。
“好的软件开发工作始于打造开发者本人。”只要是做某种取悦自己或满足己需的东西，程序员就会动力十足，努力做到最好。"好程序员懂得写什么。卓越的程序员懂得改写(并复用)什么。”若能取之于现有，程序员决不肯创之于本无。瑞蒙德指出其中的两个要诀:其一，低成本、广泛地接入像互联网那样的网络，让开发者之间能建立迅速、可信的沟通渠道，存储可被开放访问的共享知识和代码池;其二，围绕一种领导方式一如托瓦 茨那样的方式一形 成合作团队的良好风气，欢迎新人进入、鼓励成员做出贡献，同时尽可能增加合格成员。瑞蒙德写道，一旦具备这些条件，就能彻底改进在程序中寻找和修正缺陷的过程。与其害怕竞争对手窃取代码而秘不示人，不如将其展现给全世界，邀请同道加入。而且，假使你独具魅力，且懂得如何管理一群开发者，或许还能组织起自循环的集智体系。愉悦是金,"艾瑞克●瑞蒙德写道。“开源的成功告诉我们，对于创造性工作，玩耍是最经济有效的模式。”