Tom DeMarco是著名的Peopleware: Productive Projects and Teams一书的合著者，然而在这个月，DeMarco向IEEE的计算机协会提出个人意见：软件工程时代结束了。
大多数计算机软件开发者必读书目中都包含Peopleware一书，它于1987年首次出版，1999年再版。
尽管出版多年，Peopleware依然具有重要参考价值，因为它并不注重软件技术本身，而是关注人的因素。
因此，DeMarco给这本书起了一个带People的名字。也许并不像Steve Ballmer，Steve Jobs或者Linus Torvalds这些大师们演讲时拥有那么多粉丝听众，但DeMarco依然是全世界高质量软件开发从业者们执着追随的对象。
一个类似的公告出现在今年7月Computing Now杂志（IEEE计算机协会的出版物）的DeMarco视角专栏，标题为《软件工程：一个过时的概念？》。
这在很多层面上都是很吸引眼球的，除了DeMarco的作者身份以外，标题还蕴含着出人意料的观点：软件工程是一个正在消失的概念。
实际上，DeMarco本人就一直引领着软件工程的现代观念，在Peopleware之前，他写了Controlling Software Projects: Management, Measurement and Estimation（《控制软件开发项目：管理，测算和评价》）一书。
这本1982年销量冠军的第一行文字在接下来的27年中被广泛引用，DeMarco在其中写道：一个人无法控制他不能测算的东西。为了解决这个问题，软件工程师们克服重重困难，勇敢地一次次去分析和揭示一切软件里可能的规律。
可是，随着时间的推移，DeMarco现在显露出对其原先所持观点的不安。
那句引文中（书名也是）暗示了控制是一个重要的方面，他说，也许对任何软件项目来说都是最重要的方面。
但现在不是了。他说，接着举了Google Earth和Wikipedia这两个典型例子，它们都是在发展中不进行多少控制的软件。
为了说明他已改变了的推理，DeMarco引用了两个假定的项目：最后都要花费大约100万美元，但项目A将产生大约110万美元的效益，项目B将产生超过5000万美元的效益。
很明显项目A会有更严格的控制，如果预算超支或软件发布推迟或质量不达标，项目会冒很大的亏损风险。
相比之下，项目B由于投入和产出差异巨大，控制可以很松。很明显的是，在这里面成本、期限和质量问题依然存在，但项目最终会赚钱。如果不赚钱的话，一切都会乱掉。
由此，DeMarco沉思自语道：实际上一位主管越是注重控制，他的团队越是可能在开发一个只能艰难盈利的项目。
接着他说，管理软件开发的问题应该不是关于严格的控制和软件工程所规定的规律，相反，开发团队应当开发产生真正效益的项目，主管应当降低对项目控制的期望。
这是在假设DeMarco以上第一个建议更关注企业领导者或分析师，因为是由他们确定一个软件解决方案是必要的，而不是开发者被指派去编写这些代码。
普通公司里的程序员并没有选择他们开发项目的权利，但显而易见，主管们应该在投入资源开发之前确定一个项目数量上的效益和质量上的效益，他们得在这方面多下功夫。
一个软件工程之父，不停地在告诉人们要放松，不要整天盯着开发项目的成本和时间要求，这听起来让人感到困惑。
为了给他的观点进行辩护，DeMarco拿青少年来做类比。对于青少年，你怎样在他们身上找到一个人无法控制他不能测算的东西的理论依据？例如，一位称职的家长会如何客观地评价他子女的道德水平、教养和同情心？
在这种情况下，你无法控制一个抚养对社会有益成员的育人项目，相反，在软件项目中你管理的是员工，控制的是时间和成本，从根本上说，在这过程中你得尽可能在拥有极少反馈信息的情况下掌控大局。
用同样的方法，一支软件开发团队应当在开发过程中按照相关价值大小、文档和测试结果不断向项目中增加程序块，在项目主管宣布项目完成的任何可能时候都能立刻将产品打包并发布。
DeMarco说，去设计规划一套软件依然有其意义，但那并不是软件工程这个术语所要真正表达的意思，设计策划软件是一整套规则，过程，检视，度量，规划，追踪以及许多其他元素的总和。
几十年来，开发团队们都在成本预算和时间限制上痛苦地挣扎着，但这不该是他们追求的至上目标。
更重要的目标是要转变。DeMarco现在说，去切实改变这个世界或一家公司或它运作的模式才是更重要的。
几乎是为了向自己推行了几十年将工程化原则应用于软件开发的想法表示忏悔，DeMarco说这场转变是我们一向应该关注实施的。
在我个人看来，DeMarco说设计规划一套软件的做法与词语软件开发是不同的，这毫无疑问，的确，有很多人开始怀疑开发软件到底是不是一种包含度量控制和管理控制的工程化实务，而事实却是，软件本身并不像物理学那样有着坚实的科学理论基础，而是充满了抽象的概念，虚幻的构想甚至是一次次的试验研究。
我职业生涯的美好回忆中就有自己提出的解决方案帮助公司进行重大转变的一系列例子，其实谦虚地说，我的这些方案在技术层面上一点也不特别，但它们对公司起到的效果却是立竿见影。这些直到现在我还能如数家珍般列出。
之前我说过这样一个例子，在这个例子中我给那个老板设计了使公司的毛利率报表自动化生成的方案，这确确实实改变了整个公司的文化。现在，这是一个有着巨大甚至是无限价值的软件项目。
具有讽刺意味的是，DeMarco的新式哲学有可能很早以前就存在了。2003年我读了Ed Yourden所著的第二版《Deathmarch》（Deathmarch预示失败的开发项目），惊异于其中一部分内容，在那里面，Yourden试图界定适用于类似Microsoft Word这样巨型开发项目的度量标准。
Yourden详细叙述了他打电话给微软，询问软件有多少行代码的事，结果微软技术服务人员在电话另一头说不知道，他又问这个项目有多少开发人员，答复依然是不知道。Yourden继续问着这些叫人无法回答的问题，最后那个技术服务人员火了：你难道不知道吗？我们卖出了数千万套软件，谁管开发成本是多少？
当然，随着今年早些时候的裁员，微软也许现在会计算成本，但Yourden之类的作者们在最近十年早些时候肯定有证据表明项目的成本和可度量性会随着回报率的升高而重要性降低。
我认为没有人去超越这个观点的原因是众所周知的将软件与已确定的工程化原则相关联的必要性，尽管二者之间存在着明显不同，比方说建造一幢建筑与开发一款文字处理软件。
确实，有人经常说相比一门科学来说，开发软件可能更是一门艺术，我越来越倾向于这种说法。我把它看成是一种工艺，一项技巧，一个创造过程。当编程理论能被教授时，它更像是一套音乐或绘画的理论，除非你有天生的创造表现力，否则你不可能立志要成为有史以来最伟大的程序员或音乐家或艺术家。
与Agile Development严格的瀑布方法论和在它之前的应用程序快速开发（RAD）渐行渐远的当代趋势同样支持了DeMarco的说法：实际上，他发现的事实已在我们身边存在了很多年。
现在的问题是，没人敢站出来大声说：我们不再需要软件工程这个概念！
【编辑推荐】
