聚沙成塔，集腋成裘。

- 奥维德

Adde parvum parvo magnus acervus erit. [Add little to little and there will be a big pile.]

- OVID

Chapter 5. The Second-System Effect

如果将制订功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来，那么有什么样的准则和机制来约束结构师的创造性热情（inventive enthusiasm）呢？

If one separates responsibility for functional specification from responsibility for building a fast, cheap product, what discipline bounds the architect's inventive enthusiasm?

基本回答是结构师和建筑人员之间彻底、仔细和谐的交流。另外，还有很多值得关注的、更细致的答案。

The fundamental answer is thoroughgoing, careful, and sympathetic communication between architect and builder. Nevertheless there are finer-grained answers that deserve attention.

结构师的交互准则和机制（Interactive Discipline for the Architect）

建筑行业的结构设计师使用估算技术来编制预算，该估算技术会由后续的承包商报价来验证和修正。承包商的报价总会超过预算。接下来，设计师会重新改进他的预算或修订设计，调整到下一期工程。他也可能会向承包商建议，使用更加便宜的方法来实现设计。

The architect of a building works against a budget, using estimating techniques that are later confirmed or corrected by the contractors' bids. It often happens that all the bids exceed the budget. The architect then revises his estimating technique upward and his design downward for another iteration. He may perhaps suggest to the contractors ways to implement his design more cheaply than they had devised.

类似的过程也支配着计算机系统和计算机编程系统的结构师。相比之下，他有能在设计早期从承包商处得到报价的优势，几乎是只要他询问，就能得到答案。他的不利之处常常是只有一个承包商，后者可以增高或降低前者的估计，来反映对设计的好恶。实际情况中，尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

An analogous process governs the architect of a computer system or a programming system. He has, however, the advantage of getting bids from the contractor at many early points in his design, almost any time he asks for them. He usually has the disadvantage of working with only one contractor, who can raise or lower his estimates to reflect his pleasure with the design. In practice, early and continuous communication can give the architect good cost readings and the builder confidence in the design without blurring the clear division of responsibilities.

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

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

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

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

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

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

The architect has two possible answers when confronted with an estimate that is too high: cut the design or challenge the estimate by suggesting cheaper implementations. This latter is inherently an emotion-generating activity. The architect is now challenging the builder's way of doing the builder's job. For it to be successful, the architect must

• remember that the builder has the inventive and creative responsibility for the implementation; so the architect suggests, not dictates;

• always be prepared to suggest a way of implementing anything he specifies, and be prepared to accept any other way that meets the objectives as well;

• deal quietly and privately in such suggestions;

• be ready to forego credit for suggested improvements.

Normally the builder will counter by suggesting changes to the architecture. Often he is right—some minor feature may have unexpectedly large costs when the implementation is worked out.

自律：开发第二个系统所带来的后果（Self-Discipline—The Second-System Effect）

在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。

An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.

在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为"下一个"项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。

As he designs the first work, frill after frill（褶边;虚饰） and embellishment（[ɪmˈbelɪʃmənt]，润色） after embellishment occur to him. These get stored away to be used "next time." Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。

This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable.

一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法，它们曾在第一个系统中被小心谨慎地推迟了。结果如同Ovid所述，是一个"大馅饼"。例如，后来被嵌入到7090的IBM 709系统，709是对非常成功和简洁的704系统进行升级的二次开发项目。709的操作集合被设计得如此丰富和充沛，以至于只有一半操作被常规使用。

The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a "big pile." For example, consider the IBM 709 architecture, later embodied in the 7090. This is an upgrade, a second system for the very successful and clean 704. The operation set is so rich and profuse that only about half of it was regularly used.

让我们来看看更严重的例子——Stretch计算机的结构（architecture）、设计实现（implementation）、甚至物理实现（realization），它非常具有代表性。如果Strachey在评审时所述：

Consider as a stronger case the architecture, implementation, and even the realization of the Stretch computer, an outlet for the pent-up（压抑） inventive desires of many people, and a second system for most of them. As Strachey says in a review:

对于Stretch系统，我的印象是从某种角度而言，它是一个产品线的终结。如同早期的计算机程序一样，它极富有创造性，极端复杂，非常高效。但不知为什么，同时也感觉到粗糙、浪费、不优雅，以及让人觉得必定存在某种更好的方法1。

I get the impression that Stretch is in some way the end of one line of development. Like some early computer programs it is immensely ingenious（创造性）, immensely complicated（极端复杂）, and extremely effective（非常高效）, but somehow at the same time crude, wasteful, and inelegant（粗糙、浪费、不优雅）, and one feels that there must be a better way of doing things.[1]

操作系统360对于大多数设计者来说，是第二个系统。它的设计小组成员来自1410-7010磁盘操作系统、Stretch操作系统、Mercury实时系统项目和7090的IBSYS。几乎没有人有两个以上早期操作系统的经验2。因此，OS/360是典型的第二次开发（second-system effect）的例子，是软件行业的Stretch系统。Strachey的赞誉和批评可以毫无更改地应用在其中。

Operating System/360 was the second system for most of its designers. Groups of its designers came from building the 1410-7010 disk operating system, the Stretch operating system, the Project Mercury real-time system, and IBSYS for the 7090. Hardly anyone had experience with two previous operating systems.[2] So OS/360 is a prime example of the second-system effect, a Stretch of the software art to which both the commendations and the reproaches of Strachey's critique apply unchanged.

例如，OS/360开发了26字节的常驻日期翻转例程来正确地处理闰年的12月31日的问题，其实它完全可以留给操作员来完成。

For example, OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is Day 366). That might have been left to the operator.

开发第二个系统所引起的后果（second-system effect）与纯粹的功能修饰和增强明显不同，也就是说存在对某些技术进行细化、精炼的趋势。由于基本系统设想发生了变化，这些技术已经显得落后。OS/360中有很多这样的例子。

The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions. OS/360 has many examples of this.

例如，链接编辑器的设计，它用来对分别编译后的程序进行装载，解决它们之间的交叉引用。除了这些基本的功能，它还支持程序的覆盖（overlay）。这是所有实现的覆盖服务程序中最好的一种。它允许链接时在外部完成覆盖结构，而无需在源代码中进行设计。它还允许在运行时刻改变覆盖，而不必重新编译。它配备了丰富的实用选项和各种功能。某种意义上，它是若干年静态覆盖技术开发的顶峰。

Consider the linkage editor, designed to load separately-compiled programs and resolve their cross-references. Beyond this basic function it also handles program overlays. It is one of the finest overlay facilities ever built. It allows overlay structuring to be done externally, at linkage time, without being designed into the source code. It allows the overlay structure to be changed from run to run without recompilation. It furnishes a rich variety of useful options and facilities. In a sense it is the culmination of years of development of static overlay technique.

然而，它同时也是最后和最优秀的恐龙，因为它属于一个基本运行方式为多道程序，以动态内核分配为基础的系统，这直接与静态覆盖的概念相冲突。如果我们把投入在覆盖管理上的工作量，用在提高动态内核分配和动态交叉引用的性能上，那么系统将会运行得多么好啊！

Yet it is also the last and finest of the dinosaurs, for it belongs to a system in which multiprogramming is the normal mode and dynamic core allocation the basic assumption. This is in direct conflict with the notion of using static overlays. How much better the system would work if the efforts devoted to overlay management had been spent on making the dynamic core allocation and the dynamic cross-referencing facilities really fast!

另外，链接编辑器需要如此大的空间，而且它本身就包含了很多链接库，以至于即使在不使用覆盖管理功能，仅仅使用链接功能的时候，它也比绝大多数系统的编译程序还要慢。具有讽刺意味（irony）的是，链接程序的目的是为了避免重新编译。这种情况就像一个挺着大肚子的节食者一样，直到系统的思想已经十分优越时，才开始对原有技术进行细化和精炼。

Furthermore, the linkage editor requires so much space and itself contains many overlays that even when it is used just for linkage without overlay management, it is slower than most of the system compilers. The irony of this is that the purpose of the linker is to avoid recompilation. Like a skater whose stomach gets ahead of his feet, refinement proceeded until the system assumptions had been quite outrun.

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

The TESTRAN debugging facility is another example of this tendency. It is the culmination of batch debugging facilities, furnishing truly elegant snapshot and core dump capabilities. It uses the control section concept and an ingenious generator technique to allow selective tracing and snapshotting without interpretive overhead or recompilation. The imaginative concepts of the Share Operating System[3] for the 709 have been brought to full bloom.

但同时，整个无需重编译的批调试概念变得落伍了。使用语言解释器和增量编译器的交互式计算系统，向它提出了最根本的挑战。即使是在批处理系统中，快速编译/慢速执行编译器的出现，也使源代码级别调试和快照技术成为优先选择的技术。如果在构建和优化交互式和快速编译程序之前，就已经着手TESTRAN的开发，那么系统将是多么的优秀啊！

Meanwhile, the whole notion of batch debugging without recompilation was becoming obsolete. Interactive computing systems, using language interpreters or incremental compilers have provided the most fundamental challenge. But even in batch systems, the appearance of fast-compile/slow-execute compilers has made source-level debugging and snapshotting the preferred technique. How much better the system would have been if the TESTRAN effort had been devoted instead to building the interactive and fast-compile facilities earlier and better!

还有另外一个例子是调度程序。OS/360的调度程序是非常杰出的，它提供了管理固定批作业的杰出功能。从真正意义上讲，该调度程序是作为1410－7010磁盘操作系统后续的二次系统，经过了精炼、改进和增强。它是除了输入－输出以外的非多道程序批处理系统，是一种主要用于商业应用的系统。但是，它对OS/360的远程任务项、多道程序、永久驻留交互式子系统，几乎完全没有影响和帮助。实际上，OS/360调度程序的设计使它们变得更加困难。

Yet another example is the scheduler, which provides truly excellent facilities for managing a fixed-batch job stream. In a real sense, this scheduler is the refined, improved, and embellished（增强） second system succeeding the 1410-7010 Disk Operating System, a batch system unmultiprogrammed except for input-output and intended chiefly for business applications. As such, the OS/360 scheduler is good. But it is almost totally uninfluenced by the OS/360 needs of remote job entry, multiprogramming, and permanently resident interactive subsystems. Indeed, the scheduler's design makes these hard.

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

How does the architect avoid the second-system effect? Well, obviously he can't skip his second system. But he can be conscious of the peculiar hazards of that system（系统的特殊危险）, and exert extra self-discipline to avoid functional ornamentation（ [ˌɔːrnəmenˈteɪʃn] ，装饰） and to avoid extrapolation（外延） of functions that are obviated（排除） by changes in assumptions and purposes.

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

A discipline that will open an architect's eyes is to assign each little function a value: capability x is worth not more than m bytes of memory and n microseconds per invocation（每次改进）. These values will guide initial decisions and serve during implementation as a guide and warning to all.

项目经理如何避免画蛇添足（second-system effect）？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

How does the project manager avoid the second-system effect? By insisting on a senior architect who has at least two systems under his belt. Too, by staying aware of the special temptations, he can ask the right questions to ensure that the philosophical concepts and objectives are fully reflected in the detailed design.

Chapter 6 Ref：

1. Neustadt, R. E., Presidential Power. New York: Wiley, 1960, Chapter 2.

2. Backus, J. W., "The syntax and semantics of the proposed international algebraic language." Proc. Intl. Conf. Inf. Proc. UNESCO, Paris, 1959, published by R. Oldenbourg, Munich, and Butterworth, London. Besides this, a whole collection of papers on the subject is contained in T. B. Steel, Jr. (ed.), Formal Language Description Languages for Computer Programming. Amsterdam: North Holland, (1966).

3. Lucas, P., and K. Walk, "On the formal description of PL/I," Annual Review in Automatic Programming Language. New York: Wiley, 1962, Chapter 2, p. 2.

4. Iverson, K. E., A Programming Language. New York: Wiley, 1962, Chapter 2.

5. Falkoff, A. D., K. E. Iverson, E. H. Sussenguth, "A formal description of System/360," IBM Systems Journal, 3, 3 (1964), pp. 198–261.

6. Bell, C. G., and A. Newell, Computer Structures. New York: McGraw-Hill, 1970, pp. 120–136, 517–541.

7. Bell, C. G., and A. Newell, Computer Structures. New York: McGraw-Hill, 1970, pp. 120–136, 517–541.

8. Bell, C. G., private communication.

关于《人月神话》

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验，该项目堪称软件开发项目管理的典范。

Freder ick P.Brooks，Jr.（1931年4月19日 - 2022年11月17日 ）曾荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。

Brooks博士是北卡罗莱纳大学KENAN-FLAGLER商学院的计算机科学教授。他被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献，他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖（National Medal of Technology）。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。

【更多阅读】

1. 《人月神话》（The Mythical Man-Month）4概念一致性：专制、民主和系统设计(System Design）

2. 《人月神话》（The Mythical Man-Month）3 外科手术队伍（The Surgical Team）

3. 《人月神话（The Mythical Man-Month）》2人和月可以互换吗？人月神话存在吗？

4. 《人月神话（The Mythical Man-Month）》1 看清问题的本质：如果我们想解决问题，就必须试图先去理解它

5. 悼念《人月神话》作者 Fred Brooks

6. 【图文详解】一文全面彻底搞懂HBase、LevelDB、RocksDB等NoSQL背后的存储原理：LSM-tree日志结构合并树

7. 在平时的工作中如何体现你的技术深度？

8. Redis 作者 Antirez 讲如何实现分布式锁？Redis 实现分布式锁天然的缺陷分析&Redis分布式锁的正确使用姿势！

9. 程序员职业生涯系列：关于技术能力的思考与总结
   

10. 十年技术进阶路:让我明白了三件要事。关于如何做好技术 Team Leader？如何提升管理业务技术水平?（10000字长文）
    

11. 当你工作几年就会明白，以下几个任何一个都可以超过90%程序员

12. 编程语言：类型系统的本质

13. 软件架构设计的核心：抽象与模型、“战略编程”

14. 【图文详解】深入理解 Hbase 架构  Deep Into HBase Architecture

15. HBase 架构详解及读写流程原理剖析

16. HDFS 底层交互原理，看这篇就够了！

17. MySQL 体系架构简介

18. 一文看懂MySQL的异步复制、全同步复制与半同步复制

19. 【史上最全】MySQL各种锁详解：一文搞懂MySQL的各种锁