第五章画足添蛇（THE SECOND-SYSTEM EFFECT）
架构设计师面对过高的估算的两个选择：
削减设计向开发人员建议用成本更低的实现方法
第2个选择若要成功，架构设计师必须：
这边所谓的「第二系统效应」，是指一个人在设计系统的时候，，第二个设计出来的系统，是最危险的一个。这是因为在第一个系统的时候，由于自知不够熟系，所以会比较节制、也会比较简单清爽；
但是设计第二个系统的时候，却很容易把在做第一个系统时的所有构想，都加挂到这个自认已经熟系的第二个系统上，所以第二个系统很容易有过度设计的问题。再之后的系统（第三个及以后），由于会和之前的经验做对比、相互印证，所以也就比较不会有问题了～
如何避免这个问题？ 以设计师来说：
主要就是要靠「自律」了～同时，也要了解这个第二系统效应的原因，并提醒自己避免设计出不相关的功能、或是做出违反原先架设与目的的功能。为每个小功能分配一个值：每次改进，功能x不超过m子节的内存和n微秒
项目经理来说：
要采用至少两个以上系统设计经验的架构设计老手的决定。保持对特殊诱惑的警觉。第六章贯彻执行（PASSING THE WORD）
这一章主要的主题，是着重于整个意思的传达，以及精确的描述；因为唯有在所有参与专桉的人都能够明确无误地了解整个架构、规范、介面等等必须要沟通的东西时，才有可能真正完全按照计画来进行。而针对了这个主题，作者也在本章内提出了许多建议：
书面规则／手册
不仅要描述使用者将会看到的所有细节，也要避免描述使用者看不到的东西。手册的风格应该要准确、完整、详细，各项定义与要点必须要保持一致；而为了做到这点，所以书面化的工作应该要由一到两个个人来主笔。
形式化定义
－设计实现也可以当作正式定义，例如用模拟器来当作定义。
这样的好处是只要实际测试一下，就知道他应该有什么结果；但是相对的，也有可能因此会因为这个实现，而导致定义的过度描述，而影响到之后实现的弹性。
开会
1周例会
2年度大会
时间较长（两周）用来处理细琐事务、公开讨论，让大家发洩不满。
多重实现
一开始就开发两个以上的实现产品，可以避免根据错误的实现去修改规格，将有助于维持架构定义的纯净与严谨。
电话日志
允许实现人员直接询问架构设计师（电话、或者电子邮件），而不要自行解释。 而这些询问都应该被记录下来、整理后分发给所有实现人员和使用者。
产品测试
独立的产品测试小组是必须的。
第七章为什么巴比伦塔会失败？（WHY DID THE TOWER OF BABEL FAIL?）
巴别塔失败的原因是什麽？作者认为是「沟通」，以及随之而来的「组织」；
怎样沟通？
使用工作手册的原因？
规范了专桉进行过程中即将产生的文件，并可以用来保存技术方面的说明；而为了让工作手册可以真正有用，他需要被尽早、小心地设计出来。控制信息发布：确保需要资讯的人都能够在适当的地方取得资讯的方法，每一个团队的成员都应该要可以看到工作手册的全部文件内容（没有必要所有人都要看完所有的东西，部分的细节应该要被封装（encapsulated）起来，不属于自己的东西，就不必、也不被允许去看裡面的细节，只需要看到简介就够了。）（对备忘录编号，建立树状索引结构）；同时也要确保文件的内容有被持续地更新，并且保有改版的纪录，让看的人知道版本间的修改状况。在以往这点可能很难做到，但是现在网路、电子化文件都很发达了，要做到基本上问题并不大。
大型编程项目的组织架构
「组织」的目的：减少沟通量。
人力配置专业分工
传统的树状结构组织主要是源自于权力的责任结构，但是以沟通结构来说，则是会是网状的，这样才可以避免沟通不良的问题。
树状编程队伍：
2负责着急小组、分派工作、规划时程、争取掌握资源，以及和别的小组沟通，并且对时程负责； 3则是构思、分割系统，切割系统的外观和内构，维持整个设计的和谐与整体性。
作者认为，这两种脚色的搭配方法有三种：
当你能飞的时候就不要放弃飞
