软件工程已死？

注：本文是一篇译文，原文为著名的博客作家Jeff Atwood在其博客codinghorror上发表。原文链接在这里。我订阅的英文博客不多，主要就是Jeff Atwood和Joel Spolsky。凑巧的是，两个人还合伙办了一个网站，stackoverflow，一个技术类的问题网站，高质量的回答不少，不像某网站都是”顶”、”接分”之类。
我一向认为，对软件项目加注过多的控制和度量本身完全没有意义。说的就是你，PSP/TSP，看谁呢。A/FR，这些真正代表了什么？哦，他们就是一些数字，真的不代表什么。我们总希望开发过程更加透明，让领导们可以对进度一目了然，并可以控制项目。但实际上他们什么也做不了，只能盯着越来越近的项目期限拼命催促程序员加班。软件真的是一门工程吗？也许开发一个公司的主页是吧，但更多的时候，软件开发就像大型手工作坊。前阵子有一本书叫做《走出软件作坊》，可我怎么看软件开发就像手工作坊呢？
对于软件开发，我个人主张从实践入手。大公司先不谈，对于深陷软件危机的小作坊，就像文中提到的这篇文章所言，别去追什么流程，做好SCM，CI和Tracking，这才是他们看得见摸得着的有效招数。而这些东西，都有很好的开源软件。而日常的控制，做一个Scrum Daily就足够了。
小愤了一把，下面是译文：
当我读到Tom Demarco这篇在IEEE杂志上发表的新文章(pdf)的时候，被彻底雷到了。你也来看看：

我一本早期有关度量的书：, Controlling Software Projects: Management, Measurement, and Estimates [1986] ，在许多需要协同的软件项目的度量工作和计划方面起了一些帮助。我不断反思，书中的建议在当时是否正确，在现在是否还有用，并且这些度量是否还是成功的软件开发所一定要拥有的？我现在的答案分别是不，不，还是不。
我逐渐意识到，软件工程的时代一去不复返了。
软件开发现在是而且将来也总是带有一些实验性质的。虽然实际的软件构建并不一定都是实验，但概念上总是。这是我们现在所关注的地方，我们也一直都在关注这点。

如果你被雷焦了，别害怕。我也是。如果想缓解一下读过上面摘要的心情，我强烈推荐扫一扫两页的原文。
Tom DeMarco是当前软件工业立最受尊重的权威之一，合著有大作《人件》以及很多软件项目管理类的经典像《与熊共舞》。从Tom这么一位有才干、经验和影响力的大牛这么直接的说软件工程已死…
嗯，就像基努里维斯说过，whoa
事情很严重，吓死人。
不过，这对我来说也是种释然。压在我胸口的大石头终于被拿走了。我可以宣布最近五到十年来作为一个软件开发者逐渐意识到，我们干的是手工艺，不是工程。我可以大声地、不愧疚地、胸有成竹地这么宣布。
我认为Jole Spolsky，我的合伙人，最近也有类似的顿悟。他在How Hard Could It Be?: The Unproven Path里这么写道：

对于如何开发软件，我自己有非常强烈的主见，但我通常不说出来。这是件好事，因为随着组织逐渐成型，基本上所有的原则都会被抛弃。
不管这意味着什么，我始终要找到答案。我废弃了七个有关业务和软件工程的原则，没什么坏事发生。我过去是不是太过于小心了？也许我打算尽量不莽撞一点因为这仅仅是我的一个编外项目而不是主业。这次的经验告诉我们，当你在构造一个全新的软件时，可以考虑把那些警告都扔一边去。

是的，我还可以再列出一堆关于你现在手头项目细节的软件工程警告出来：类型（性命攸关，显然），规模（Google那样大的，很自然的），受众（每天好几百万，明显），等等。
但我不打算这么做。
DeMarco似乎在说的–至少，我就是这么说的–控制永远是软件开发项目里遥不可及的幻影。如果你想推动你的项目，唯一靠谱的办法就是练就一身更好的软件开发功夫，更好的技艺和职业素质。
天天渴望着修炼技艺，构建对他们自己意义重大的软件的人们，也许就是会取得最后成功的人们。一起成功的还有他们的软件。
其他所有的东西都是扯淡。