作者将巴比伦塔失败的原因之一归结于缺乏交流，缺乏组织。而我们能从中得来的教训之一在大型软件开发，要无比重视交流的重要性。本书初版之后四十余年的现在，人们所发明的很多技术和规范很大程度上都是为了加强“交流”，减少不必要的交流，增加交流的效率——团队组织的目的是减少所需的交流和合作的数量。制定规范也是。
正如作者直接在文中以文字形式表达的“交流和交流的结果——组织，是成功的关键”。但我们要谨记交流和组织的技能需要锻炼，相关经验的积累和能力的提高同软件技术本身一样重要，不要因为一时的失败而放弃，也不要因为成绩而固步自封。
对于交流，文档这一工具起着非常大的作用，例如项目经理的基本职责是使每个人都向着相同的方法前进，所以其主要职责是沟通，而不是做决定。因此他需要大量的文档来极大减轻他的负担 。
在设计的过程中，我们要做到自上而下的设计，在设计的每个步骤中，尽可能地使用级别较高的表达方法来表示概念和隐藏细节，直到必要的时候再进一步的细化。文中的这段话让笔者想起SICP中教授们试图传达给学生们的一个屠龙之术——“推迟做出决定的时机，因为只有尽可能地退出做出决定的时机，你之后的行为才不会被当下做出的决定所影响，所阻碍”。而且细节的抑制使得结构上的缺陷更加容易识别。
作者在本章中还详细给出了控制变更的最佳实践——阶段化，定期变更。
- 直到下一次定期发布前都使用快速补丁。
- 而在当前的发布中，其将已经通过测试并进行了文档化的修补措施整合到系统平台中。
另外作者还给出了系统集成测试阶段的最佳实践——一次添加一次构件。我们总是倾向于将所有的构件全部组合到一起再测试