喝一口依然还滚烫的咖啡，你决定最后一次检查客户需求。用早餐的位置?有了。四个浴室，其中一个要在天花板上安装花洒淋浴头?有了。三车车库以及宽敞的院子?有了。一切准备就绪，各就各位。最后的审查让你充满自信：想必客户定会满意，施工也马上可以开始。合上笔记本电脑，抓起它走出房门，兴冲冲地想要展示给客户看。
正如你所预期的那样，客户很满意!他对院子的大小很满意，他和他的家人也很喜欢你设计的游泳池和早餐位置。但是美中不足的是….
“你能让它飞起来吗?”
这是工艺，而不是工程
上面的故事显然是荒谬的：只要是思维正常的人都不会要求让房子飞起来，因为我们都见过房子，它们都是不会飞的。然而，这样的情景却经常在软件开发上重演，一遍又一遍。客户要求的东西——他认为是合理的，但对我们开发人员而言可能是完全不可能的——至少目前为止我们清楚这是不可能的事情。现在的软件开发很少有章程，双方协定的标准就更少了。我们能做的，通常就是，创建的东西尽可能地符合客户的期望。
几年前，有一个关于软件开发是否可以被称为软件工程的大辩论，这源于一篇名为《Software Engineering: An Idea Whose Time Has Come and Gone?》的文章，作者是Tom DeMarco。DeMarco认为，短命的软件工程已经死去，这对于所谓软件“变革”的创建并不重要。
DeMarco的论文认为由于缺乏测量力度(和“软件”一词所代表得深度和广度)，软件工程已经走向了灭亡。但是我看到的是一种截然不同的现象：软件工程从未存在过。
首先郑重声明，我赞同DeMarco先生的主要观点。软件开发不是工程，因为在传统的工程中输出是有把握的，且可被反复衡量和控制的。DeMarco的著名论据“你无法控制你不能衡量的东西”是对此理念的完美总结：如果你不能衡量你将要实施的变化的影响，那么让我们怎么相信你能控制它们呢?
这一点，在我看来，正是我们不能将软件开发称为“工程”的首要原因：我们不能衡量将要实施的变化的影响。当然，我们可以执行单元测试，集成测试——我们能想到的所有测试，但我们依然无法准确估计当我们实施所有潜在的变化时，它们对现有系统所造成的影响范围。我们现在根本没有足够的工具来做到这一点，并且据我所知，我们一直以来就没有这样的工具。
我认为软件开发可以当作一门手艺。“工艺”一词或许能够更好地描述我们开发人员的实际工作。
工艺和工程之间的主要区别是，后者使用已经广为人知且公认的知识来解决问题，而前者使用的是更专业的知识，懂这些知识的人不如前者那么多，甚至这些知识可能是不成文的或并不为大众所认同。因此，我们可以得出软件工程一说根本不存在的观点，因为没有足够普遍都接受的知识来证明它可以叫做“工程”。
那么“软件工程”可以存在吗?是否有用?
软件工程这说法是否可行?
假设将软件开发的整个领域转换到工程学科是可能的。然而，我们真的想要这么做吗?
在我看来，创建有用的软件需要具备一定层次的艺术技能，有的形式的创造并不能用数学和工程精确地表现出来。创造力能让我们面对从未见过的问题时，也能想出新颖的解决方案。但是如果我们不小心，它也会让我们搬起石头砸自己的脚。
对我而言，将软件开发制定为工程学科会消弭大量的创造自由(当然并非全部)，从而阻碍我们从多方面思考来解决当前问题。
另一方面，利用工程策略可以显著提高例如标准规格、可测试性，以及项目管理等理念。此外，它提供的公共知识池，可作为使用来源用于参考解决方案，使它们更容易交叉引用。
既然这样，那么共享和控制所有知识是否值得我们失去一些创造的自由?我认为这不值得，哪怕上述权衡真的可以实现。软件可用于所有基本的事情，与其说伟大的多元化思维自由是我们解决问题的阻碍，倒不如说它是福音。如果硬是将软件塞进工程领域，那么就会有太多的变量，太多的问题，太广泛的问题范围需要考虑。对所有软件开发使用工程策略将会是一场灾难。
这篇文章开头的故事，就是一个当我们将软件开发与工程作比较时，常见但不正确的假设：即将软件设计比作是盖房子。这严重偏离了事实。房子是有形的，受到物理定律如重力的约束，并且我们已经拥有了上千年的筑造历史，知道如何建筑适宜居住的房子。而软件是没有这些条件的，因此这样的比较说好听点是天真，说难听点就是误人子弟。
总之，软件开发永远不可能是软件工程。
我们的专业是一门手艺，我们是工匠。软件开发是一个过程，作为程序员的我们吸取关于项目的专业信息和设计内容，然后实施满足客户需求的解决方案。它是艺术，它充满了创造性;它不是工程，它也不需要成为工程。这应该成为我们的共识。
你有什么看法?你认为软件开发成为软件“工程”是一个值得追求的目标，还是一项不可能完成的任务?欢迎分享你的评论，请畅所欲言!
