最近阅读了罗森伯格的《梦断代码》，算是近距离观察了十几年前软件开发的状态。这本书是作者对OSAF主持的Chandler项目进行田野调查 而写的一本书。本书是在讲一事，也是在讲百千事；是写一软件，也是在写千百软件。在描述Chandler项目的过程当中亦提出了很多观点，带给我们很多思考。让我们这些软件工程专业的学生对软件开发有了一个更深层次的认知。
在本书第一章，作者为我们介绍了一个布鲁克斯法则：“往已延误的项目里补充人力，只会使其继续延误”。
布鲁克斯曾是IBM的资深程序经理，他亲眼目睹了IBM System/360主机操作系统的打造过程，该系统是当时规模最大的项目。那台巨大而昂贵的大型计算机，本应是后来二十年中生意场上的中流砥柱，但它的孕育和诞生却饱受延误和成本超支之苦，正如布鲁克斯所言，它变成了一个“沥青坑”，一个能粘住大企业的陷阱，哪怕是对于IBM这样孔武有力的公司也不例外。布鲁克斯所在的部门，深受进度落后之困，不断招募新程序员参与项目，如同李将军派遣一个又一个旅团进攻墓园山脊——结果发现后援力量非但没能挽救项目，反而使情况越来越糟。
所以布鲁克斯法则就这样诞生了，听起来既是原则也是悖论：“往已延误的项目里补充人力，只会使其继续延误”。布鲁克斯说软件开发者通常都是乐天派，他们认为每个缺陷都可以迅速被修正，且修正旧缺陷必能减少新缺陷的数量。这种盲目乐观，加上程序员想要取悦主顾，往往进度在一开始的时候就偏离正轨。布鲁克斯发现，在实际的开发中，编程只占项目开发时间的1/6，有一半时间用于测试和修改缺陷。但只有少数项目经理会按照这种思路去安排开发人员的工作时间。
对于软件而言，项目各有差异，工具不断升级，每当团队中加入一个新组员，老组员就得放下手中的工作，帮助新组员进入角色，每位组员都要等待重新分派任务，好让新组员有事情可以做。在你意识到这一切之前，已经远远落后于进度了。在最坏的情况下，这会导致灾难般的延误循环，一种再生性进度灾难。每一次重新安排进度计划，都导致雇佣更多人力，于是又不得不重新安排进度。
制作软件的大量工作受困于“序列约束”，它限制了任务分解的程度：完成某项任务是处理其他任务的先决条件，这与人力投入多少无关。最后布鲁克斯以不同个体程序员生产力的巨大差异来完成对“人月神话”反驳——极好的程序员能在规定时间内完成十倍于普通程序员的工作量，而且完成质量也五倍于普通程序员。若人与人之间的工作效果如此不同，那么衡量标准也无从谈起。
布鲁克斯法则在一定程度上暗示了最理想的发开组规模是一个人。因为这样一个单个开发者就无需为了与同事沟通而停下工作了。虽然在软件历史上一些“孤狼”贡献良多，但是太多软件渐成巨物，仅凭一人之力无法做成。所以编程到最后还是演变成了一种团队努力，一种团队合作。