只有不容忍才能提升软件质量

虽然称为不容忍,但其实有认真的含义,属于偏执狂才能生存的逻辑。

该文认为:无论是软件开发团队的一员还是“软件开发协会”:对质量的最大影响并不是通过达成共识、投票或者容忍他人的观点或编码方式来实现的。对软件质量产生最大的影响的因素正好与前面描述的共识相反:是不能容忍所有不同的风格、方法以及固执于你自己的方式。“最不容忍的人获胜”。

例如,如何改进项目的编码风格?也许可以讨论一下你们都喜欢哪种风格,然后就其中一种达成一致。同意了已经从现在开始你们都会应用这种一致的方案吗?不会,作为管理者你,只能在任何地方都强制使用它,并对不采用它的现象表现为非常不容忍,这样才能实现一致的编码风格(也就是说,只允许符合这种特定样式的提交)。

另一个例子:你会让你的同事决定是否使用静态方法来获取依赖关系,还是将所有依赖项作为构造函数参数注入?如果两者都允许的话,结果将是一团糟。你甚至无法使用这两个选项中的任何一个方法来实现依赖了,一个类不可以同时有这两个选选项,要彻底提高和保护项目的质量,就需要不容忍。

在过去的20年里,我与开发人员和管理人员进行了大量的交谈,结果证明这只是空谈,没有行动。我不知道你的经历(虽然我很想听听它们!),但这是“科技对话”的一个非常普遍的特点;很多会议,很多讨论,很酷的想法,很棒的计划,但这些都不会发生。当然,有很多原因,比如:

会议上的经理们只是想让开发人员高兴,所以他们允许他们做得很好。计划永远不会被执行。

开发人员对他们的工作不再满意,所以他们构建了一个共同的梦想,即事情会怎样“如果.”。

每个人都意识到,伟大的计划是伟大的,永远无法完成,所以没有人敢开始做这项工作。

说话的人觉得他们必须就每件事达成共识,只能在空谈中才能达成共识。

我相信,根据经验,您可以在这个列表中添加更多的原因。

我发现我过去在项目上最有影响力的工作是先行动。我做了一些事情,相信这是正确的事情,投入我自己的时间,并证明“它可以工作”。我在正常上班时间之外,在无法人付工资的时间内,在没有(很多)共识的情况下做了这项工作。毫无例外,开始一个改变会导致其他人跳进来、支持和完成这项工作。挖坑,带着大家跳坑,填坑。

事实上,当我被问到:“我如何能在我的团队中改变X?”我的第一条建议总是:不要问,只要去做。

我一直认为这是做自由职业者的一个很好的理由:你犯的错误迫使你去适应,去学习。你从你所做的事情中得到即时的反馈,并利用它成为一个更好的自由职业者。因为你想让你的生意持续下去,而不是以坏名声收场,成为一个无法被雇用的人。

然而,重新考虑这一点,我认为把“自雇”和“从错误中吸取教训”联系起来是不明智的。

重要的是工作中涉及的反馈回路,如果你犯了一个错误,但它永远不会和你联系在一起,或者你永远不会听到它,你就无法从中吸取教训。这很可能会发生在任何自由软件开发人员身上:你犯的错误(你制造的错误,你强加的糟糕的设计,你介绍的耦合问题),可能会浮出水面。在你成功之后。由于公司通常不能支付(一组)自由开发人员超过一到两年,你很可能会错过你所犯的错误,因此不会从中吸取教训。在未来的几年里,你甚至可能会在其他项目中犯同样的错误。

如果是这样,那么,我建议你不要一开始做自由职业者,我确实建议你寻找方法,你可以利用你产生的错误,评估事情的进展,并寻找方法,帮助你改善。

原文:
https://matthiasnoback.nl/2018/08/improving-your-software-project-by-being-intolerant/

如果一个企业在开发软件时行政化气氛较强,构成一种二极管的半通状态,那么领导者就无从知道他们下的命令是否合适,部下士气会降低