人月神话

跟只為私人使用而單獨寫出來的組件程式相比，做出軟體系統產品（programming systems product）所要付出的代價將是九倍以上。估計產品化（productizing）的代價是三倍，若要對組件從事設計、整合、測試，進而凝聚成為一個系統，則代價也是三倍，而且這方面的成本計算基本是獨立的。[1]

軟體開發的另一個難題，是從單一程式到軟體系統過程中，所造成複雜度的快速上升，期間並需要包含不同的活動與技能，使得軟體開發必須面對多樣性的挑戰。布魯克斯最早認識到設計程式、開發軟體的差別，他以程式與系統、產品的差異，解釋兩者之間的不同，並以3×3的複雜度加以說明。[3]

人月神話（英語：）：這部分講述人力和時間並不呈現線性關係。指出以大量人員和較短的時間，並不能縮短軟體的開發進度。一窩蜂的作業方式無助於軟體生產，且會製造麻煩，產生出更差的軟體。向進度落後的專案追加人力，只會使進度更加落後。因為新進的人員需要時間了解整個專案，而增加額外的溝通消耗。當有N個人必須在這群人之中進行溝通時（無階級關係），當N增加，其輸出M將抵消其效益，甚至倒退（最後幾天所完成的進度，遠不如剛開始幾天所完成的進度。像是發現了許多錯誤）。

• 團隊交流公式：${\displaystyle n(n-1)/2}$
• 範例：50個開發人員，就要${\displaystyle 50(50-1)/2=1225}$個溝通管道

用「人月」來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思，使用人月的前提必須是在人力和工時可以互換的情況之下：當一份工作因具有連續性的限制而不可切分時，就算投入再多的人力，也不會對時程有所影響，生小孩就是需要九個月，你叫多少個媽一起生都一樣，軟體工程就是像這樣的工作，因為它必須除錯，而除錯本身就具有連續性的本質。[1]

人月（英語：）指的是「一個人要花幾個月」才能完成軟體開發的單位，通常用來評估一件軟體專案的大小。[4]以成本會計（cost accounting）為基礎的時程預估技術，使我們誤把工作量和專案進度混為一談，人月是個危險並很容易就遭到誤解的迷思（myth），因為它假設人力和工時可以互換。[1]

在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後[註 3]。根據Brooks法則，增加人員到一個已經延誤的專案裡，等於是火上加油。除非你可以把工作區分，讓新進人員可在不影響他人工作的狀況下有所貢獻。

把工作切分給更多人做將造成額外的溝通（communication）代價——訓練和相互的交流（intercommunication）。欲增加軟體專案的人手，總共必須付出的代價可分為三方面：工作重新切分本身所造成的混亂與額外工作量、新進人員的訓練、新增加的相互交流。[1]

在接受相同的訓練、同樣都是兩年資歷的情況下，優秀專業程式設計師的生產力要比差勁的程式設計師好上十倍。短小精悍團隊是最棒的——盡可能用最少的人。兩人團隊，其中一人當領導者，這通常是最佳的用人方式。以短小精悍團隊開發真正大的系統就太慢了。絕大多數大型軟體系統的經驗顯示，使用一堆人蠻幹的方式最耗成本、最慢、最沒有效率，做出來的系統在概念上也最不完整。

以一位首席程式設計師為主、類似於外科手術團隊的組織提供了一個良方，既可因少數人的決策而兼顧到產品的整體性，又可因多數人的合作與大幅溝通減少而得到全部人的生產力。[1]

• 在系統設計時，保有概念整體性（conceptual integrity）是最重要的原則。[1]
• 功能概念複雜度比（這個比值是為了量測使用便利性，對簡單和困難的運用都很有效）才是系統設計的最終測試標準。功能多，不見得是好事。
• 要達成概念整體性，設計必須出自於一個人的想法，或是極少數人的一致決定。
• 對大型軟體專案（小專案也一樣）來說，將架構設計獨立於實作之外是取得概念整體性強而有利的方法。
• 如果系統必須保有概念上的整體性，那麼就必須有人來控制這些概念，這就是需要專制的原因，無庸置疑。
• 許多軟體架構、實作、實現的工作都是可以同時進行的。（不論硬體或軟體設計，都可以同時進行）

第二系統效應（英語：）就一個人所做過的設計而言，第二個系統是最危險的系統，一般來說，都傾向於過度設計。[1]

當他做第三或之後的系統時，之前的經驗會互相印證，以確認出這類系統的一般性特色，而系統彼此之間的不同處，也會幫助他辨別出屬於特殊和非通用的部份。除了做些功能上的修飾之外，第二系統效應還有另外一項特徵，那就是傾向於將之前已熟悉的技術發揮到淋漓盡致，但卻沒有留意到，這項技術早就跟目前專案的基本系統假設有衝突而不再適用，OS/360有好多這樣的例子。（Windows NT則似乎是1990年代的範例）

對大部份OS/360的設計人員來說，它也是個第二系統，設計成員分別來自1410-7010磁碟作業系統、Stretch作業系統、Project Mercury即時系統、給7090用的IBSYS作業系統等等，幾乎沒有人擁有兩個上述系統的發展經驗，所以OS/360可稱得上是一個最佳的第二系統效應範例。

手冊或書面規格是不可或缺的工具，雖然光靠它是不夠的。手冊載明的是產品的外部（external）規格，用來描述並制定出使用者從外觀上將或看到的所有細節，撰寫手冊便是架構設計師的主要工作。當使用者和實作人員的反應不斷地顯示出設計上難以使用或實現之處，手冊就會墮入重新準備、修改的輪迴之中。為了造福實作人員，將修改的程度予以量化（quantize）是很重要的——在時程上應該要有載明日期的版本資訊。[1]

失敗的軟體專案經常發生在開發者與用戶間對需求認知的誤解。開發者抱怨用戶說不清楚需求，而用戶抱怨開發者誤解他們的意思。布魯克斯認為「軟體開發最困難的單一項目，是精確地決定要建造什麼。」[註 4]

增修內容：[1]

1. 將初版中所主張的所有論斷整理出一個簡潔的摘要，包括了原書的主要理念：就人力配置的比例而言，大型軟體專案所面臨的是跟小型專案完全不同的管理問題，這引申出產品的概念整體性是其中的關鍵，而達成概念整體性雖然困難，但卻是可能辦到的。
2. 作者佛瑞德·布魯克斯對他當初所提出的這些論斷，在經過一個世代之後所做的觀察。
3. 轉載布魯克斯1986年發表於IEEE《Computer》的論文沒有銀彈。
4. 布魯克斯對於他1986年的論斷「十年內不會有任何銀彈」所做的回應。