1.2.4   软件与工程化

把软件开发视作一个分步骤的博弈是有益处的，因为这样做给了我们一种方式，我们可以按照这种方式对项目做出重要的和有利的决策。相反，把软件开发说成工程化（engineering）或构建模型不能帮助我们做出这样的有利决策。

使用工程作为参考的问题在于：我们作为一个团体，不知道这意味着什么。没有对工程的共同理解，就很难让人们工作得“更工程化一些”。在我的经验中，人们大部分使用工程化一词来建立一种因“没有把某件事做充分，也不清楚某件事是什么”而内疚的感觉。

什么是“工程化”？字典中的定义很清楚，它是：“科学和数学的应用，通过这种应用将自然界中的物质属性和能量源变得对人类有用”（Merriam-Webster誷 Collegiate Dictionary ，第11版，2003）。

这一定义没有解释什么是进行工程化（doing engineering）。在我的经验中，“进行工程化”包括为所面临的相互冲突的需求建立一个折衷的解决方案。然而，另一个人写信给我说：“工程化的基本概念是以可重复的一致的方式来解决问题”。这混淆了进行工程化的行为和进行工程化的结果，这是一个常见的错误。

进行工程化工作的结果是工厂，在工厂运营的时候，会有专门的人仔细监控所生产的产品的质量和数量上的变化。
进行工程化工作的行为是一个未清楚定义的创造性过程，工业的工程师通过这个过程来创造一个制造工厂的设计。这一过程不在统计控制之下进行，也不对产出的质量和数量进行度量。像软件开发一样，它也是一个创造和沟通的博弈，不同背景的人聚集在一起搞出一个可用的设计来。

当人们说“让软件开发更像工程一些”时，他们通常是要说“让它更像经营工厂那样，进行统计方式的质量控制”。但是我们已经看到了，经营工厂并不是进行工程化的行动。

“进行工程化”的另一方面就是：在手册中查找以前的解决方案。

没有人期望设计桥梁的市政工程师能发明一个新的结构。只要指定了河流和预测出的交通流量，他们就会去取土壤样品，然后使用手册来查找一个最简单的结构，用来在检验过的土壤之上跨越给定的距离建立一座能够承受所要求的负载的桥。他们的工作以数百年来众多的已知方案为基础。

这一点勉强符合软件开发的当前状态。我们还处在这样一个阶段：每个团队的设计都应该比别的团队好，而技术在飞快地变化，所以没有现成的参考手册。随着时间的推移，将会出现更多的这种参考手册。然而在今天，系统中的差异仍然比共同点更多。

让我们回过头来把“工程化”视作“思考并做出折衷”。这是更合适的说法。我们愿意让我们的软件开发者思考并理解他们所选择的折中。然而，这种说法不能为管理项目提供指导。