神品—— 代序*
這是本書中的一節廢話。*
我是一個書狂，積習甚深，費盡心機在軟件工程、繫統工程方面積累了一些書。書，在我看來當分為神品、精品和普通三等，其中神品、精品又分別有一、二和三品之分。我所收集的書中，軟件工程書大都屬於精品，神品隻有兩本，Frederick P. Brooks的這本書就屬於神品之列。
軟件作為一個行業，逐步背起了“solving the wrong problem”(解決錯誤的問題)的名聲。問題決定解決方案，這也就是說，我們一直在制造錯誤解決方案！這方面有大量的證據，其中著名的是美國政府統計署(GAO)的數據：全球的軟件消費商(美國軍方)每年要花費數購買軟件，而在其所購軟件中，可直接使用的隻占2%，另外3%需要做一些修改，其餘95%都成了垃圾。一句話，不管這些軟件是否符合需求規格，它們都顯然沒有滿足客戶的需求。面向對像技術並沒有給我們帶來“神奇的效應”，不管開發商如何吹噓面向對像OO(Object-Oriented)工具多麼，也不管那些OO狂熱者多麼毅然地前赴後繼，這方面的數據從20世紀80年代以來並沒有發生大的改觀。
這實在令我們的軟件工程專家和從業人員們羞愧，因為它揭示了我們可能一開始就從根本上做錯了什麼！20世紀90年代中期，當軟件工程一代宗師Michael Jackson(非歌壇巨星Michael Jackson)宣布他們的研究結果時，立刻在軟件工程界激起了陣陣漣漪。Jackson指出，軟件從業人員和方法學大師們隻是簡單地模仿和照搬其他學科的方法，卻將重要的方面(問題域)忽略了。他指出，面向對像方法和結構化方法對問題域的處理沒有什麼大的區別，卻被人們過分地用美好的詞彙美化了：
“...You can see the results clearly in many object-oriented modeling descriptions. Often they are accompanied by fine words about modeling the real world. But when you look closely you can see that they are really descriptions of programming objects, pure and simple. Any similarity to real-world objects, living or dead, is purely coincidental...”
(……從眾多面向對像建模的描述中，你可以很清楚地看到這些惡果。而且它們還經常伴隨著有關現實世界建模的非常美好的詞彙。然而，仔細看看，你就會發現它們其實是徹頭徹尾的編程對像！如果說有任何和現實世界對像相似的地方，不管是死是活，純屬巧合……)
回首軟件工程近40年的發展，Jackson哀嘆軟件行業普遍缺乏專業性，充滿了業餘人員，“手中有一個錘子，看到什麼都是釘子”，誰都可以開發性命攸關的軟件。
這就是我們面臨的嚴峻而復雜的現實，也許您會感到震驚！然而在大師Frederick P. Brooks眼裡，是那麼的平靜。因為早在28年前，他就在《人月神話》(The Mythical Man-Month)這本不朽著作中對這些內容做了深入論述。
這本小冊子行文優美，思想博大精深，字字真言，精讀之有不盡的趣味，藏之又是極珍貴的文獻，名眼高人，自能鋻之。
前些年，一位朋友從印度歸來，說此書在印度極為普及，我也動起筆來，但慚愧終未成正果。汪穎兄素來勤懇，明知此翻譯為“success without applause, diligence without reward”(沒有掌聲的成功，沒有回報的勤勉)，卻兢兢業業，反復琢磨，歷經單調、繁瑣、艱辛的勞動，終於付梓。欽佩之餘隨即作序共勉。
Dave Wang
SE Forum China
2002年3月於深圳
20周年紀念版序言
令我驚奇和高興的是，《人月神話》在20年後仍然繼續流行，印數超過了250 000冊。人們經常問，我在1975年提出的觀點和建議，哪些是我仍然堅持的，哪些是已經改變了的，又是怎樣改變的？盡管我在一些講座上也分析過這個問題，但我還是一直想把它寫成文章。
Peter Gordon現在是Addison-Wesley的出版伙伴，他從1980年開始和我共事。他非常有耐心，對我幫助很大。他建議我們準備一個紀念版本。我們決定不對原版本做任何修訂，隻是原封不動地重印(除了一些無足輕重的修正)，並用更新的思想來擴充它。
第16章重印了一篇在1986年IFIPS會議上的論文“沒有銀彈：軟件工程的根本和次要問題”(No Silver Bullet：Essence and Accidents of Software Engineering)。這篇文章來自我在國防科學委員會主持軍用軟件方面研究時的經驗。我當時的研究合作者，也是我的執行秘書，Robert L. Patrick，他幫助我回想和感受那些做過的軟件大項目。1987年，IEEE的《計算機》(Computer)雜志重印了這篇論文，使它傳播得更廣了。
“沒有銀彈”被證明是富有煽動性的，它預言10年內沒有任何編程技巧能夠給軟件的生產率帶來數量級上的提高。10年隻剩下一年了，我的預言看來是安全了。“沒有銀彈”激起了越來越多文字上的劇烈爭論，比《人月神話》還要多。因此在第17章，我對一些公開的批評做了說明，並更新了在1986年提出的觀點。
在準備《人月神話》的回顧和更新時，一直在進行的軟件工程研究和經驗已經批評、證實或否定了少數書中斷言的觀點，也影響了我。剝去輔助的爭論和數據後，把那些觀點粗略地分類，對我來說是很有幫助的。我在第18章列出了這些觀點的概要，希望這些單調的陳述能夠引來爭論和證據，然後得到證實、否定、更新或精煉。
第19章是一篇更新的短文。讀者應該注意的是，新觀點並不像原來的書一樣來自我的親身經歷。我在大學裡工作，而不是在工業界，做的是小規模的項目，而不是大項目。自1986年以來，我就隻是教授軟件工程，不再做這方面的研究。我現在的研究領域是虛擬環境及其應用。
在這次回顧的準備過程中，我找了一些正在軟件工程領域工作的朋友，征求他們現在的觀點。他們很樂意與我分享他們的想法，並仔細地對草稿提出了意見，這些都使我重新受到啟發。感謝Barry Boehm、Ken Brooks、Dick Case、James Coggins、Tom DeMarco、Jim McCarthy、David Parnas、Earl Wheeler和Edward Yourdon。感謝Fay Ward對新的章節進行了出色的技術加工。
感謝我在國防科學委員會軍事軟件工作組的同事Gordon Bell、Bruce Buchanan、Rick Hayes-Roth，特別是David Parnas，感謝他們的洞察力和生動的想法。感謝Rebekah Bierly對第16章的論文進行了技術加工。我把軟件問題分成“根本的”和“次要的”，這是受Nancy Greenwood Brooks的啟發，她在一篇“Suzuki小提琴教育”的論文中應用了這樣的分析方法。
在1975年版本的序言中，Addison-Wesley出版社按規定不允許我在書中向該社的一些扮演了關鍵角色的員工致謝。可是，有兩個人的貢獻必須特別指出：執行編輯Norman Stanton和美術指導Herbert Boes。Boes設計了優雅風格的版式和封面，他在評注時特別提到：“頁邊的空白要寬，字體和版面要有想像力。”更重要的是，他提出了至關重要的建議：為每一章的開頭配一幅圖片(當時我隻有“焦油坑”和“蘭斯大教堂”的圖片)。尋找這些圖片使我多花了一年的時間，但我永遠感激這個忠告。
Soli Deo Gloria—— 願神獨得榮耀。
Frederick P.Brooks, Jr.
Chapel Hill, N.C.
1995年3月
第1版序言
在很多方面，管理一個大型的計算機編程項目與管理其他行業的大型工程很相似—— 比大多數程序員所認為的還要相似；在另外一些方面，它又有差別—— 比大多數職業經理人所認為的差別還要大。
這個領域的知識在於累積。現在，AFIPS(美國信息處理學會聯合會)已經有了一些討論和會議，也出版了一些書籍和論文，但是還沒有成形的方法對這一領域來進行繫統地闡述。提供這樣一本主要反映個人觀點的小書看來是合適的。
雖然我原來從事計算機科學的編程方面的工作，但是在1956—1963年，自動控制程序和高級語言編譯器開發出來的時候，我主要參加的是硬件構架方面的工作。1964年，我成為操作繫統OS/360的經理，我發現前些年的進展使編程世界改變了很多。
雖然是失敗的，但管理OS/360的開發仍是一次很有幫助的經歷。負責這次開發項目的團隊，包括我的繼任經理F. M. Trapnell，有很多值得自豪的東西。該繫統在設計和執行方面都很出色，並被成功地應用到很多領域，特別是設備獨立的輸入輸出和外部庫管理，在很多技術革新中被廣泛復制。現在，這一繫統是十分可靠的，相當有效且非常通用。
但是，並不是所有的努力都是成功的。所有OS/360的用戶很快就能發現它應該能夠做得更好。設計和執行上的缺陷在控制程序中特別普遍，相比之下，語言編譯器就好得多。大多數缺陷發生在1964—1965年的設計階段，所以這肯定是我的責任。此外，這個產品發布推遲了，需要的內存比計劃中的要多，成本也是估計的好幾倍，而且次發布時並不能很好地運行，直到發布了幾次以後，問題纔得以解決。
按照當初接受OS/360任務時的協議，在1965年離開IBM後，我來到Chapel Hill。我開始分析OS/360的經驗，看能不能從中學到什麼管理和技術上的教訓。特別要說明的是，System/360硬件開發和OS/360軟件開發中的管理經驗是大相徑庭的。對Tom Watson關於為什麼編程難以管理的探索性問題，這本書是一份遲來的答案。
在這次探索中，我和1964—1965年的經理助理R. P. Case，還有1965—1968年的經理F. M. Trapnell進行了長談，從中受益很多。我還對比了其他大型編程項目經理的結論，這些項目經理包括M. I. T.的F. J. Corbato，貝爾電話實驗室的V. Vyssotsky和John Harr，International Computers Limited的Charles Portman，蘇聯科學院西伯利亞分部計算實驗室的A. P. Ershov和IBM的A. M. Pietrasanta。
我自己的結論體現在下面的文字中，送給專業程序員、職業經理，特別是程序員的職業經理。
雖然寫出來的是各自獨立的章節，但本書還是有一個中心的論點，特別包含在第2～7章。簡言之，我相信由於人員的分工，大型編程項目踫到的管理問題和小項目踫到的管理問題區別很大；我相信關鍵需要的是維持產品自身的概念完整性。這幾章探討了其中的困難和解決的方法。而後續的章節則探討了軟件工程管理的其他方面。
這個領域的文獻並不多，但散布很廣。因此我嘗試在書後給出了參考文獻，說明某個特定知識點並指導感興趣的讀者去參閱其他有用的文獻。很多朋友讀過了本書的手稿，其中一些朋友還給出了很有幫助的意見。這些意見很有價值，但為了不打亂文字的通順，我把它們作為注解包含在本書中。
因為這本書是一部文集而不是一部教材，所有的參考文獻和注解都被放到書的末尾，建議讀者在讀遍時略去不看。
深深地感謝Sara Elizabeth Moore小姐、David Wagner先生和Rebecca Burris夫人，他們幫助我準備了手稿。感謝Joseph C. Sloane教授在圖解方面的建議。
Frederick P. Brooks, Jr.
Chapel Hill, N.C.
1974年10月
