Employee Turnover Is Good for the Maintainability of Your Code Base

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

这就是维基百科对此的说法:“如果熟练工人经常离职,并且工人群体中含有高比例的新手,高员工流动率可能对公司的生产力有害。” 我同意。然而,我认为低员工流动率也可能非常有害。

我在这篇好文章中找到了约翰·沙利文解释为什么低员工流动率可能是一个令人担忧的症状。这是一篇非常好的文章,但相对泛泛而论。它并不特别讨论软件团队。我的经验主要集中在程序员及其离职率上。我得知低员工流动率对代码可维护性产生负面影响,并鼓励“英雄驱动开发”和“代码所有权”(这两者都是不好的做法)。

“员工流动率”基本上是用新员工替换现有员工的行为,原因可以是解雇、退休、辞职或其他任何原因。简而言之,你的团队每年流失的人数越多,员工流动率就越高。如果你的团队有20名程序员,每年有5人离职,你的员工流动率就是25%。

我无法确定你应该追求什么具体的数字,但我坚信,如果你将“程序员”视为“有价值的长期资产”,并试图不惜一切代价留住他们,你就错了。

我的观点是,一个健康的软件团队必须定期“更换”程序员。我会说,让一个人在团队工作超过一年是在自找麻烦。

通过更换,我并不一定意味着解雇。完全不是这样。我是说将他们“远离”代码库。显然,如果你只有一个代码库,更换就意味着解雇。

当程序员长时间在一起,共同工作在同一个代码库上时,他们不可避免地会成为专家。首先,这导致强烈的代码所有权。自然地,他们中的每一个都会成为自己所负责代码的专家,主要是因为与熟悉的模块一起工作比在不同模块之间跳来跳去更容易。不用说,强烈的代码所有权是一种不好的做法。集体代码所有权是一个更好的替代方案,正如马丁·福勒所解释的那样。

然后,团队上有强大的专家必然会导致英雄驱动开发,其中消防工作非常受欢迎。专家不想失去自己的位置,总是试图证明自己对团队的价值。做到这一点的最好方法是解决其他人无法解决的问题。这就是如何获得“工作保障”。这也是团队开始退化的方式。弗雷德里克·鲁本森的这篇博文对这个问题是正确的。

因此,为了提高源代码的可维护性和产品的稳健性,我们必须“轮换”程序员,防止他们成为主题专家。

我意识到这个想法听起来违反直觉,但请思考一下。通过让人们长时间集中在同一个问题上工作,我们将大量的知识放入他们的头脑中,而不是我们的源代码中。这些人成为“资产”。他们变得更聪明,他们非常了解解决方案,并且能够迅速解决所有问题。但是代码库会退化。

当需要更换某个人(出于任何原因)时,损失将是巨大的。我们可能会失去重要的知识,并且留下的代码库将无法维护。在大多数情况下,我们将不得不重新编写它。这就是为什么在大多数软件团队中,管理层害怕程序员的原因。他们害怕失去关键的软件开发人员,因为后果可能是灾难性的。

最后,程序员控制着管理层,而不是相反。

这篇早期的帖子解释了如何解决这个问题,而不需要解雇或轮换程序员,但很少有团队,特别是实地协作的团队,有负担得起的能力。如果你的团队不能做到这一点,只需尽力保持员工流失率足够高,以防止“英雄”(也就是主题专家)的出现。

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:34

sixnines availability badge   GitHub stars