重读《人月神话》（9）-胸有成竹（Calling the Shot）

将程序员的生产效率量化到指令/年，是一个过时的好方法吗？

系统编程的时间和工作量估计是一项复杂且精细的任务。简单地根据编码部分进行估计，然后应用固定比率，往往会导致不准确的结果。实际上，编码仅占整个项目工作量的六分之一左右，而其他诸如规划、文档编写、测试、系统集成和培训等任务同样占据大量时间。

以下是几种估计方法和实际经验数据的总结：

Aron 的数据

基于 IBM 在马里兰州盖兹堡的九个大型项目，Aron 发现程序员的生产率取决于系统中各部分之间的交互程度：

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

• 少量的交互：5,000 指令/人年

• 较多的交互：1,500 指令/人年

Harr 的数据

在 Bell 实验室，Harr 发现控制程序的生产率为 600 指令/人年，而语言翻译程序的生产率为 2200 指令/人年。

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

OS/360 经验

控制程序组的生产率大约为 600 到 800 指令/人年，语言翻译程序组则为 2000 到 3000 指令/人年。

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

综合来看，系统编程的工作量和时间消耗高度依赖于项目的复杂性、团队规模以及使用的编程语言等因素。使用高级语言可以显著提高生产力，但无论使用何种语言，系统编程的生产率都相对较低，尤其是在涉及大量交互和复杂控制逻辑的情况下。因此，在进行项目估计时，需要全面考虑各个阶段的工作量，并留有足够的缓冲时间以应对不可预见的问题。