实践是最好的老师。

- PUBILIUS

实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。

- 《穷理查年鉴》

Practice is the best of all instructors.

- PUBILIUS

Experience is a dear teacher, but fools will learn at no other.

- POOR RICHARD'S ALMANAC

系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？

先前，我推荐了用于计划进度(1/3)、编码(1/6)、构件测试(1/4)和系统测试(1/4)的比率。

How long will a system programming job take? How much effort will be required? How does one estimate?

I have earlier suggested ratios that seem to apply to planning time, coding, component test, and system test. 

首先，需要指出的是，仅仅通过对编码部分的估计，然后应用上述比率，是无法得到对整个任务的估计的。编码大约只占了问题的六分之一左右，编码估计或者比率的错误可能会导致不合理的荒谬结果。

First, one must say that one does not estimate the entire task by estimating the coding portion only and then applying the ratios. The coding is only one-sixth or so of the problem, and errors in its estimate or in the ratios could lead to ridiculous results.

第二，必须声明的是，构建独立小型程序的数据不适用于编程系统产品。对规模平均为3200指令的程序，如Sackman、Erikson和Grant的报告中所述，大约单个的程序员所需要的编码和调试时间为178个小时，由此可以外推得到每年35,800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的四分之一，相应推断出的生产率几乎是每年80,000代码行1。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此，上述小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类可以在3分钟之内跑完1英里的结论一样。

Second, one must say that data for building isolated small programs are not applicable to programming systems products. For a program averaging about 3200 words, for example, Sackman, Erikson, and Grant report an average code-plus-debug time of about 178 hours for a single programmer, a figure which would extrapolate to give an annual productivity of 35,800 statements per year. A program half that size took less than one-fourth as long, and extrapolated productivity is almost 80,000 statements per year.[1] Planning, documentation, testing, system integration, and training times must be added. The linear extrapolation of such sprint figures is meaningless. Extrapolation of times for the hundred-yard dash shows that a man can run a mile in under three minutes.

在将上述观点抛开之前，尽管不是为了进行严格的比较，我们仍然可以留意到一些事情。即使在不考虑相互交流沟通，开发人员仅仅回顾自己以前工作的情况下，这些数字仍然显示出工作量是规模的幂函数。

Before dismissing them, however, let us note that these numbers, although not for strictly comparable problems, suggest that effort goes as a power of size even when no communication is involved except that of a man with his memories.

图8.1讲述了这个悲惨的故事。它阐述了Nanus和Farr2在System Development Corporation公司所做研究，结果表明该指数为1.5，即，

Figure 8.1 tells the sad story. It illustrates results reported from a study done by Nanus and Farr[2] at System Development Corporation. This shows an exponent of 1.5; that is,

工作量 ＝ （常数）×（指令的数量）^1.5【工作量随着指令的指数级增长】

注释: incomplete－未终结的

图8.1：编程工作量是程序规模的函数

Weinwurm3的SDC研究报告同样显示出指数接近于1.5。

现在已经有了一些关于编程人员生产率的研究，提出了很多估计的技术。Morin对所发布的数据进行了一些调查研究4。这里仅仅给出了若干特别突出的条目。

Another SDC study reported by Weinwurm[3] also shows an exponent near 1.5.

A few studies on programmer productivity have been made, and several estimating techniques have been proposed. Morin has prepared a survey of the published data.[4] Here I shall give only a few items that seem especially illuminating.

Portman的数据（Portman's Data）

曼彻斯特Computer Equipment Organization（Northwest）的ICL软件部门的经理Charles Portman，提出了另一种有用的个人观点5。

他发现他的编程队伍落后进度大约1/2，每项工作花费的时间大约是估计的两倍。这些估计通常是非常仔细的，由很多富有经验的团队完成。他们对PERT图上数百个子任务估算过（用人小时作单位）。当偏移出现时，他要求他们仔细地保存所使用时间的日志。日志显示事实上他的团队仅用了百分之五十的工作周，来进行实际的编程和调试，估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时间、高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等。简言之，项目估算对每个人年的技术工作时间数量做出了不现实的假设。我个人的经验也在相当程度上证实了他的结论6。

Charles Portman, manager of ICL's Software Division, Computer Equipment Organization (Northwest) at Manchester, offers another useful personal insight.[5]

He found his programming teams missing schedules by about one-half—each job was taking approximately twice as long as estimated. The estimates were very careful, done by experienced teams estimating man-hours for several hundred subtasks on a PERT chart. When the slippage pattern appeared, he asked them to keep careful daily logs of time usage. These showed that the estimating error could be entirely accounted for by the fact that his teams were only realizing 50 percent of the working week as actual programming and debugging time. Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest. In short, the estimates made an unrealistic assumption about the number of technical work hours per man-year. My own experience quite confirms his conclusion.[6]

Aron的数据（Aron's Data）

Joel Aron，IBM在马里兰州盖兹堡的系统技术主管，在他所工作过的9个大型项目（简要地说，大型意味着程序员的数目超过25人，将近30,000行的指令）7的基础上，对程序员的生产率进行了研究。他根据程序员（和系统部分）之间的交互划分这些系统，得到了如下的生产率：

非常少的交互：10,000 指令每人年

少量的交互：5,000

较多的交互：1,500

该人年数据未包括支持和系统测试活动，仅仅是设计和编程。当这些数据采用除以2，以包括系统测试的活动时，它们与Harr的数据非常的接近。

Joel Aron, manager of Systems Technology at IBM in Gaithersburg, Maryland, has studied programmer productivity when working on nine large systems (briefly, large means more than 25 programmers and 30,000 deliverable instructions).[7] He divides such systems according to interactions among programmers (and system parts) and finds productivities as follows:

The man-years do not include support and system test activities, only design and programming. When these figures are diluted by a factor of two to cover system test, they closely match Harr's data.

Harr的数据（Harr's Data）

John Harr，Bell电话实验室电子交换系统领域的编程经理，在1969年春季联合计算机会议8的论文中，汇报了他和其他人的经验。这些数据如图8.2、8.3和8.4所示。

John Harr, manager of programming for the Bell Telephone Laboratories' Electronic Switching System, reported his and others' experience in a paper at the 1969 Spring Joint Computer Conference.[8] These data are shown in Figs. 8.2, 8.3, and 8.4.

这些图中，图8.2是最数据详细和最有用的。头两个任务是基本的控制程序，后两个是基本的语言翻译。生产率以经调试的指令/人年来表达。它包括了编程、构件测试和系统测试。没有包括计划、硬件机器支持、文书工作等类似活动的工作量。

Of these, Fig. 8.2 is the most detailed and the most useful. The first two jobs are basically control programs; the second two are basically language translators. Productivity is stated in terms of debugged words per man-year. This includes programming, component test, and system test. It is not clear how much of the planning effort, or effort in machine support, writing, and the like, is included.

生产率同样地被划分为两个类别，控制程序的生产率大约是600指令每人年，语言翻译大约是2200指令每人年。注意所有的四个程序都具有类似的规模--差异在于工作组的大小、时间的长短和模块的个数。那么，哪一个是原因，哪一个是结果呢？是否因为控制程序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定。控制程序确实更加复杂。除开这些不确定性，数据反映了实际的生产率--描述了在现在的编程技术下，大型系统开发的状况。因此，Harr数据的确是真正的贡献。

图8.3和8.4显示了一些有趣的数据，将实际的编程速度、调试速度与预期做了对比。

The productivities likewise fall into two classifications; those for control programs are about 600 words per man-year; those for translators are about 2200 words per man-year. Note that all four programs are of similar size—the variation is in size of the work groups, length of time, and number of modules. Which is cause and which is effect? Did the control programs require more people because they were more complicated? Or did they require more modules and more man-months because they were assigned more people? Did they take longer because of the greater complexity, or because more people were assigned? One can't be sure. The control programs were surely more complex. These uncertainties aside, the numbers describe the real productivities achieved on a large system, using present-day programming techniques. As such they are a real contribution.

Figures 8.3 and 8.4 show some interesting data on programming and debugging rates as compared to predicted rates.

OS/360的数据

IBM OS/360的经验，尽管没有Harr那么详细的数据，但还是证实了那些结论。就控制程序组的经验而言，生产率的范围大约是600～800（经过调试的指令）/人年。语言翻译小组所达到的生产率是2000～3000（经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。就我的观点来说，它们同Harr的数据是可比的。

IBM OS/360 experience, while not available in the detail of Harr's data, confirms it. Productivities in range of 600–800 debugged instructions per man-year were experienced by control program groups. Productivities in the 2000–3000 debugged instructions per man-year were achieved by language translator groups. These include planning done by the group, coding component test, system test, and some support activities. They are comparable to Harr's data, so far as I can tell.

Aron、Harr和OS/360的数据都证实，生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片"沼泽"上的指导原则是：编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍8。

Aron's data, Harr's data, and the OS/360 data all confirm striking differences in productivity related to the complexity and difficulty of the task itself. My guideline in the morass of estimating complexity is that compilers are three times as bad as normal batch application programs, and operating systems are three times as bad as compilers.[9]

Corbato的数据

Harr和OS/360的数据都是关于汇编语言编程的，好像使用高级语言系统编程的数据公布得很少。Corbato的MIT项目MAC报告表示在MULTICS系统上，平均生产率是经调试的1200行 PL/I 语句（大约在1和2百万指令之间）/人年。

Both Harr's data and OS/360 data are for assembly language programming. Little data seem to have been published on system programming productivity using higher-level languages. Corbatò of MIT's Project MAC reports, however, a mean productivity of 1200 lines of debugged PL/I statements per man-year on the MULTICS system (between 1 and 2 million words).[10]

该数字非常令人兴奋。如同其他的项目，MULTICS包括了控制程序和语言翻译程序。和其他项目一样，它产出的是经过测试和文档化的系统编程产品。在所包括的工作类型方面，数据看上去是可以比较的。该数字是其他项目中控制程序和翻译器程序生产率的良好平均值。

This number is very exciting. Like the other projects, MULTICS includes control programs and language translators. Like the others, it is producing a system programming product, tested and documented. The data seem to be comparable in terms of kind of effort included. And the productivity number is a good average between the control program and translator productivities of other projects.

但Corbato的数字是行/人年，不是指令！系统中的每个语句对应于手写代码的3至5个指令！这意味着两个重要的结论。

.. 对常用编程语句而言，生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况.

.. 使用适当的高级语言，编程的生产率可以提高5倍。

But Corbatò's number is lines per man-year, not words! Each statement in his system corresponds to about three to five words of handwritten code! This suggests two important conclusions.

• Productivity seems constant in terms of elementary statements, a conclusion that is reasonable in terms of the thought a statement requires and the errors it may include.[11]

• Programming productivity may be increased as much as five times when a suitable high-level language is used.[12]

Chapter 8 Appendix:

1. Sackman, H., W. J. Erikson, and E. E. Grant, "Exploratory experimentation studies comparing online and offline programming performance," CACM, 11, 1 (Jan., 1968), pp. 3–11.

2. Nanus, B., and L. Farr, "Some cost contributors to large-scale programs," AFIPS Proc. SJCC, 25 (Spring, 1964), pp. 239–248.

3. Weinwurm, G. F., "Research in the management of computer programming," Report SP-2059, System Development Corp., Santa Monica, 1965.

4. Morin, L. H., "Estimation of resources for computer programming projects," M. S. thesis, Univ. of North Carolina, Chapel Hill, 1974.

5. Portman, C., private communication.

6. An unpublished 1964 study by E. F. Bardain shows programmers realizing 27 percent productive time. (Quoted by D. B. Mayer and A. W. Stalnaker, "Selection and evaluation of computer personnel," Proc. 23rd ACM Conf., 1968, p. 661.)

7. Aron, J., private communication.

8. Paper given at a panel session and not included in the AFIPS Proceedings.

9. Wolverton, R. W.; "The cost of developing large-scale software," IEEE Trans. on Computers, C-23, 6 (June, 1974) pp. 615–636. This important recent paper contains data on many of the issues of this chapter, as well as confirming the productivity conclusions.

10. Corbatò, F. J., "Sensitive issues in the design of multi-use systems," lecture at the opening of the Honeywell EDP Technology Center, 1968.

11. W. M. Taliaffero also reports a constant productivity of 2400 statements/year in assembler, Fortran, and Cobol. See "Modularity. The key to system growth potential," Software, 1, 3 (July 1971) pp. 245–257.

12. E. A. Nelson's System Development Corp. Report TM-3225, Management Handbook for the Estimation of Computer Programming Costs, shows a 3-to-1 productivity improvement for high-level language (pp. 66–67), although his standard deviations are wide.

关于《人月神话》

在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。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计算机的体系结构设计师。

【更多阅读】

• 【架构师必知必会系列】系统架构设计需要知道的5大精要（5 System Design fundamentals）

• 《人月神话》7（The Mythical Man-Month）为什么巴比伦塔会失败？

• 《人月神话》（The Mythical Man-Month）6贯彻执行（Passing the Word）

• 《人月神话》（The Mythical Man-Month）5画蛇添足（The Second-System Effect）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• MySQL 体系架构简介

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

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