We Are Not Special (2021)

我们并不特殊 (2021)

This is part two of the crossover project. Part one is here and part three is here. A conference talk based on this work is now available here. 这是跨界工程系列文章的第二部分。第一部分请见此处，第三部分请见此处。基于此项研究的会议演讲现已发布，可点击此处观看。

No one thinks about moving the starting or ending point of the bridge midway through construction. -Justin Cave 没有人会考虑在桥梁施工过程中移动起点或终点。——Justin Cave

I had to move a bridge. -Anonymous1 我不得不移动过一座桥。——匿名人士1

Carl worked as a mechanical verification engineer: he tested oil rigs to see how much they vibrated. Humans work and live on oil rigs for long stretches of time, and if they vibrate too much it can be impossible to sleep. While rigs are designed to stay below the threshold, the design and the final version often diverge. Carl 曾是一名机械验证工程师：他的工作是测试石油钻井平台的振动幅度。人类需要在钻井平台上长时间工作和生活，如果振动过大，人们将无法入睡。虽然钻井平台在设计时会考虑将振动控制在阈值以下，但设计方案与最终成品往往存在偏差。

Currently, he was explaining how they find oil. After drilling a hole, he said, “you might also want to add other additives, like acid or hazelnut shells, but also-” I stopped him. “Hazelnut shells?” He smiled. “Your oil reservoir is not like a balloon full of oil. It’s more like a porous structure in the rock.” 当时，他正在解释他们是如何寻找石油的。在钻孔后，他说：“你可能还需要添加其他添加剂，比如酸或榛子壳，但还有——” 我打断了他。“榛子壳？” 他笑了笑。“你的油藏不像一个装满油的气球。它更像是岩石中一种多孔的结构。”

When drilling in, you might hit a sudden loss of pressure in the pipe. This is extremely dangerous as you don’t know if you’ve broken into the open ocean or have just hit a local void. In the latter case, digging further and suddenly hitting a high pressure area could destroy the pipe. By pumping in hazelnut shells they can gradually fill in small voids and test if they are still in the structure, gradually equalizing the pressure if they are. According to Carl, oil companies are the biggest purchasers of hazelnut shells in Norway. 在钻探过程中，管道压力可能会突然下降。这极其危险，因为你不知道是钻进了开放海域，还是仅仅碰到了局部空洞。如果是后者，继续挖掘并突然撞击到高压区域可能会摧毁管道。通过泵入榛子壳，他们可以逐渐填补微小的空洞，并测试是否仍在结构内，如果是，则逐渐平衡压力。据 Carl 所说，石油公司是挪威最大的榛子壳采购商。

Debates about traditional versus software engineering revolve around what makes us different. The clichés here come from a different camp than the “what makes an engineer” clichés. The ways people try to define “engineering” often work to marginalize software. Differences like “we don’t have licenses” or “we’re not rigorous” are ways of saying that software is less prestigious, less “good” than traditional engineering. 关于传统工程与软件工程的争论，核心在于我们有何不同。这里的陈词滥调与“什么才算工程师”的陈词滥调来自不同的阵营。人们试图定义“工程”的方式，往往会将软件工程边缘化。“我们没有执照”或“我们不够严谨”之类的差异，实际上是在暗示软件工程不如传统工程那样享有盛誉，或者说不够“好”。

As we saw in the last essay, most of these don’t hold up, and the crossover engineers think the two jobs are much closer in nature than people who have only done one. When people talk about the fundamental differences, in contrast, they’re usually not aiming to delegitimize software development. Rather, the implicit emphasis is on making software “special”. Making software something that can’t be understood by the narrow lens of engineering. 正如我们在上一篇文章中所见，这些观点大多站不住脚，而那些跨界工程师认为，这两份工作在本质上比那些只从事过其中一种工作的人所认为的要接近得多。相比之下，当人们谈论根本差异时，通常并不是为了否定软件开发的合法性。相反，其隐含的重点在于让软件变得“特殊”，使软件成为一种无法用狭隘的工程视角去理解的事物。

I see this as a defense mechanism. If software is so different from trad, then it’s okay for us to “not be engineers”. We can say that, sure, we aren’t planning upfront, but that’s because software requirements change so much faster than everywhere else. We don’t apply engineering because we shouldn’t be applying engineering. A good example of this is the NoEstimates movement: because estimates are difficult to make in software, supposedly unlike trad engineering, we should do away with them entirely. 我认为这是一种防御机制。如果软件与传统工程截然不同，那么我们“不是工程师”也就情有可原了。我们可以说，没错，我们没有进行前期规划，但那是因为软件需求的变化速度远超其他领域。我们不应用工程学，是因为我们本就不该应用它。一个很好的例子是“无估算”（NoEstimates）运动：因为在软件开发中进行估算很困难（据称这与传统工程不同），所以我们应该完全摒弃估算。

There’s just one problem with this: as software engineers, we deeply misunderstand the nature of trad engineering. We are not special. Almost everything we think is unique about software appears in every other field of engineering. The upside of this is that—well, we are not special. Almost everything we think is awful about software is something everyone else struggles with, too. 这其中只有一个问题：作为软件工程师，我们深刻地误解了传统工程的本质。我们并不特殊。我们认为软件所独有的几乎所有特征，在其他每一个工程领域中也都存在。好的一面是——好吧，我们并不特殊。我们认为软件开发中糟糕透顶的每一件事，其实也是其他人正在挣扎面对的问题。

The claimed differences 所谓的差异

There’s a fallacy in comparing “trad”, which is an umbrella of different engineering disciplines, to software. Most arguments about engineering don’t go much beyond “software vs engineering”, or conflate “engineering” with civil engineering. All of the subfields are different, and the qualities of one don’t reflect on the qualities of others. After a few interviews, I settled on a set of “universal” differences to discuss: 将“传统工程”（这是一个涵盖了不同工程学科的总称）与软件工程进行比较存在一个谬误。大多数关于工程的争论都没有超出“软件 vs 工程”的范畴，或者将“工程”与土木工程混为一谈。所有的子领域都是不同的，一个领域的特质并不能反映其他领域的特质。经过几次访谈，我确定了一组“普遍”的差异来进行讨论：

• Traditional engineering is best done in a Waterfall style, while software is best done in an Agile one.
• 传统工程最适合采用瀑布式，而软件工程最适合采用敏捷式。
• Trad engineering is very predictable, while software is very unpredictable.
• 传统工程非常可预测，而软件工程非常不可预测。
• Engineering is mostly about manufacture, while code is mostly about design, because “the code is the design”.
• 工程主要关乎制造，而代码主要关乎设计，因为“代码即设计”。
• Trad engineering is much more rigorous than software engineering is.
• 传统工程比软件工程严谨得多。
• Software moves much faster than traditional engineering does.
• 软件工程的迭代速度远快于传统工程。

These aren’t all wrong. As we’ll see later, there are absolutely some differences between software and trad. But the majority of the differences are “wrong”, or at least lacking critical nuance. 这些观点并非全错。正如我们稍后将看到的，软件工程与传统工程之间确实存在一些差异。但大部分差异要么是“错误”的，要么至少缺乏关键的细微差别。

Traditional is Waterfall, Software is Agile 传统工程是瀑布式，软件工程是敏捷式

If there’s one thing we think is uniquely software, it’s Agile. As it’s told, Agile was a rejection of “Waterfall”, the old paradigm Winston Royce invented in 1970. Royce came up with the Waterfall model to mimic how “real” engineers built buildings. Waterfall says that you should do everything in a strict order, only progressing to the next stage of development when the current stage is completed. You only develop after you complete design, only test after you finish development, etc. This works for “real” engineering but utterly fails for software, where requirements change and often the customer doesn’t know what they want before you build it. So this is rejected by the Agile Manifesto in 2001, and everybody lived happily ever after. 如果说有什么是我们认为软件行业独有的，那就是敏捷开发。按照说法，敏捷是对“瀑布模型”的否定，而瀑布模型是 Winston Royce 在 1970 年发明的旧范式。Royce 提出瀑布模型是为了模仿“真正的”工程师建造建筑物的方式。瀑布模型要求你必须按严格的顺序执行所有操作，只有在当前阶段完成后才能进入下一个开发阶段。你必须在完成设计后才能开发，在完成开发后才能测试，等等。这对于“真正的”工程有效，但对于软件开发却彻底失败了，因为软件需求会发生变化，而且客户往往在产品建成前根本不知道自己想要什么。因此，2001 年的《敏捷宣言》否定了这一点，从此大家过上了幸福的生活。

Of course, this story is more fiction than fact. While Waterfall was a dominant model for some time, it was never quite as strict as we think it was today. Nor was it all that ubiquitous: most developers in the 70s and 80s were either working with an ad hoc plan or working in one of the many, many, many “incremental” models that were in fashion, like the Spiral Model and the V Model. Agile wasn’t a radical shift as much as a natural consequence of the trends at the time. But all that is tangential to the core claim: software engineering is Agile, while trad engineering is Waterfall. And this, unsurprisingly, is a significant oversimplification. It’s true that traditional engineers do a lot more upfront design and spend more time in dedicated testing than software engineers do. But this doesn’t mean they have Waterfall level rigidity, nor does it mean that our Agile is alien to them. Rather, spending a 当然，这个故事虚构的成分多于事实。虽然瀑布模型在一段时间内确实是主导模型，但它从未像我们今天想象的那样严格。它也不像我们认为的那样无处不在：70 年代和 80 年代的多数开发者要么是在按临时计划工作，要么是在使用当时流行的众多“增量”模型中的一种，比如螺旋模型和 V 模型。敏捷与其说是一次激进的转变，不如说是当时趋势的自然结果。但所有这些都与核心主张无关：即软件工程是敏捷的，而传统工程是瀑布式的。不出所料，这是一种严重的过度简化。传统工程师确实比软件工程师做了更多的前期设计，并在专门的测试上花费了更多时间，这是事实。但这并不意味着他们拥有瀑布模型那种程度的僵化，也不意味着我们的敏捷对他们来说是陌生的。相反，花费……