所有的程序员都是乐观主义者，他们倾向于认为事情会如他们想象的那么顺利，而事实上并非如此。所有的软件项目都倾向于被推迟完成。那种认为大项目只是增加足够的程序员就能顺利完成，已经对于已经推迟的项目，只要增加人手就能按期完成的看法是错误和危险的，因为它假定人和月是可互换的，而其实将工作分割给许多人、培训和程序员之间的交流都需要额外的工作。Brooks提出这样一条定律：给推迟的软件项目增加人手将使得项目更加推迟。
有数据表明：好的程序员与差的程序员的生产力可能相差10倍以上，而且编程经验与编程的优秀度没有直接关联（一名糟糕的程序员不会在编10年程序后就成为优秀的程序员）。所以一个小规模的精锐的团队要比一个大的却有很多平庸的程序员的团队要好得多。一个两人的团队，其中一个作为领导者，通常是最好的使用脑力的方式。书中甚至似乎是玩笑地说：如果准备200人开发一个大项目，如果有25名项目经理，那么让这25人组成开发团队，将其余175解雇掉。但是，对于真正大的系统，小规模的团队开发速度又太慢，难以满足需求。这时，一个主程序员，就像手术团队中只有一名主刀医师的模式是很好的模式。一个团队另外配一名副程序员（与主程序员分享设计，并且代替主程序员于一般程序员、工具制造者、测试人员、语言律师交流）、一名管理员（管理钱、人、机器等）、一名编辑（修改、评价主程序员写的文档），管理员与编辑都配一名秘书。主程序员只与副程序员、管理员和编辑交流，这样就大大减少了主程序员与其他人的交流量。
系统设计中最重要的是概念的完整性。应明白概念的完整性而不是功能的多样性是评价系统好坏的标准。概念上统一的系统更容易建造和测试。要保证概念上的完整性，设计应该由一个人或者观念一致的小规模小组完成。这看似具有贵族主义倾向，却是保证系统概念上的完整性的需要。架构师的角色与军队的统帅很类似，虽然独裁，但是却是必须的。分离建构和实施是建造大工程时保证概念完整性的重要手段。这不是创造性和非创造性工作的分离。事实上，实施过程中同样需要大量创造性的工作。
要保证项目尽快、低成本地完成，架构师与建造者之间尽早和持续的交流很重要。架构师应如何影响实施呢？首先应记住建造者有创造性实施的责任，架构师只是建议，而不是命令。其次，总是建议一种实施方案，但是永远准备接受其它同样好或者更好的方案。应无声和私人地给予这些建议，同时应准备对别人建议的好的方案给予赞扬和肯定。还有应能听取建造者对于架构的改进意见。第二个系统是一个设计的最危险的系统：最常见的倾向是过度设计。系统可能功能过于丰富，实际上只有半数的功能是常用的。为了避免二次系统效应，可以让一个设计师同时设计二个系统，另外，可以为每一功能付予一个优先值，这样如果时间不允许，可以去掉优先级低的功能。
在工程实施过程中，每周有架构师、软件和硬件实施者代表、市场计划者组成的小组例会是非常有用的。总架构师主持会议，如果对于一个问题达不成一致意见，由总架构师决定。会议应有确定的书面的讨论议案。另外，架构师应随时准备回答实施者对于设计的问题。实施者在有疑惑时不应猜测架构师的意图，而应询问清楚。询问的电话记录应集中起来，分发给所有实施者手中。项目经理的最好的朋友是他每天的敌人：独立的产品测试组织。