人月神话读后感言2

三、《人月神话》是预言了未来还是控制了未来？

    事实是：我们现在的很多工程知识，——无论是从书上看到的，还是从实践中体验到的——大多未曾脱离《人月神话》之所言。

    我在开篇中说《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于：如今只要论及工程（且不要让人认为是离经叛道），那么所讲述的一定是 Brooks的这样的经验以及由此推出的观点，或者在不违背这些经验和观点上的一些具体的实作方法！我们全然不顾书中所言是现象，还是本质的推论，或者只 是现象归结的一个（未必正确的）答案。尽管这些答案大多数时候都如同预期地出现在你的现实工程中：

    原文中还有许多类似的观点、现象和答案，都成为了现实工程中的既存现象。先民们所说的圣人以及通神者，皆因他们多数时候在正确地预言自己的现实。只有当这 个“多数时候”变成少数的时候，先民们才会置疑圣人和通神者的能力。其实我们知道并没有预言未来的人，大多数时候是两种情形导致的假象：   

    他做出了正确的判断；
    你主观地跟从了他对未来的设定。

    后者是危险的。大师们预言了未来也就改变了未来，即便未来未必“应当”如同他所预言的那样。
 
    但如果这种预言的前提不正确，那么未来必然脱离这种影响而回到它应该的状态上去。如同我们看到的另一些事实一样，有很多现象表明，我们正在回归工程本相的 道路上摸索前进。我们也发现，在大多数情况下，先哲们的预言在实践中被印证着，只是偶尔“不太灵光”。下表则列出一些不同的例子：

注1：我例举了敏捷的一些观点，并不表明我是AP/XP的fans。AP/XP的问题另论，在这里，我只是说明存在一种 不同的思想。
    注2：Brooks后来承认“必须扔弃原型”是一个不太正确的观点。
    注3：Brooks在这里没有犯错误，只是他所讨论的是狭义的流程图，而我们例举的时序图则更广义。
 
    我们回顾上一小节，在《人月神话》中的那“31%的答案”的前提——也就是那7%的本质中，如下两项是明显存疑的（也是主要置疑）：

    目标的本质：是大型工程，是系统项目，而不是程序
    个体的本质：是私利性的

    其实早就有人意识到个体的本质“未必全是私利的”，尊重这些个体就会带来一些效果。例如AP正是因为更尊重开发人员的个性与能力，以及相互间的合作而得到 了效率的提升。

    再进一步地说，既然Brooks设定了“大型工程或系统项目”这样的目标，并给出了一些答案。那么在“小那么一点点的”工程项目中，是不是这些答案就不必 须了呢？例如Brooks的许多建议，对于某些目标——例如你要用为期三个月的时间开发一个的产品——就并不是很有效；或者根本无法实施——例如你的团队 总共只有6个人，连“外科手术式的团队”都组织不起来。

    Brooks的答案对于同样的目标，以及在他所述的“本质”未能发生改变时，还是比较有效（或有实施的可能性）。因此上述一些例外，总是在 上述的“7%的本质”被否定或被改变的情况下获得的。因而我们提出的问题是“如何否定或改变”这些难以撼动的本质。然而在我看来，Brooks早已经在最 佳位置上，给出了撬动它们的一个支点：

    Brooks认为构建“独立小型程序”与“编程系统产品”是不同的问题。

    Brooks讨论的编程系统产品的规模到底有多大呢？我想至少应该是以IBM 360为参考的。不过书中在引用Joel Aron（IBM 在 马里兰州盖兹堡的系统技术主管）的例子时说，“大型意味着程序员 的数目超过25人，将近30,000行的指令”。而按照《人月神话》的数据：人均效率800指令/人年， 则这个“大型项目”应该需要1.5年才能完成。此外，还需要大约一倍的人工，来负责除开代码之外的测试、管理、文档和沟通 等工作。
 
    好的，如果你有一个“(至少)50人，开发一年半”的项目，那么你可以先接受Brooks的答案去实践一下：起码你可以有时间来讨论工程问题，也能够组建 那样规模的团队 。但是，难道只有这样的“大型工程”才算得工程，而“小那么一点点”的就不算吗？现实是，我们一方面在做着 “小那么一点点的”工程项目，另一方面在听着整个业界喧嚣着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”或者“预言”，而 忘却这些答案的前提：

    Brooks的经验源自对IBM 360等大型项目的实践与分析；
    Brooks所述的工程是要得到编程系统产品；

    Brooks认为编程系统产品的工作量可能是独立小型程序的9倍（在实现大致相同功能的情况下）。

    事实上我们现在的软件工程 的发展是被驾驭了，而不是被预言了。从本质上来说，Brooks在《人月神话》中只是讨论了大型工程 的实施，以及相应规模下的团队建设。而我们，便按照这样的设定来铺开了整个软件行业的工程化实施。

    促成这种现状的，并不仅仅是一本书的力量，还在于商业的力量。因为只有在这样铺展开来的行业环境中，才可能有商业机会。——即使那些工程顾问 与实施专家从来没有实施过“50人，开发一年半”这样的项目，只要他们能报出Brooks的名字，能谈及某 些工具在应对“大型项目”中的成功经验，他们就已经成功了一半了。

    为什么“敏捷”之初颇受争议？为什么敏捷对一些中小型的团队显得有效和可实施？为什么当这些争议被摆在眼前的成功平息之后，传统工程的理论家们却不忘恨恨 地评上一句：那是一种不能（或难以）应用于大型工程的方法呢？！
 
    因为如果大家都很“敏捷”，都只做比这些大型工程“小那么一点点”的工程，那么传统工程的专家们就失业了。反过来，只有把工程做大，大到“敏捷”失去了意 义，而“庞大”变成了实质的时候，传统工程就可以为任何失败找到借口：看啊，Brooks就说过“没有银弹”嘛。