三、《人月神話》是預言了未來還是控制了未來？
事實是：我們現在的很多工程知識，——無論是從書上看到的，還是從實踐中體驗到的——大多未曾脫離《人月神話》之所言。
我在開篇中說《人月神話》“是一本可怕的書”。然而我認爲真正的可怕之處在於：如今只要論及工程（且不要讓人認爲是離經叛道），那麼所講述的一定是 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就說過“沒有銀彈”嘛。