如果将制订功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来，那么有什么样的准则和机制来约束结构师的创造性热情呢？
  基本回答是结构师和建筑人员之间彻底、仔细和谐的交流。另外，还有很多值得关注的、更细致的答案

结构师的交互准则和机制

  面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法——挑战估算的结果。后者是固有的主观感性反应。此时，结构师是在向开发人员的做事方式提出挑战。想要成功，结构师必须

‰ 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配

‰ 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法

‰ 对上述的建议保持低调和平静；

‰ 准备放弃坚持所作的改进建议；

  一般开发人员会反对体系结构上的修改建议。通常他是对的——当正在实现产品时，
某些特性的修改会造成意料不到的成本开销。

自律——开发第二个系统所带来的后果

  TESTRAN 调试程序是这个趋势的另一个例子。它在批调试程序中是出类拔萃的，配备了真正优雅的快照和内存信息转储功能。它使用了控制段的概念和卓越的生成技术，从而不需要重新编译或解释，就能实现选择性跟踪和快照。这种 709 共享操作系统 3中魔术般的概念得到了广泛的使用。

  结构师如何避免画蛇添足——开发第二个系统所引起的后果（second-system effect）？是的，他无法跳过二次系统。但他可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。

  一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进，功能 x 不超过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导，在物理实现期间充当指南和
对所有人的警示。