轶事证据

软件开发领域的一个令人沮丧的地方是，很难在不同的技术和工具之间做出选择。通常，当有人谈论这个问题时，他们会被要求提供“硬数据”，证明这种技术或工具比其他选择更好。这是一个可以理解的要求，但最终注定要失败。首先，我们无法衡量生产力.

因此，在缺乏硬数据的情况下，我们经常诉诸轶事证据。事实上，我整个职业生涯都是围绕着传播基于轶事证据分析的想法而展开的。尽管它不如客观测量的现象那么好，但轻视它是不明智的。毕竟，我们还能从哪里学习呢？我们从自己的经验中学到了很多，但当其他人告诉我们他们的经验时，它为我们的信息来源增添了很多。

这就是为什么我如此渴望看到人们报告他们的经验，即使它们是特定的，并且没有得到测量的支持。读者理解这些局限性，如果他们能够将这些教训应用到自己的环境中，他们会尽其所能。

去年，我参与了一个会议的程序委员会，并审阅了三篇论文，它们都遵循相同的基本主题。每篇论文都讨论了一个可以用来改进软件开发的想法。它们的关键缺陷在于作者没有尝试过他们的想法——甚至一次都没有。这就是为什么我对它们都投了反对票。

有些人会进一步扩展这一点——说在你看到一个想法在多个项目中应用之前，你不能真正谈论它。虽然这很好，但我不同意这是必要的。仅仅报告你在一个项目中发现的某一特定事情是有用的，因为它为其他人提供了原始材料。其他人可能处于类似的位置，你的想法给了他们一些东西可以尝试。其他人可能做过类似的事情，当他们写下他们的经验时，他们会将他们的经验报告在你之上。

这种方法——有些人报告他们的故事，其他人复制它，无论成功与否——是职业学习的支柱。事实是，它是轶事性的，但这并不妨碍它发挥作用——毕竟，没有科学严谨的证据表明降落伞可以防止从飞机上跳下来的人受到伤害。