晨间论文
PDF晨间论文
委员会如何发明？以及自动化的讽刺
康威定律的制定以及自动化水平提高带来的违反直觉的后果
Adrian Colyer
林迪效应告诉我们，如果一篇论文在很长一段时间内都具有高度相关性，那么它很可能在未来很长一段时间内继续如此。对于本期精选，我将回顾几篇经受了时间考验的论文。它们包含的教训可以在未来许多年继续结出硕果。
我的第一个选择，来自 1968 年，题为“委员会如何发明？”。 这篇论文提出了康威定律，虽然我们今天都知道这个定律，但作者 Melvin E. Conway 提供了大量精彩的材料，最终形成了以他的名字命名的定律。 这是一篇很棒的论文，每次阅读都会给你带来新的收获。 根据林迪效应，它应该还能再流行 52 年；）。
我的第二个选择是时间推进到 1983 年，Lisanne Bainbridge 的“自动化的讽刺”。 这是关于自动化水平提高带来的违反直觉的后果的经典论文，并且对于即将到来的十年来说非常重要。 当我们需要专家时，他们会在哪里？
委员会如何发明？
Conway, M. E. 1968. 委员会如何发明？ Datamation 14(4), 28-31.
感谢 Chris Frost 推荐这篇论文——这是一个很好的例子，我们都知道定律（本例中为康威定律），但我们中的许多人实际上并没有阅读其背后的原始思想。
我们回到 1968 年，那时人们理所当然地认为，在构建系统之前，必须先设计它。 顺便说一句，这里讨论的系统并不局限于计算机系统——一个例子是公共交通网络。 设计是由人产生的，参与设计的人员组成设计组织。
设计的定义本身就很有趣
那种从其不同部分创造整体的智力活动可以称为系统设计。
当我思考设计时，我更自然地从另一个角度思考：如何将整体分解为一组可以协同工作以实现系统目标的部分。 当然，康威是对的，这些部分确实必须组合在一起才能再次产生预期的整体。
在设计过程开始时需要两个方面的知识
• 对系统边界（以及对设计和开发过程的任何限制）的（初步）理解——哪些在范围内，哪些在范围外。
• 系统如何组织的初步概念。 没有这个，你就无法开始分解设计工作。
在对系统有了初步了解之后，就可以开始组织设计团队了。 在信息有限的早期阶段做出的决策可能会产生持久的影响
……组织设计团队的行为本身就意味着某些设计决策已经做出，无论是明确的还是其他的。 给定任何设计团队组织，都有一类设计方案无法被这样的组织有效地追求，因为必要的沟通路径不存在。 因此，不存在既有组织又有公正性的设计团队。
如今，拥有专门的设计团队的可能性较小——即使是看似显而易见的在构建之前（至少部分地）设计某些东西的说法也可能感觉像是一个有争议的说法。 但是，当然，人们一直都在进行设计活动，也许是非正式的和隐含的，有时则更明确。 他们只是学会了在获得反馈之前，在每个设计增量中采取更小的步骤。 然后，在软件环境中，每次康威谈到“设计和设计组织”时，在脑海中将“设计和开发”替换为“设计和开发”会更有意义。
一旦完成设计（和开发）团队的初步组织，就可以开始委派任务。 每次委派都代表着某人范围的缩小，以及可以考虑的设计方案类别的相应缩小。 随着个人范围的缩小，还存在协调问题
小组之间的协调，虽然表面上降低了小组内个人的生产力，但提供了各个任务小组能够将其努力整合到统一的系统设计中的唯一可能性。
即使有新发现的信息表明有更好的选择，也很少有团队会根据这些信息进行重组。
这种观点产生了这样的观察：永远没有足够的时间把事情做对，但总是有足够的时间重新做一遍。
设计师工具箱中最基本的两个工具是分解和组合。 整个系统被分解为相互连接（组合）的较小子系统。 这些子系统中的每一个又可以进一步分解为零件并由零件组成。 最终，达到一个足够简单的级别，无需进一步细分即可理解。 因此，设计师可以做出的最重要的决定涉及将系统分解为模块的标准，但这又是另一个故事了。
不同的子系统通过接口（1968 年新出现的术语）相互通信。 现在，如果您考虑由通过接口交互的子系统组成的系统，您会在组织中找到一个并行，方法是进行以下替换
• 将系统替换为委员会。
• 将子系统替换为小组委员会。
• 将接口替换为协调员。
用更现代的术语来说，我认为你也可以
• 将系统替换为组。
• 将子系统替换为团队。
• 将接口替换为团队领导。
现在我们可以解决本文的基本问题了。 设计组织的图结构与其设计的系统的图结构之间是否存在任何可预测的关系？ 答案是：是的，这种关系非常简单，以至于在某些情况下它是一种恒等关系……事物两组之间保持这种结构的关系称为同态。
到目前为止，我最喜欢这篇论文的后半部分，其中详细阐述了这种同态的含义。 实际上是 Fred Brooks 在人月神话中提到这篇论文时，创造了康威定律这个术语。 当然，关于人（人）月的神话之处在于，人月是可以替代的商品的错觉——从管理的角度来看，这是一个诱人的想法，但完全错误。 康威解释了原因。 资源单位的观点会说，两个人工作一年，或 100 个人工作一周具有相同的价值……
假设两个人和一百个人不能在相同的组织结构中工作（这是直观明显的，将在下面讨论），我们的同态性表明他们不会设计相似的系统； 因此，他们的努力的价值甚至可能不具有可比性。 从经验中我们知道，如果选择得当且能经受住考验，两个人会给我们带来更好的系统。 对于削土豆和砌砖墙可能足够的假设，对于设计系统则不适用。
每个人都在某种程度上理解这一点，但很容易忘记。 此外，还有一些组织力量在与你作对
1. 你很早就意识到系统会很大，这意味着用当前的团队规模进行设计将花费比你希望的更多的时间。 然后，组织压力开始发挥作用，以“使给设计工作分配过多的人员的诱惑变得不可抗拒”。
2. 随着你增加人员，并将传统的管理结构应用于他们的组织，组织沟通结构开始瓦解。 （康威指的是军事风格的组织结构，即每个人最多只有一个上级，并且最多大约有七个下属——这几乎仍然是今天使用的经验法则。）
3. 然后，同态性确保系统的结构将反映设计组织中发生的瓦解。
关键时刻出现在复杂性尚未被驯服，并且初始设计师的技能正在接受最大程度的考验时
当系统的表面复杂性接近他的理解极限时，初始设计师——其初步设计概念影响设计工作组织的设计师——自然会倾向于委派任务。 这是设计过程中的转折点。 他要么努力将系统简化到可理解的程度并取得胜利，要么失去对系统的控制。
一旦组织配备了人员并建立起来，它就会被使用。 组织具有令人难以置信的自我保护能力。
现在存在的许多设计不良的系统背后可能最大的共同因素是需要工作的设计组织的可用性。
我一直偏爱由高技能人员组成的小团队，而不是更大的团队。 在整理这份文稿时重温康威定律，我最深刻的印象是，更经常被忽视的观察结果是，设计组织结构不仅指导设计，而且实际上限制了可以考虑的设计集。 你添加的每个人都会减少你的设计选择。
因此，也许最重要的概念是“保持设计组织精简和灵活”。 组织的灵活性对于有效的设计非常重要，因为你现在拥有的设计很少是永远最好的。
最后，在倒数第三段中，是已知的康威定律的表述
本文的基本表述是，设计系统（此处使用的广义）的组织必然会产生与其组织沟通结构相同的设计。
自动化的讽刺
Bainbridge, L. 1983. 自动化的讽刺。 Automatica 19(6);
https://www.ise.ncsu.edu/wp-content/uploads/2017/02/Bainbridge_1983_Automatica.pdf.
感谢 Thomas Depierre 推荐这篇论文。
做出预测是一场危险的游戏，但当我们展望未来十年时，似乎有几件事是肯定的：自动化程度提高、系统复杂性增加、处理速度更快、互连性更强，以及人类和社会对技术的依赖性更大。 可能会出什么问题？ 自动化本应让我们的生活更轻松，但当它出错时，它会让我们陷入非常被动的境地。 “自动化的讽刺”探讨了这些问题。 该论文最初发表于 1983 年，提出的教训与今天一样具有现实意义。
本文中提到的中心讽刺（情况的组合，其结果与可能预期的结果截然相反）是，我们自动化程度越高，自动化越复杂，我们就越依赖于高技能的人工操作员。
自动化系统需要高技能操作员
我们为什么要自动化？
设计师对人工操作员的看法可能是，操作员不可靠且效率低下，因此应从系统中消除。
自动化系统不会像人工操作员那样犯错误，并且它可以比人工操作员以更高的速度和/或更低的成本运行。 该论文假设一个世界，其中每个自动化任务以前都是由人类承担的（背景是工业控制系统），但当然今天许多系统都是天生自动化的。 我在阅读本文时发现自己思考的一个例子确实具有人类先例：自动驾驶汽车。
在自动化系统中，人类只剩下两个角色：监控自动化系统是否正常运行，以及在系统不正常运行时接管控制。 如果操作员不经常操作系统，那么一旦被要求接管，他们的技能就会萎缩。
不幸的是，身体技能在不使用时会退化，尤其是增益和定时的改进。 这意味着，曾经经验丰富的操作员，在监控自动化过程后，现在可能是一个没有经验的操作员。
不仅操作员的技能在下降，而且操作员将被要求介入的情况本身就是最苛刻的情况，即某些事情被认为正在出错。 因此，在这种情况下真正需要的是更熟练的操作员，而不是不太熟练的操作员。 为了为不寻常的情况制定成功的策略，操作员还需要很好地理解受控过程和系统的当前状态。 前者的理解最有效地通过使用和反馈来发展（操作员可能不再有定期获得这种机会）； 后者需要一些时间来消化。
我们已经看到接管控制是有问题的，但监控（导致决定接管控制）也存在问题。 例如，在依靠人类驾驶员在紧急情况下接管自动驾驶汽车的控制之前，请考虑以下事项
我们从许多“警惕性”研究（Mackworth，1950）中了解到，即使是积极性很高的人，也不可能对很少发生信息源保持有效的视觉注意力超过大约半小时。 这意味着人类不可能执行监控不太可能发生的异常的基本功能，因此必须由连接到声音信号的自动警报系统来完成……
但是谁会注意到警报系统何时工作不正常？ 你可能需要在警报器上安装警报器。 本文的 2.1 节有一个很好的章节，讨论了我们现在称之为灰度故障的挑战
不幸的是，自动控制可以通过控制变量变化来“伪装”系统故障，从而使趋势在失控之前不会变得明显。 这意味着自动化系统还应监控异常的价值变动。 “性能的平稳降级”在“菲茨清单”中被引用为人优于机器的优势。 这不是计算机性能的目标方面，因为它可能会引发监控故障的问题； 自动系统应该明显地发生故障。
一种可行的直接解决方案是自动关闭。 但是许多系统“由于复杂性、成本或其他因素”必须稳定而不是关闭。 如果可能发生非常快速的故障，并且没有来自先前变化的警告，从而使操作员的工作记忆无法跟上速度，那么可靠的自动响应是必要的； 如果这不可能，那么如果故障成本是不可接受的，则不应构建该过程。
我们能做些什么来解决这个问题？
一种可能性是允许操作员在每个班次中使用手动控制一小段时间。 如果这个建议很可笑，那么必须提供模拟器练习。
混沌实验和游戏日是当今使用的一些技术，旨在让操作员获得在各种场景下使用系统的经验。 模拟器可以帮助教授基本技能，但始终会受到限制：“未知故障无法模拟，并且系统行为可能不适用于可以预测但尚未经历过的故障。”
没有人可以被教导关于系统的未知属性，但他们可以被教导练习使用已知信息解决问题。
本文撰写时的一项新创新是使用“VDU [视频显示单元] 上的软显示器”来设计特定于任务的显示器。 但是更改显示器会带来自身的挑战。 Bainbridge 提出了三点建议
• 对于每种无法简单地映射到其他类型的信息，应至少有一个永久可用的信息来源。
• 操作员不应在显示器之间翻页以获取有关他们当前正在考虑的过程部分以外的其他部分中的异常状态的信息，也不应在显示器之间翻页以获取一个决策过程内所需的信息。
• 对复杂显示器的研究应侧重于确保它们之间兼容性的问题，而不是在不考虑其与其他功能信息关系的情况下，找到哪种独立显示器最适合特定功能。
在许多情况下，很可能最终会处于计算机控制系统某些方面，而人工操作员控制其他方面的境地。 这里的关键是，人类必须始终知道计算机正在处理哪些任务以及如何处理。
也许最后的讽刺是，最成功的自动化系统，几乎不需要人工干预，可能需要对人工操作员培训进行最大的投资…… 我希望本文已经清楚地说明了，自动化本身并不一定能消除困难，而且解决这些困难可能需要比经典自动化更大的技术独创性。
这让我想起了 Kernighan 定律（“调试的难度是编写代码的两倍。 因此，如果你尽可能聪明地编写代码，那么根据定义，你就不够聪明来调试它。”）。 如果你将自己推向自动化系统的技术能力的极限，那么你将如何管理它？
Adrian Colyer 是伦敦 Accel 的风险合伙人，他的工作是帮助在欧洲和以色列寻找和建立伟大的科技公司。 （如果您正在从事有趣的科技相关业务，他很乐意收到您的来信：[email protected]。）在加入 Accel 之前，他在技术岗位工作了 20 多年，包括担任 Pivotal、VMware 和 SpringSource 的 CTO。
版权所有 © 2020，所有者/作者所有。 出版权已许可给 。
经许可转载自 https://blog.acolyer.org
最初发表于 Queue 第 18 卷，第 1 期—
在 数字图书馆 中评论本文
更多相关文章
Catherine Hayes, David Malone - 质疑评估非密码哈希函数的标准
尽管密码哈希函数和非密码哈希函数无处不在，但在它们的设计方式上似乎存在差距。 针对各种安全要求，存在许多针对密码哈希函数的标准，但在非密码方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。 虽然针对真实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。 直观地看，技术领导者普遍认为，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。 然而，在许多组织中，旨在改进 DevEx 的拟议计划和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果，研究生产力差异，从而为该主题提供新的见解。 低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。 本文报告了程序和协议、结果、局限性和未来研究的机会。
Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和方法来服务于商业和社会，但它也很健忘。 为了快速前进，它容易受到时尚的突发奇想的影响，并且可能会忘记或忽略针对它面临的一些永恒问题的成熟解决方案。 用例于 1986 年首次引入，后来普及，是这些成熟的解决方案之一。
© 保留所有权利。