观点
PDF燃烧的粪便袋——及其他环境反模式
你认为你的问题很严重吗？
菲利普·拉普兰特，宾夕法尼亚州立大学
在我年轻的时候，当地不良少年（作为一个书呆子，我不是其中之一）最喜欢的恶作剧是将装满狗屎的纸袋放在邻居的门廊上，点燃它，按响门铃，然后逃跑。房主在应门后，别无选择，只能踩灭燃烧的粪便，在此过程中弄脏他们的鞋子。为什么要讲这个粪便轶事呢？因为它是一个隐喻，象征着工作环境中情况变得如此糟糕，以至于“灭火”的唯一方法就是踩进去。我称之为“燃烧的粪便袋”反模式。
威廉·布朗、拉斐尔·马尔沃、海斯·“斯基普”·麦考密克和托马斯·莫布雷在他们开创性的著作《反模式：重构软件、架构和危机项目》（约翰·威利父子出版社，1998年）中，描述了软件架构、设计和项目管理中反复出现的一系列问题。他们还描述了针对这些情况的解决方案或重构。提供这样的分类法有助于快速识别问题情况，为解决问题提供行动指南，是的，也为处于这些情况中的人们提供一些滑稽的缓解。
将他们的分类法扩展到组织，引出了另一种反模式，“环境反模式”（我们也可以称之为“文化”或“情境”反模式）。这就是“燃烧的粪便袋”反模式的适用之处。
环境反模式与其他类型的反模式不同，因为它们更难归咎于特定的个人或实践。相反，反模式是由于一组静态和动态的内部环境条件造成的，这些条件营造了有毒的氛围。此外，环境反模式通常比其他反模式更难检测，因为它们变得如此普遍，以至于可能被隐藏起来。当你看到糟糕的软件架构时，你就知道它不好。你可以识别糟糕的软件设计。但描述一种消极的文化并不总是容易的。通常，它被描述为：“这个地方真烂。”
什么是反模式？
对于软件工程师来说，模式是一个命名的“问题-解决方案”对，用于实现软件设计和架构的大规模重用。基于建筑师克里斯托弗·亚历山大的工作，他试图在使用独一无二的设计时实现建筑物设计的可重复性，模式明确地捕捉了专家知识，并使这种专业知识更广泛地可用。软件设计、分析、管理等方面有许多模式集（“模式语言”）。
在设计、分析、管理等模式出现后不久，从业者开始讨论“问题-解决方案”对，其中传统的解决方案弊大于利，被称为“反模式”。
我的同事科林·尼尔和我已经识别出许多环境反模式（这将出现在我们即将出版的书籍《IT反模式》，奥尔巴赫出版社，2005年），我们还在不断添加到这个列表中。我将在此介绍这些反模式的示例，描述软件开发或IT世界中的典型场景，并为这种情况提供重构。在某些情况下，可能没有干净的方法来灭火。在其他情况下，勇气可能会以最小的附带损害来解决问题——例如，通过处理长期存在的员工问题。请注意，逃离困境始终是一种潜在的重构，而且往往是最理想的重构。无论如何，通过描述这些反模式，我希望您能够更善于识别类似的情况并采取适当的行动。
燃烧的粪便袋
这种反模式已经在幽默的比喻中描述过了。在真正的意义上，它描述了由一个或多个逃离的管理者留下的任何负面工作环境。事实上，一个序列通常涉及将“粪便袋”从一个管理者传递到另一个管理者——真是“烫手山芋”！当解决负面情况的每种明显补救措施都涉及某种创伤性痛苦时，这种情况就完全符合——例如，裁员。
在软件世界中，燃烧的狗屎袋可能包括软件开发实践（或缺乏实践），这些实践已完全嵌入公司中，以至于再培训将是徒劳的（例如，“敏捷”商店，其中每种渎职行为都被解释为敏捷宣言的一部分）。它也可能表现为项目管理文化，其中涉及指标的误用，从而导致偏执——你不能建议不使用指标，但你也无法让人们正确使用它们。
在其他情况下，必须拉响火警警报——组织的其余部分必须伸出援手。这是一个合理的解决方案策略，因为可能是之前的管理者被留下独自处理燃烧的粪便袋，因为他不受欢迎。例如，在之前描述的情况下，只有通过宣传方法的正确应用才能修复对敏捷实践的滥用。这需要很大的勇气；如果条件合适，可能会有集体改革。如果你是高级经理，你可以强制进行再培训，或者你可以通过招聘和解雇来重组你的团队。同样的重构可能适用于指标被意外或恶意滥用的环境。
创始人病
在这种反模式中，当公司的增长超出创始人自身技能时，创始人难以放手。创始人仍然想控制一切，就像公司还是一个人的小店时一样。创始人病及其影响如此普遍的原因是，启动一家公司并使其成功所需的技能与运营一家中型甚至上市公司所需的技能截然不同。
尽管这种反模式归因于单个个体（或一小群创始人），但其影响却如此深远，并且如此紧密地编织到公司的结构中，以至于它正在进行环境改造。其影响是创始人自上而下的普遍微观管理和令人窒息的氛围。我见过许多收入从几百万到数十亿美元的组织都患有创始人病（不，我不是指微软；尽管创始人深度参与其中，但显然，这是一个拥有独特文化的健康组织）。例如，我知道两家收入超过1亿美元的软件公司，每家公司都有200多名员工，创始人仍然亲自编写代码并批准其他人所做的代码更改。
大多数成熟的风险投资家都认识到创始人病，并且一旦初创公司的收入达到一定水平，就会撤换创始人，即使这家初创公司很成功。其他重构包括：制定已发布的继任计划；请一位德高望重的人与创始人谈论负面文化；学会接受这种情况；以及离开公司。后一种重构是最可能的解决方案——通常，即使是创始人的儿子也会因为无法在那种环境中生存而离开。离开公司避免了不得不与创始人对质的丑陋局面。
赤脚的孩子
这种反模式与鞋匠的孩子没有鞋子的寓言有关，因为他们的父亲太忙于糊口。在软件和IT世界中，“赤脚的孩子”反模式类似于公司拒绝给自己提供设备或自助服务，因为其所有资源都集中在产品开发、交付和客户服务上。在极端情况下，某家软件公司可能会拒绝给自己提供足够的软硬件资源，即使它正在为客户提供“最先进的”解决方案。这是一种环境反模式，因为赤脚通常是基于根深蒂固的节俭文化习俗。
重构取决于“赤脚的孩子”环境的原因。在某些情况下，这种情况可能与创始人病有关，这暗示了一组重构。在其他情况下，反模式可能源于不良管理，导致不良现金流和内部资源的必要匮乏。在这种情况下，解决方案是战略性预算削减，但不包括必要的基础设施，这绝非有趣或容易。
崇拜金牛犊
在任何缺乏远见或领导力的环境中，人们常常方便地将希望寄托在一种知之甚少的技术或方法论上，从而为某种奇迹提供希望。由于没有人真正理解该技术、方法论或实践，因此很难驳斥它。这是一种环境反模式，因为它基于集体的暂停怀疑和贪婪，而这种怀疑和贪婪不可能由一两个人拥抱荒谬来维持。
在某种程度上，互联网商业模式是金牛犊（又名“皇帝的新装”）。一些失败的企业（甚至是非失败的企业）迅速转向这种模式，希望获得救赎或快速回报。集体认为改变基础编程语言或开发环境将治愈与糟糕的软件架构或管理文化相关的问题，这是祈求镀金小牛的另一个例子。
这种现象也与“冰球杆”收入预测有关——在记录了n个月的利润下降之后，通过一些含糊不清的理由，分析师预测会出现突然、急剧的上升趋势，这类似于冰球杆。每个人都希望相信这样的奇迹是可能的。
金牛犊环境的重构是揭露小牛的真面目。这需要揭露者付出巨大的勇气和努力，因为那些相信的人会抓住任何渺茫的希望——即使在无可辩驳的证据面前也是如此。回想一下著名的漫画，两位教授在黑板上，两行方程式之间写着“然后奇迹发生了”。持怀疑态度的教授说：“我认为你必须在第二步中更加明确。”将当前的金牛犊比作以前被揭露的金牛犊也可能有所帮助。
结论
这份情境反模式列表仅代表了一些最常见的环境情况，这些情况可能表明组织病态。虽然，事后看来，每个问题的解决方案似乎都很明显，但只有当问题被正确识别时才是这样。此外，应用重构将需要勇气、力量和智慧。
不幸的是，在处理燃烧的粪便袋时，无法避免被烧伤或踩到你知道的东西。可悲的是，当制度惯性难以克服时，最好的重构通常是逃离。无论如何，我希望这组环境反模式的子集将引导您正确识别自己的情况，从而找到解决方案。
喜欢它，讨厌它？请告诉我们
[email protected] 或 www.acmqueue.com/forums
菲利普·拉普兰特，博士，是宾夕法尼亚州立大学大谷研究生院的软件工程副教授。他的研究兴趣包括实时和嵌入式系统、图像处理和软件需求工程。他撰写了大量论文、20本书，并共同创办了期刊《实时成像》。他编辑了 CRC 出版社的图像处理系列，并担任四家期刊的编委会成员。拉普兰特在史蒂文斯理工学院获得计算机科学学士学位、电气工程硕士学位和计算机科学博士学位，并在科罗拉多大学获得工商管理硕士学位。他是 IEEE 的高级会员、 和国际光学工程学会 (SPIE) 的会员，以及宾夕法尼亚州注册的专业工程师。
© 2004 1542-7730/04/1000 $5.00
最初发表于 Queue vol. 2, no. 7—
在 数字图书馆 中评论本文
更多相关文章
凯瑟琳·海耶斯，大卫·马龙 - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全需求，存在许多针对加密哈希的标准，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
妮可·福斯格伦，埃里尼·卡利亚姆瓦库，艾比·诺达，米凯拉·格雷勒，布莱恩·豪克，玛格丽特-安妮·斯托里 - DevEx 在行动
随着领导者在财政紧缩和人工智能等转型技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者直观地认为，良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
若昂·瓦拉霍，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清晰地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
伊瓦尔·雅各布森，阿里斯泰尔·科克伯恩 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对它所面临的一些永恒问题的行之有效的解决方案。用例于 1986 年首次引入，后来普及，是这些行之有效的解决方案之一。
© 保留所有权利。