本节书摘来自异步社区《软件工艺》一书中的第1章软件工程的困境，作者【美】Pete McBreen，更多章节内容可以访问云栖社区“异步社区”公众号查看。
第 2 章 软件工程的困境
软件工艺
软件工程存在的最大问题就是：它假设那种“有组织、有纪律、可计量的开发方式”是唯一可行的方式。软件工程实际上是把工程学的隐喻强加于软件开发之上，从而使我们一叶障目不见泰山，看不到其他开发方式的存在。有一个例子能够将这一问题彰显无遗，那就是软件工程中的“缺陷可能性”和“缺陷排除率”这两个概念：
缺陷可能性：软件项目中预期可能存在的全部错误和缺陷。
缺陷排除率：在将软件项目发布给消费者之前，被排除的缺陷占潜在缺陷总数的百分比。1
这种机械的观点忽略了一个事实：越好的程序员，所犯的错误就越少，并且发现错误也越快。教条主义的软件工程使我们忘记了软件的本质：真正决定项目成败的，是作为个体的程序员的技能、知识和经验。
Bill Curtis等人对大型软件工程项目进行了一组意义深远的现场调研。从这些调研结果中，我们可以清楚地看到杰出的设计师作为个体对整个项目所做的贡献以及他们的重要性：
每个项目组中都会有这样的一两个人。他们通常是资深系统工程师，他们在系统的设计中承担主要责任。在我们研究过的所有项目中，大约有三分之一的项目存在这样的情况：某一个人对整个项目起主导作用，项目的发展方向由他决定，项目的成果依赖于他的工作成果。有时候，项目组的其他成员甚至会将他称为“救世主”。这些真正杰出的设计师拥有的应用领域知识比其他同事丰富得多，因此，在我们的研究结果中，他们显得格外出类拔萃。他们是项目的一种稀缺资源。2
随后，这份研究报告还写道：
软件开发的传统观点往往认为：软件项目的成败不应该依赖于某个关键人物的发挥。但是，很多成功的大型项目的经验却告诉我们：这种理论一旦被用于实践，可谓贻害无穷。优秀的设计师拥有的领域知识不论在深度上还是在广度上都胜人一筹，而这些知识很难通过一组设计过程获得。所以，优秀的设计师的确是不可或缺、不可替代的。3
在期盼通过工程学的超度而达到“有组织、有纪律、可计量的开发方式”时，我们逐渐地迷惑了自己的头脑。其实，我们应该讨论的不是“项目的缺陷可能性”，而是“开发者的缺陷可能性”。
道理很简单：优秀的设计师所犯的错误要比他的同事们少得多，因此优秀设计师的“缺陷可能性”就比较低；同时，优秀的设计师也能够更快地发现系统中的缺陷，因此他的“缺陷排除率”也比较高。对此，Fred Brooks早已作出了精辟的论断：
……系统应该由尽可能少的人员来开发。实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是缺乏概念完整性的产品。……得出的结论很简单：如果在一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。4
简而言之，软件工程的关键问题就在于：它使我们忘记了“是人来开发软件”这样一个简单的事实。软件工程含蓄地给了我们一个承诺：只要能定义出一个有组织、有纪律、可计量的开发过程，任何人都可以成功地完成软件开发。可惜，这只能是一个梦想。正如Curtis的调研报告所表明的：就算有了一个理想的过程，想要获得项目的成功，出类拔萃的开发者仍然是必不可少的。所以，我们有必要认真考虑这样一个问题：如何培养软件开发者，才能使他们也有可能出类拔萃？不过，在回答这个问题之前，我们需要先解决另一个问题：所谓“有组织的软件开发过程”，究竟意味着什么？
1 Jones Capers，《软件质量》（Software Quality），ITP，1997，p.331-332。
2 Bill Curtis，Herb Krasner及Neil Iscoe，《对大型系统软件设计过程的现场调研》（A Field Study of the Software Design Process for Large Systems）。见《ACM通讯》（Communications of the ACM）1988年11月号，pp. 1268-1287，p. 1271。
3 Curtis，《对大型系统软件设计过程的现场调研》，p. 1272。
4 Brooks，《人月神话》，p. 130。或见中译本第34至35页。
