病态软件项目的四骑士

别让苍白的骑士用异常抓住你。

尊敬的 KV：

是否有任何可靠的衡量标准可以用来判断软件项目的健康状况？我见过很多关于软件质量的文章，但关于项目本身质量的文章却不多。我问这个问题是因为我担心自己被困在一个失败的项目中，但很难知道它是否真的在失败。我工作的公司交替地给项目提供和剥夺资源，同时又说按时完成下一个版本是我们成功的关键。如果我们是成功的关键，他们为什么要定期剥夺项目的资源呢？我一直在想，我是否是温水煮青蛙中的青蛙，只有到了为时已晚的时候，我才会意识到自己应该离开。如果软件质量有衡量标准，那么项目质量肯定也有衡量标准吧？

温水煮青蛙

尊敬的 Heating：

软件团队与软件项目不同，它是由人组成的，与人的互动是混乱的，这就是我们中一些人最初进入这个领域的原因：为了避开混乱的人类，与美妙的逻辑和精确的机器打交道。不幸的是，一个人很难构建任何有趣的东西，所以你最终会与一个团队一起工作，而团队是由人组成的，正如萨特曾经说过的那样，“他人即地狱。”

有很多关于软件项目如何生存或死亡的书籍和文章，其中最著名的是弗雷德·布鲁克斯的《人月神话》，我很久以前就在这些页面中推荐过，我仍然坚持这个推荐。《人月神话》的著作仍然具有现实意义，因为——与我们工作的技术不同——人们不会很快改变，有些人，包括 KV，会认为人们很少从他们的经验中吸取教训。如果你怀疑我的愤世嫉俗，拿起一份报纸看看头版。我会等你的。

在不深入探讨软件团队失败的具体案例的情况下，我们可以谈谈软件项目可耻结局的四个预兆。这些预兆与神话中的天启四骑士非常相似：战争、饥荒、瘟疫和死亡。

当一个团队开始失败时，最早出现的预兆之一是战争。运作良好的团队可以相处——至少在工作环境中——并分担任务，当一个成员负担过重时可以移交任务，并且通常以融洽的方式工作。当一个团队开始失败时，团队成员会变得越来越偏执，因为他们不想为失败承担责任。

这种偏执通常表现为极端的防御性，其想法是，“不是我的错我们失败了。我的代码运行正常！”在一个大型且复杂的项目中，一旦团队中有足够多的人陷入这种偏执状态，他们就会攻击任何或任何人，只要他们可能被视为在质疑他们工作的质量。这种攻击会导致争吵，看起来很像战争，尽管这种战争是通过代码提交、尖酸刻薄的评审和令人讨厌的电子邮件线程进行的。很难成为不朽传奇的素材，但足以消耗团队的精力，使其陷入失败的恶性循环。

随着团队失败和项目延期，管理层可能会决定是时候将精力集中在其他地方，并将开发人员从团队中调走，投入到其他领域的工作中。移除开发人员会剥夺项目的资源，并导致饥荒。此时，杀死项目并在更有效率的方式下完全重建团队可能更有意义，但管理者——像开发人员一样——常常对奇迹般的拯救抱有太大的希望，因此，在一个团队应该解散很久之后，仍然继续一个项目。像千刀万剐一样痛苦漫长地死于饥荒。如果你在一个不断被剥夺资源的项目中，就该找点别的事情做，或者找个别的地方工作了。一旦饥荒开始，恢复就变得困难，最好到别处寻求生存。

KV 在过去的专栏中谈到过各种软件质量的衡量标准，但也许软件质量下降——以 bug 数量不断增加的形式——是团队正在失败的最客观的衡量标准之一。这种瘟疫是由战争和饥荒给团队带来的士气低落造成的，这清楚地表明出了问题。在现实世界中，可以剔除患病的动物，以防止疾病蔓延并在陆地上蔓延成瘟疫。bug 数量的增加，尤其是在没有增加功能的情况下——即代码修复导致更多 bug 而不是实际修复时——是项目末日即将来临的可靠迹象。

最后的骑士不是死亡的预兆，而是死亡本身。最终，管理层或风险投资家将被迫看到失败的真相，扼杀项目，并解散团队。在最极端的情况下，这也会摧毁公司本身。这是我们这些在行业工作过一段时间的人都见过的时刻——通常是亲眼所见——而且从来都不好看。当你在一个团队中看到战争、饥荒和瘟疫时，如果你无法解决问题——而我们中很少有人能够做到——那么就该转移到其他地方或其他事情上，以免苍白的骑士在你深陷一个复杂的函数中时用异常抓住你，让你无法返回。

乔治·V·内维尔-尼尔 以编写网络和操作系统代码为乐和盈利。他还教授各种与编程相关的科目课程。他的兴趣领域是计算机安全、操作系统、网络、时间协议以及大型代码库的维护和管理。他是The Kollected Kode Vicious的作者，并与马歇尔·柯克·麦库西克和罗伯特·N·M·沃森合著了The Design and Implementation of the FreeBSD Operating System。近 20 年来，他一直是以 Kode Vicious 而闻名的专栏作家。自 2014 年以来，他一直担任剑桥大学的工业访问学者，参与了多个与计算机安全相关的项目。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他的软件不仅在地球上运行，而且还作为 VxWorks 的一部分部署在 NASA 的火星任务中。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。

最初发表于 Queue 第 20 卷，第 4 期—
在数字图书馆中评论这篇文章

更多相关文章

凯瑟琳·海耶斯，大卫·马龙 - 质疑评估非密码散列函数的标准
尽管密码散列函数和非密码散列函数无处不在，但在它们的设计方式上似乎存在差距。密码散列函数存在许多由各种安全要求驱动的标准，但在非密码方面，存在一定程度的民间传说，尽管散列函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。

妮可·福斯格伦，埃伊里尼·卡利亚姆瓦库，艾比·野田，米凯拉·格雷勒，布赖恩·豪克，玛格丽特-安妮·斯托里 - DevEx 实践
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

若昂·瓦拉尧，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发效率
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，以研究生产力差异，从而提供关于该主题的新见解。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

伊瓦尔·雅各布森，阿里斯泰尔·科伯恩 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的过程中，它容易受到时尚潮流的支配，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，并在后来普及，是这些成熟的解决方案之一。