9.8 精炼、充分和快速的程序往往是战略性突破的结果，而不仅仅是技巧上的提高。战略上的突破常来自于对数据或者表的重新表达。数据的表现形式是编程的根本。
提纲挈领
10.1 对于软件项目，目标、用户手册、内部文档、进度、预算、组织结构图和工作空间分配是关键文档。
10.2 即使是小型项目，项目经理也应该在项目早期对上述一系列文档进行规范化。
10.3 每个文档本身就可以作为检查列表或者数据库。
10.4 项目经理的主要日常工作是沟通，而不是做出决定，文档使各项计划和决策在整个团队范围内得到交流。
未雨绸缪
11.1 第一个开发的系统对于大多数项目来说并不合用，它可能太慢、太大难以使用。
11.2 系统的丢弃和重新设计可以一步完成，也可以一起实现，但必须完成。
11.3 为舍弃而计划，无论如何，你一定要这么做。
11.4 开发人员交付的是用户满意程度，而不仅仅是实际的产品。
11.5 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
11.6 为变更计划软件产品的技术，特别是拥有最细致的模块接口文档的结构化编程广为人知。
11.7 为变更计划组织架构：为变更组建团队比为变更进行设计更加困难。
11.8 前进一步，后退两步：程序维护主要由各种变更组成，如修复设计缺陷，新增功能，或者使用环境或配置变换引起的调整。
11.9 对于一个广泛使用的程序，其维护成本通常是开发成本的40% 或更多。
11.10 缺陷修复总会以20%~30%的几率引入新的bug。
11.11 实现设计的人员越少，接口越少，产生的错误也就越少。
11.12 前进一步，后退一步：系统熵随时间增加，所有修改都倾向于破坏系统的架构，增加系统的混乱程度(熵)。
干将莫邪
12.1 项目经理应该制定一套策略，为通用工具的开发分配资源，同时，也必须意识到专业工具的需求。
12.2 需要安排一名系统程序员，保证机器上的标准软件是及时更新和实时可用的。
12.3 目标机器的使用需求量是一种特殊曲线：开始使用率非常低，突然出现爆发性增长，最后趋于平缓。
12.4 在编制程序的项目中，节省最大工作量的工具可能是文本编辑系统。
整体部分
13.1 许多失败完全源于哪些产品未经确定以的地方。
13.2 在编码前，规格说明必须提高给外部测试小组，以详细检查说明的完整性和明确性。
13.3 好的自上而下的设计从四个方面避免了bug。
13.4 有时必须回退，推翻顶层设计，重新开始。