聽說是軟體工程唯一活過五十年的書 找來讀了
作者 Fred Brooks 是 IBM OS/360 的專案負責人 那是 1960 年代地表上最大的軟體專案 幾千人年的規模 然後嚴重遲到 這本書就是他事後的檢討報告 所以裡面每一條都是用真的錢跟真的加班換來的
老實說沒有全部看懂 先把有感的記下來
人月不可互換
書名的哏就是這個 專案管理喜歡用人月當單位 好像 10 個人做 1 個月等於 1 個人做 10 個月 但人跟月是不能相乘的 人一多 溝通成本是平方在長 n 個人的溝通線是 n(n-1)/2 條 3 個人 3 條 10 個人變 45 條 工作可以切 溝通切不掉
書裡把任務分成幾種 可以完全切割的 像收麥子 人多真的就快 不能切割的 他舉的例子是生小孩 九個月就是九個月 派幾個人來都一樣 軟體開發偏向後者 而且還要加上溝通的稅
The bearing of a child takes nine months, no matter how many women are assigned.
這句大概是整本書最有名的一句
Brooks's Law
Adding manpower to a late software project makes it later.
專案延遲了 直覺是加人 但他把帳算給你看 新人上手要時間 帶新人的老手產出先掉下來 然後溝通線又變多 工作還要重新切分 三筆成本加起來 常常比多出來的人力還大
五十年前寫的 現在的專案還是一直在犯一樣的錯 知道歸知道 deadline 壓下來的時候 加人還是每次都被搬出來
書裡還有一句講進度的也很利
How does a project get to be a year late? One day at a time.
專案不是某天突然遲到一年的 是每天遲到一點 每次都覺得追得回來
沒有銀彈
軟體的複雜有兩種 本質的跟附帶的 本質的複雜是問題本身的 需求 相依 狀態 這些東西再怎麼換工具都在 附帶的複雜是工具造成的 從組合語言到高階語言 消掉的就是這種
他的論點是 工具的進步只能消附帶的複雜 而附帶的複雜消得差不多之後 剩下的都是本質的 所以不會再有十倍的躍進
這篇其實是 1986 年另外寫的文章 後來被收進紀念版 變成整本書最有名的一章 讀的時候一直在想 AI 算不算銀彈 目前看起來 它消掉的還是偏附帶的那種 要做什麼 為什麼這樣做 還是得自己想
第二系統效應
設計師做第一個系統的時候會保守 因為不確定行不行 成功之後做第二個 就把第一次忍住沒加的東西全部加進去 結果第二個系統常常是最過度設計的那個
這個放到現在看還是很準 第一版求活下來 第二版什麼都想要 反而把自己搞死 忍住不加東西 好像從五十年前就是最難的事
計畫丟掉一版
Plan to throw one away; you will, anyhow.
第一版本來就是拿來學的 因為做之前你根本不知道問題長什麼樣 與其假裝第一版就是成品 不如一開始就打算丟掉它
有趣的是 Brooks 在二十週年版自己承認這條寫得不好 不是丟掉重寫 是應該一路演進 這本書連自我修正都示範給你看
後半看不太懂
概念完整性 外科手術團隊 那幾章讀得比較茫 知道它在講什麼 一個系統的設計應該出自一個心智 團隊該像手術房一樣一個主刀其他人支援 但只是字面上懂 沒有畫面 可能是還沒遇過那個規模的問題 沒有經驗可以對上去
這種書大概就是這樣 有些地方就是要遇到才讀得懂 先放著 之後有機會再回來看
讀完想到的
想通了一件事 這本書為什麼活得下來 同年代講技術的書全過時了 書裡講 OS/360 細節的部分現在也沒人在乎 留下來被一直引用的 全是講人的部分 技術一直換 人的限制沒被換掉過
溝通成本這件事 我是有感覺的 學生時期做專案 人一多就開始亂 訊息對不齊 誰做了什麼沒人知道 最後常常是兩三個人把整組的事做完 人少的組反而交得快
現在的對比更明顯 公司裡一個改動要對齊很多人 開會跟文件的時間常常不比寫 code 少 但回家弄自己的 side project 一個人加 AI 什麼都不用問 想到就改 改完就上 這個部落格就是這樣長出來的
所以用現在的眼睛看 書裡有個地方特別有意思 如果溝通成本是平方在長 那讓專案變快的方法可能不是加人 是減人 AI 讓一個人做得了以前三個人的事 團隊從 10 人縮到 3 人 溝通線就從 45 條掉到 3 條 也許 AI 帶來的提速 一半是 code 寫得快 另一半是團隊終於可以小到不太需要開會
還有 帶 agent 其實也有人月神話的影子 多個 agent 一起上的時候 要寫交接文件 要對齊 context 溝通的稅並沒有消失 只是從會議室搬到了 prompt 裡
現在讀起來最神奇的是 1975 年的觀察到現在都還成立 軟體變了好幾輪 人沒有變