软件的魔力：或者说，优秀的工程师造就优秀的工程组织

2024年9月23日

创造软件的人通常自称为软件_工程师_，然而，如果他们从大学毕业，通常会获得计算机_科学_学位。我一直觉得这有点奇怪，因为科学和工程是两个非常不同的学科，但我们似乎在很大程度上理所当然地接受了这种明显的矛盾。然而，我认为软件有一种独特的魔力，而这种魔力可能源于我们定义它的这种紧张关系。

乍一看，软件似乎是一种直接的_工程_实践。毕竟，它存在于一个完全已知的宇宙中——计算机——由我们自己创造。这与那些更明显是_科学_的学科形成了鲜明对比，比如生物学或物理学，它们存在于我们没有创造且没有完全理解的领域中。与完全被理解的计算机不同，这些学科在很大程度上是关于_寻找_理解。换句话说，科学通常致力于发现事物如何运作的过程——而我们不需要对计算机做这些。

既然我们了解关于计算机的一切，并且不需要发现它的运作方式，那么软件似乎就简单得多。既然没有什么需要发现的，我们可以说软件是一种工程实践，即结合和组装来自复杂计算系统的可用资源，以实现给定的愿景。

从愿景开始，然后进行工程以实现该愿景。

但是，我不相信这就是全部。我想表明，软件中愿景和工程之间的关系通常是相互交织和双向的，而不是线性的，并且即使它存在于一个完全已知的宇宙中，整个软件开发实际上也充满了发现。

愿景和工程之间更相互交织和双向的关系。

考虑一下我在最初对软件产生兴趣的那个时代的这些计算机图形动画：

这些动画来自一个非常原始的时代，但它们却美丽而引人注目。对我来说，这些动画的有趣之处在于，它们实际上并没有“动画化”——至少不是按照传统意义上的动画化，即每秒计算和渲染每个像素的值 30 次。当然，考虑到所有动态运动，看起来好像就是这样，但根据当时的硬件限制，这在当时是不可行的。

相反，这些实际上是_图像_，它们使用了一种称为 color cycling 的技术。 Color cycling 利用了诸如 VGA 之类的图形系统使用“索引”颜色的事实。索引颜色系统是一种内存优化技术，用于用单个 1 字节颜色值（而不是完整的 3 字节 RGB 值）表示屏幕上的每个像素，以及一个单独的“调色板”，该调色板将这些 1 字节颜色值映射到完整的 3 字节 RGB 值。

每个像素都可以用 1 字节的颜色值表示。 一个单独的表将 1 字节颜色索引映射到 3 字节 RGB 值。 为每个像素渲染生成的颜色。

一个了解索引颜色系统如何工作的人意识到，通过为图像仔细指定颜色值，然后智能地 循环调色板中的 256 种颜色 来创建动画的外观，就可以创建令人印象深刻（在当时）的视频效果。

结合这样的技巧才使得著名的 Amiga boing ball demo 得以实现：

我认为这是一个有些不明显的结果。索引颜色系统不是为此目的而创建的，但_理解_它们的软件开发人员能够使用它们来创造出意想不到的伟大事物。

总的来说，计算是无数不明显结果的历史。我的意思是，如果我在这一切的开始就在那里，我不确定我会预测到通过快速打开和关闭电源，我们可以得到……所有这些？

与纯科学学科非常相似，软件的历史一直是一部发现的历史。然而，虽然理解是生物学或物理学中发现的_对象_，但在软件中，理解和工程通常是发现的_基础_。虽然软件开发确实是结合和组装资源以实现给定愿景的过程，但对资源及其所有使用方式的深刻理解也以双向关系_告知_愿景。它并不总是像从一个愿景开始，然后使用可用的资源来构建它那么简单。它们通常一起出现或以交织的方式出现，事物不断地向前跳跃。

如果我们将上面的动画视为软件产品，那么很明显，该产品并非始于某人对看起来像这样的动画的愿景。正是对工程的理解告知了愿景，反之亦然。

我使用 color cycling 作为一个例子，因为它具有视觉效果并且非常古老，以至于不会引起争议，但这是我在参与软件的过程中一遍又一遍地看到的模式：对工具和技术的深刻理解会产生新的愿景、意想不到的结果、洞察力或某种解决方案（无论大小！）。这并不总是意味着新产品或演示，而且通常只是一个项目中的进步，只有一小部分人会注意到，但它几乎总是从_理解_部分开始。

我觉得我们可能正在忽视理解部分。

抽象：构建更多，创造更少

软件开发受益于依赖于抽象层。每次需要将数据存储到磁盘时都必须实现与将数据存储到磁盘相关联的所有逻辑将是极其困难的，因此将其抽象到可重用的存储接口（如 RDBMS 或 KV 存储）中当然是非常有价值的。对于 HTTP 库、套接字接口、C 编译器、游戏引擎或任何其他抽象层的值也可以这样说。

但是，有两种与抽象层交互的方式：作为对您代表您执行的操作的理解的_简写_，或者作为_黑盒_。我认为，当抽象层充当简写而不是黑盒时，工程师的能力最强，效率最高。计算非常复杂，这些接口永远不会完全干净（而且永远不会），因此将它们用作黑盒而不了解其中发生了什么会导致负面结果，这些负面结果会随着应用程序的大小/复杂性/规模而复合。

大多数使用软件的人通常对此有所了解。但对我来说，似乎还有更多的事情正在发生，这与工程和愿景之间相互交织的关系有关：当我们把一切都看作是黑盒时，就很难有任何愿景。

例如，有时我们创建抽象层，允许人们在它们之上显式地创建东西，而不必理解它们之下的任何东西。我们将这些称为“平台”。期望是，当我们创建这样的抽象层时，我们应该看到创造力的爆发，因为现在人们可以只关注要构建的东西的创意方面，而不是如何构建它的技术方面。

对于计算之外的一些努力来说，这似乎显然是正确的：电影制作人可以使用相机来制作出色的电影，而无需详细了解如何构建相机，并且对相机工作原理的了解与最终电影的质量之间可能没有太多可预测的关系。我们可能会试图将此推断到计算世界中，并说通过创建像游戏引擎这样的东西，我们应该期望看到游戏中创造力的爆发，因为现在游戏制作者可以专注于构建游戏的创意方面，而不必了解如何构建游戏的技术方面——就像电影制作人不必构建相机一样。

但是，我认为这些比喻的问题在于，相机实际上并不是电影的抽象层。一个故事不仅仅是放在相机之上。电影制作人_确实_需要了解很多其他非常复杂的东西才能将故事变为现实。

当我们在计算领域应用这种逻辑，通过创建显式的黑盒抽象层时，我认为我们确实看到了_更多东西_的爆炸式增长，但通常是_更多平庸的东西_。

随着我们让构建游戏变得更容易，我们肯定看到了更多的游戏。但是，高评价游戏的数量（在本例中由 metacritic 记录）似乎并没有随着时间的推移而增加。

对我来说，在像计算这样复杂的生态系统中，在深刻理解我们用来创造事物的功能的工具与我们最终获得的输出的质量或创造力之间，似乎存在某种持续的关系。

我认为只有当我们真正理解我们必须用什么来创造时，我们才能真正创造。

当团队变成特百惠：密封严密，内部陈腐

也许这很明显，但我认为这适用于整个软件行业的各种元方式。例如，我认为造就优秀工程师的许多动态也造就了优秀的工程组织。

如今，工程组织已经膨胀到庞大的人数，但这些庞大的工程组织并没有以高速产出而闻名。其中一些是产品大规模化带来的结果：从根本上说，迭代、改进或更改拥有 100 个用户的产品比对拥有 1 亿用户的产品做同样的事情更快、更容易。

但是，在了解了一些大型工程组织之后，我不认为这解释了一切。

如今，大多数管理或构建工程团队的人都拥有一种熟悉的管理理念。一般的论点是，等级决策——信息以报告、摘要和执行摘要的形式向上流动，然后以预算、人员编制和优先级的形式向下流动——太慢了。

相反，现在更普遍的观点是，组织应该由自治团队组成，而组织中领导者的职能是在所有这些团队之间创建“对齐”，确保他们朝着同一个愿景朝着同一个方向前进：

--->

乍一看，这两种思考组织的方式（自治与等级）似乎真的不同。但是，在一个方面，它们本质上是相同的：

两者都假设愿景和工程之间存在相对单向的关系。实质性的区别在于执行的组织方式，但两者都没有为工程和愿景之间双向关系的出现留下太多空间。

为了加剧这种情况，将工程师组织到孤岛中与为组织创建抽象层非常相似，几乎就像微服务架构一样。不幸的是，这些抽象几乎总是被同级团队和领导团队视为黑盒，而且就像在软件中一样，生活在黑盒抽象的世界中会使任何人难以获得真正出色成果所必需的洞察力。

在考虑工程组织的功效时，我喜欢应用的一个思想实验是想象它是“移动”时代的黎明时的 Skype。想象一下您正在运行 Skype，您将所有这些人隔离到自治团队中，并且您有远见看到移动将有多么重要。因此，您要确保每个人都对移动作为组织的关键、第一、绝对存在的优先事项保持一致。

即使每个人都保持一致，适应移动也是一项艰巨的任务。现有产品在各个层面上都 100% 围绕桌面模型进行组织。UX 以“在线”或“离线”的概念为中心，而这种概念在移动环境中已不复存在。通信协议是一种半分布式网格，它依赖于能够在桌面操作系统上的“后台”中运行，这在移动设备上根本无法运行。代码库的编写方式无法在移动操作系统上部署，等等。

显然，事情需要改变。几乎所有事情都需要改变。但是，每个团队需要进行的更改_取决于每个其他团队需要进行的更改_。产品愿景本身是相互交织的，并且从工程方面以双向的方式告知，但是如果组织中的每个人都将组织的每个其他部分视为黑盒抽象层，那么我认为这样的更改不会发生。

虽然像移动革命这样的巨大转变可能很少见，但我认为那些没有能力进行根本性变革的组织即使在稳定时期也可能表现不佳。就像软件一样，深刻的理解通常是发现的基础，一个组织必须真正了解自己才能为创新做好准备。当团队以不可渗透的黑盒形式运作时，愿景就会变得短视，潜力就会枯萎。尽管拥有巨大的人才，但 SV 的大型工程组织通常以孤立专业知识的方式构建自己。因此，他们可能拥有大量尚未开发的潜力——永远无法连接的创造性和技术想法。

水果圈和虚假偶像

我注意到，有抱负的企业家经常专注于研究成功企业家的_当前_习惯，希望模仿他们的成就。这种逻辑的问题在于，现在，无论是 Jeff Bezos 每天早上 5 点开始用冷水浸泡，还是在早上 10 点吃一碗水果圈，都可能对其公司的结果影响甚微。如果模仿真的是目标，人们可能应该看看他 1994 年在做什么——这可能只是痴迷地工作，损害了一切。

我认为对于我们如何看待工程组织也存在类似的谬误。如今的许多“最佳实践”都是从像 Google 这样历史悠久的互联网公司中汲取的。但是，根据他们取得的成功来复制他们目前的做法的问题在于，这些公司中的大多数公司都找到了几乎无懈可击的商业模式，这些商业模式基本上是在印钞票，因此，几乎任何组织或管理实践，无论是以随机方式开发还是选择的，都可能会在某种程度上继续“成功”。在没有太多选择压力的情况下，我认为在这些公司中发展起来的实践和文化更多地反映了为各种决策者谋取利益的优化，而不是为实际创造伟大事物而进行的优化。最明显的例子是组织本身的规模，我认为这通常更多地是由于招聘经理拥有更多“下属”而不是与能力、能力或速度的任何实际关系而获得的好处。

来自这些公司的人成为新公司的管理层，在那里学习的人成为其他新公司的管理层，最终我们忘记了在这一切之前还有其他做事方式。

如果您今天正在建立公司或工程团队，我认为真正的机会在于了解您不受已作为“标准”传递下来的惯例的约束。

造就优秀工程师的品质通常与造就优秀工程组织的品质相同。两者都始于深刻的理解，以此作为创新的基础——培养对黑盒内部进行观察的好奇心。两者都认识到愿景和工程通常是紧密相连且相互告知的，而不是线性的。软件和软件组织的魔力都来自对事物如何运作的洞察力激发了关于它可能成为什么的全新想法的时刻。

© 2012 Moxie Marlinspike