引用
| 你知道吗，我们从来没有发现一个开发人员多年的经验与他的代码质量或生产力之间有直接关系。 |
关于开发人员经验与生产力关系的研究
最初对于个人编程生产力的研究是在1968年进行的，在这之后的30年间，其他研究人员至少做过8次同样的研究，结果并没有什么不同。他们在研究了一些平均有7年开发经验的专业开发人员后统计出：
- 开始编码时间比率约20 : 1
- 调试时间比率约25 : 1
- 程序执行速度比率约10 : 1
- 程序大小比率为5：1
他们发现没有一个开发人员的多年经验和代码质量或生产力之间存在直接联系。这说明经验和生产力（即生成代码的能力）之间不存在相关性，也说明经验和软件质量（即***限度地减少缺陷）之间没有相关性。
上图展示了两个开发人员群体——差的（生产效率、产品质量均低）和优秀的。研究发现，每个群体中都存在开发经验丰富和贫乏的开发人员。该研究只是说明多年的经验并不重要，并没有说明培训指导是否能帮助开发人员提升。
在不考虑合法性的前提下，这意味公司可以辞退掉拥有多年经验、工资高但产出低的开发者，并雇用一些没几年经验但高效高质的开发者。
尽管研究存在缺陷，但是仍显示出好的开发人员和差的开发人员之间存在数量级的差别，而这种差别与经验无关。关于“开发人员之间存在数量级的差异”已经被其他研究所证实。（见英文原文***的参考文献）
技术越来越先进，而开发者不是
你可能会认为与过去相比，现在我们对软件开发了解得更多，毕竟现在：
- 我们有更好的计算机语言
- 我们有更先进的技术
- 我们有对高效开发模式有更好的研究
- 我们在大学中有正规的软件专业
上面这些都是事实，但现在开发人员之间仍然存在较大的差异。这意味着有一些X因素驱动着产品开发，X因素可能是开发人员规划并作出正确决定的能力。
| 坏消息是，如果你不是一个高效、高质量的开发者，那么仅仅是多年的经验可能不会令你变得更好。 |
学会决策
开发人员每一天都面临着“如何构建自己的代码”的决策。比如如何：
- 规划代码路径
- 将函数封装成类
- 将类封装成包/模块
开发人员面临的编码决策，其中有许多是复杂的，好的开发人员会安排他们的工作，并做出正确的决定。差的开发人员只是“跳过”，他们认为，他们总是可以重写代码或在做出决定后再弥补错误。差的开发人员甚至没有意识到他们的决策过程是糟糕的，他们完全可以通过规划工作来变得更好。
解决方案：可能是PSP和TSP
Watts Humphrey试图通过针对个人的PSP（Personal Software Process，个体软件过程）和针对团队的TSP（Team Software Process，团队软件过程）来让开发人员了解评估、规划开发和决策的价值。但只有很少的组织接受他。Capers Jones已经分析了超过18,000个项目，发现：
- PSP可以提高生产力21.2%，提高质量31.2%
- TSP可以提高工作效率20.9%，提高质量30.9%
这些研究，对创建开发团队有一定的帮助。比起拥有平庸开发人员的大型团队来说，拥有高效开发人员的小型团队更为合理，因为他们知道如何规划并作出正确的决定。
| PSP和TSP建议：改造一个差的开发人员的***的方式是教他们如何作出更好的决策。 |
要知道，随着时间的推移，知识技能、编写高效高质代码的能力是会提升的。
结论
本质上，我们都知道这一点，但只是很难做到。如果公司中的高级管理人员知道这些研究，那么高效高质的开发者会得到更多的报酬，差的开发者可能就需要另谋高就了。这样做不仅降低了构建软件的成本，同时也提高了软件质量。
不幸的是，我们一直都在为各种编程方法、语言和技术辩论、斗争不已。大多数组织中的开发人员的编码方式，正在逐步使“巫毒科学（VoodooScience）”看起来像“科学”。（译者注：指一些不正统的编码方式逐渐成为主流）。
