实践是最好的老师，但智者还能从其他的地方有所收获——《穷理查年鉴》
必须声明的是,构建独立小型程序的数据不适用于编程系统产品。对规模平均为3200指令的程序,如 Sackman、 Erikson和 Grant的报告中所述,大约单个的程序员所需要的编码加调试时间为178个小时,由此可以外推得到每年35800语句的生产率。而规模只有一半的程序花费时间大约仅为前者的1/4,相应推断出的生产率几乎是每年80000代码行。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。因此,上述小型项目数据的外推是没有意义的。就好像把100米短跑记录外推,得出人类可以在3分钟之内跑完1英里的结论一样。
Joel aron,IBM在马里兰州盖兹堡的系统技术主管,在他所参与过的9个大型项目(简要地说,大型意味着程序员的数目超过25人,将近30000行的指令)的基础上,对程序员的生产率进行了研究。他根据程序员(和系统部分)之间的交互划分这些系统,得到了如下的生产率:
非常少的交互 10000指令每人年
少量的交互 5000
较多的交互 1500
该人年数据未包括支持和系统测试活动,仅仅是设计和编程。当这些数据被除以2,以包括系统测试的活动时,它们与Harr的数据非常的接近。
生产率同样地被划分为两个类别:控制程序的生产率大约是600指令每人年,语言翻译大约是2200指令每人年。注意所有的4个程序都具有类似的规模——差异在于工作组的大小、时间的长短和模块的个数。
那么,哪一个是原因,哪一个是结果呢?是否因为控制程序更加复杂,所以需要更多的人员?或者因为它们被分派了过多的人员,所以要求有更多的模块和更多的人月?是因为复杂程度非常高,还是分配较多的人员,导致花费了更长的时间?没有人可以确定。控制程序确实更加复杂。
除开这些不确定性,数据反映了实际的生产率—一描述了在现在的编程技术下,大型系统开发的状况。因此,Harr数据的确是真正的贡献。
IBM OS360的经验,尽管没有Har那么详细的数据,但还是证实了那些结论。就控制程序组的经验而言,生产率的范围大约是600~800(经过调试的指令)人年。语言翻译小组所达到的生产率是2000~3000(经过调试的指令)人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。就我的观点来说,它们同Har的数据是可比的
Aron、Har和OS/360的数据都证实,生产率会根据任务本身复杂度和困难程度表现出显著差异。其指导原则是:编译器的复杂度是批处理程序的3倍,操作系统复杂度是编译器的3倍。
使用适当的高级语言，编程的生产率可以提高5倍