Frederick P. Brooks, Jr. - 人月神話

本作是由IBM傳說中的大PM執筆，以作者自己的說法，是一部經驗談。為什麼這麼說呢？因為作者感覺自己還沒辦法為大型軟體設計工程提出一番好的見解，倒是可以把自己所觀察到的工作實況與經驗做為後輩的借鏡。

雖然作者在開頭這麼寫了，但是書中提及的軟體專案管理方法其實非常有用，許多方法不但沿用至今，甚至作為一種核心的理念不斷的進化。

比如在「外科手術團隊」一章介紹了軟體開發的成員類型與職掌，就經常落實在現今的專案之中。其中的「外科醫生」一角，經常是專案中的系統架構師、分析師、設計師或至少是主要的實作人員。而其他成員的工作，分擔枝微末節的工作(也是必須且很重要的工作)，協助「外科醫生」完成「手術」。

文中也提及文件的重要性。至少有兩個章節都在討論文件。而我們也知道文件在現今的軟體開發中佔有重要的角色。除了作為交付給客戶的「證據」之外，文件也成為未來向外擴充或向內維護的重要參考。對此，本文除了說明文件的重要外，也提到文件的管理辦法。許多辦法現在仍然在使用。

在經驗分享的部份。作者提出了兩個有意思的想法，它們都十分有效。首先是軟體開發的專制政治。由於軟體是無形的，(看似)易變 的，因此在概念設計時，容易將創意發散，最終將導致應用程式失去核心概念，變的四不像。因此，作者建議概念設計由少數人(架構師、分析師)主導、決定，其他人頂多提供意見，就像專制政治一樣。而另一個想法叫「第二系統效應」。這點十分有趣。在下先不要在這裡透露太多。留給親愛的讀者們自己去翻翻看，嘗嘗箇中滋味。

本文最難得的是作者對軟體開發的本質作了深度的思考。透過這些思考，可以反推出許多軟體專案經常遇到的問題，以及軟體專案難以突破的瓶頸。像是軟體專案的複雜度超乎想象，困難與簡單的程式，兩者之間的難度是指數成長，而溝通則佔據軟體開發中相當多的成本。另外，軟體雖然稱為「軟」體(Soft-ware)，但是更動起來卻不見得容易，人們對軟體的易變性期待性太高，忘了軟體是一種工程，和建築物的工程一樣，有時為了一個小功能就要做大幅的更動。人們不會輕易去更改建築物的設計，因為他們「看」起來覺得牽一髮動全身。而軟體則「看」不到，所以就會輕易想去改動它。

在下也做了好多年的軟體專案。雖然數年前就想買這本《人月神話》，但總覺得是上個世紀的舊書，也就打消了念頭。年初時突然興起念頭訂購下來，看完了感覺果真不錯。我想，對於從事軟體開發相關工作的人們，本書恐怕是必讀之作呀。它有一股...像《孫子兵法》般，不會因時間而消逝的魅力。