工程师办公室，愉快地想了想如何进行工作组织，以及是否有什么不妥。过了四个小时，他带Berkeley 进来，与Coster 会面。这位总工程师正在他的桌子上睡觉，头枕在臂弯里。Harriman慢慢地退出去，但Coster醒了过来。“喔，对不起，”他有点不好意思地说，“我肯定是打了个瞌睡。”“这就是我给你带来长沙发的原因，”Harriman 说道。“它更加舒适。Bob，来见一下Jock Berkeley。他是你的新奴隶，你仍是总工程师，毫无疑问的老板。Jock是其他一切的主管。从现在起，你不需要担心其他的任何问题，除了建造登月飞船的一些细节问题。”他们握了一下手。“Coster 先生，我只想问一件事，”Berkeley 认真的说，“所有你需要做的事，我都无权过问——你即将进行一个技术演示——但是看在上帝的份上，能否记录一下，从而让我了解一下。我将会把一个开关放在你的桌上，它会开启桌上的一个密封的录像机。”“好的！”Coster正看着他，Harriman 想，够年轻的。“如果要做任何非技术的事情，不需要自己动手。只需按个按钮知会一声，它们就会被完成！”Berkeley 扫了Harriman一眼。“老板说他想同你谈一谈实际的工作。我得先走，去忙去了。”他离开了。Harriman坐了下来，Coster整了整衣服，说道，“喔！”“感觉好一些了？”“我喜欢Berkeley 这小伙子的样子。”“太好了！不用担心，他现在就是你的孪生兄弟。我以前用过他。你可以认为你正住- 47 ------------------------ Page 60-----------------------2在一个头等的疗养院里。”这个故事几乎不需要任何的分析解释，这种安排同样能使工作非常有效。我猜测最后一种安排对小型的团队是最好的选择，如同在第3 章《外科手术队伍》一文中所述。对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更合适的安排。巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果——组织，是成功的关键。交流和组织的技能需要管理者仔细考虑，相关经验的积累和能力的提高同软件技术本身一样重要。- 48 ------------------------ Page 61-----------------------胸有成竹（Calling the Shot）实践是最好的老师。- PUBILIUS实践是最好的老师，但是，如果不能从中学习，再多的实践也没有用。- 《可怜的理查年鉴》Practice is the best of all instructors.- PUBILIUSExperience is a dear teacher, but fools will learn at no other.- POOR RICHARD’S ALMANAC系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？先前，我推荐了用于计划进度、编码、构件测试和系统测试的比率。首先，需要指出的是，仅仅通过对编码部分的估计，然后应用上述比率，是无法得到对整个任务的估计的。编码大约只占了问题的六分之一左右，编码估计或者比率的错误可能会导致不合理的荒谬结果。第二，必须声明的是，构建独立小型程序的数据不适用于编程系统产品。对规模平均为3200 指令的程序，如Sackman、Erikson 和Grant 的报告中所述，大约单个的程序员所需要的编码和调试时间为178个小时，由此可以外推得到每年35,800 语句的生产率。而规模只有一半的程序花费时间大约仅为前者的四分之一，相应推断出的生产率几乎是每年80,000代码行1。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此，上述小型项目数据的外推是没有意义的。就好像把100码短跑记录外推，得出人类可以在3分钟之内跑完1英里的结论一样。在将上述观点抛开之前，尽管不是为了进行严格的比较，我们仍然可以留意到一些事- 49 ------------------------ Page 62-----------------------情。即使在不考虑相互交流沟通，开发人员仅仅回顾自己以前工作的情况下，这些数字仍然显示出工作量是规模的幂函数。图8.1 讲述了这个悲惨的故事。它阐述了Nanus 和 Farr2 在 System DevelopmentCorporation 公司所做研究，结果表明该指数为1.5，即，1.5工作量 ＝ （常数）×（指令的数量）3Weinwurm 的SDC 研究报告同样显示出指数接近于1.5。现在已经有了一些关于编程人员生产率的研究，提出了很多估计的技术。 Morin 对所发布的数据进行了一些调查研究4。这里仅仅给出了若干特别突出的条目。人月机器指令：千注：incomplete－未终结的图8.1：编程工作量是程序规模的函数Portman 的数据曼彻斯特Computer Equipment Organization （Northwest）的ICL 软件部门的经5理Charles Portman，提出了另一种有用的个人观点 。他发现他的编程队伍落后进度大约1/2，每项工作花费的时间大约是估计的两倍。这些- 50 ------------------------ Page 63-----------------------估计通常是非常仔细的，由很多富有经验的团队完成。他们对PERT 图上数百个子任务估算过（用人小时作单位）。当偏移出现时，他要求他们仔细地保存所使用时间的日志。日志显示事实上他的团队仅用了百分之五十的工作周，来进行实际的编程和调试，估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时间、高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等。简言之，项目估算对每个人年的技术工作时间数量6做出了不现实的假设。我个人的经验也在相当程度上证实了他的结论 。Aron 的数据JoelAron，IBM 在马里兰州盖兹堡的系统技术主管，在他所工作过的9 个大型项目（简7要地说，大型意味着程序员的数目超过25 人，将近30,000 行的指令）的基础上，对程序员的生产率进行了研究。他根据程序员（和系统部分）之间的交互划分这些系统，得到了如下的生产率：非常少的交互 10,000 指令每人年少量的交互 5,000较多的交互 1,500该人年数据未包括支持和系统测试活动，仅仅是设计和编程。当这些数据采用除以2，以包括系统测试的活动时，它们与Harr 的数据非常的接近。Harr 的数据John Harr，Bell 电话实验室电子交换系统领域的编程经理，在1969 年春季联合计算机会议8 的论文中，汇报了他和其他人的经验。这些数据如图8.2、8.3 和8.4 所示。这些图中，图8.2 是最数据详细和最有用的。头两个任务是基本的控制程序，后两个是基本的语言翻译。生产率以经调试的指令/人年来表达。它包括了编程、构件测试和系统测试。没有包括计划、硬件机器支持、文书工作等类似活动的工作量。生产率同样地被划分为两个类别，控制程序的生产率大约是600 指令每人年，语言翻译大约是2200 指令每人年。注意所有的四个程序都具有类似的规模——差异在于工作组的大小、时间的长短和模块的个数。那么，哪一个是原因，哪一个是结果呢？是否因为控制程- 51 ------------------------ Page 64-----------------------序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定。控制程序确实更加复杂。除开这些不确定性，数据反映了实际的生产率——描述了在现在的编程技术下，大型系统开发的状况。因此，Harr 数据的确是真正的贡献。图8.3和8.4 显示了一些有趣的数据，将实际的编程速度、调试速度与预期做了对比。程序单元 程序员人 年 人年 程序字数 字/人年数操作性 50 83 4 101 52,000 515维护 36 60 4 81 51,000 6301编译器 13 9 2 /4 17 38,000 22301语言解释 15 13 2 /2 11 25,000 2270器（汇编）图8.2：4 个NO.1 的ESS 编程工作总结机器指令：千字注：Monthly estimate of program size－程序规模月估计Actual Programmize rate－实际编程速度Prediction of programming rate－预计编程速度图8.3：ESS 预计和实际的编程速度- 52 ------------------------ Page 65-----------------------机器指令：千字注：Monthly estimate of program size－程序规模月估计Actual Programmize rate－实际调试速度Prediction of programming rate－预计调试速度图8.4：ESS 预计和实际的调试速度OS/360 的数据IBM OS/360 的经验，尽管没有Harr那么详细的数据，但还是证实了那些结论。就控制程序组的经验而言，生产率的范围大约是600～800 （经过调试的指令）/人年。语言翻译小组所达到的生产率是2000～3000 （经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。就我的观点来说，它们同Harr 的数据是可比的。Aron、Harr 和OS/360 的数据都证实，生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的8三倍，操作系统复杂度是编译器的三倍 。Corbato 的数据Harr 和OS/360 的数据都是关于汇编语言编程的，好像使用高级语言系统编程的数据公布得很少。Corbato 的MIT 项目MAC 报告表示在MULTICS 系统上，平均生产率是1200 行经调试的PL/I 语句（大约在1和2 百万指令之间）/人年。该数字非常令人兴奋。如同其他的项目，MULTICS 包括了控制程序和语言翻译程序。和- 53 ------------------------ Page 66-----------------------其他项目一样，它产出的是经过测试和文档化的系统编程产品。在所包括的工作类型方面，数据看上去是可以比较的。该数字是其他项目中控制程序和翻译器程序生产率的良好平均值。但Corbato 的数字是行/人年，不是指令！系统中的每个语句对应于手写代码的3 至5个指令！这意味着两个重要的结论。对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况.使用适当的高级语言，编程的生产率可以提高5倍。- 54 ------------------------ Page 67-----------------------削足适履（Ten Pounds in a Five-PoundSack ）他应该瞪大眼睛盯着诺亚，……好好学习，看他们是怎样把那么多东西装到一个小小的方舟上的。- 西德尼·史密斯，爱丁堡评论the author should gaze at Noah, and ... learn, as they did in the Ark, to crowda great deal of matter into a very small compass.- SYDENY SMITH. EDINBURGH REVIEW作为成本的程序空间程序有多大？除了运行时间以外，它所占据的空间也是主要开销。这同样适用于专用开发的程序，用户支付给开发者一笔费用，作为必要分担的开发成本。考虑一下IBM APL交互式软件系统，它的租金为每月400 美金，在使用时，它至少占用160K 字节的内存。在Model 165上，内存租金大约是12美金/每月每千字节。如果程序在全部时间内都可用，他需要支付400 美元的软件使用费和1920 美金的内存租用费。如果某个人每天使用APL 系统4 小时，他每月需要支出400 美元的软件租金和320美元的内存租用费。常常听到的一个“可怕的”谈论是在2M 内存的机器上，操作系统就需要占用400K 内存。这种言论就好像批评波音747 飞机，仅仅因为它耗资两千七百万美元一样无知。我们首先必须问的是“它能干什么？”。对于所耗费的资金，获得的易用性和性能是什么？投资在内存上的每月4800 美元的租金能否比用在其他硬件、编程人员、应用程序上更加有效？当系统设计者认为对用户而言，常驻程序内存的形式比加法器、磁盘等更加有用时，他会将硬件实现中的一部分移到内存上。相反的，其他的做法是非常不负责任的。所以，应- 55 ------------------------ Page 68-----------------------该从整体上来进行评价。没有人可以在自始至终提倡更紧密的软硬件设计集成的同时，又仅仅就规模本身对软件系统提出批评。由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，就像硬件开发人员会设立元器件数量目标，控制元器件的数量，想出一些减少零件的方法。同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。规模控制对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。他必须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干部分，并设定每个部分的规模目标。由于规模－速度权衡方案的结果在很大的范围内变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。聪明的项目经理还会给自己预留一些空间，在工作推行时分配。在OS/360 项目中，即使所有的工作都完成得相当仔细，我们依然能从中得到一些痛苦的教训。