| 書名 | 人月神話:軟體專案管理之道(20 週年紀念版) |
| 原書名 | The Mythical Man-Month: Essays on Software Engineering |
| 作者 | Frederick P. Brooks Jr. |
| 譯者 | 錢一一 |
| 出版商 | 經濟新潮社 |
| 出版日 | 2004-03-31 |
| ISBN | 9789867889188 |
這本書在大概十年前,曾經看過然後寫過一次書評 - 人月神話:軟體專案管理之道 。 既然都寫過了幹嘛還要再寫?
原因自然是這幾年的當紅炸子雞 AI,它幾乎顛覆了我們對資訊世界的一切想像,依我的經驗奉勸各位軟體工程師,在經歷過 AI 時代後睡前讀物千萬不要選人月神話,上次拿了人月神話出來看結果愈看愈興奮,後來就失眠了。
這篇就讓我們回顧一下人月神話的內容,看看在 AI 時代,究竟有多少變化。
AI 與軟體系統產品
軟體系統產品,指的是整合了大量軟體、有完善開發說明文件的大型系統,例如作者親身參與高達 5000 人年等級的 o360 專案。
從一般程式,成為文件、測試齊備的軟體產品,對於熟稔軟體產品的人,很大一部分的工作已經被 AI
填平了;但要整合多個軟體產品,成為軟體工程產品的所需要的功,我認為 AI 的增效就沒有(還沒有)這麼明顯。
確實 AI 如同火箭般強而有力,但推力需要一個方向,例如朝向月球飛去,而不是沒有導引像蒼繩一樣亂飛。
假設 AI 可以在一秒中生成作業系統好了,請問 windows 11 的 spec 是什麼?
燒了一堆 token 之後,這個作業系統有誰要用?如何在市場上與其他的作業系統作出區隔?既然
AI 這麼神猛,那 windows 11 又怎麼會搞到怨聲載道?
洞察市場需求,訂定出整個系統規格,這些事情無法被外包,也無法交由 AI 決定,缺乏明確的系統規劃, AI 的實作也只是用十倍速度疊床架屋,它可以很快的用 Chromium-based WebView2 幹出一個漂亮的天氣 App,然後在你的電腦上 吃掉 GB 等級的記憶體 。
在第二章,作者提出了所謂的外科手術團隊,這部分很明顯已經被 AI 完全顛覆了,未來會是一支高效率的架構團隊,以及一群高效率使用 AI 的<首席 AI 工程師>,外科手術團隊裡面的人全部都是 AI:
- 主程式設計師 -> AI agent
- 輔助程式設計師 -> AI sub agent
- 文件撰寫 -> AI agent
- 測試 -> AI agent
雖然大家都被 AI 取代了,但高效團隊的組成原則我覺得仍然不變,例如多個 agent 要如何有效率的切割工作,讓彼此之間不會打架,清晰的架構讓 AI 能有效率生產 code,整體的程式碼又能保持在人類能夠理解,能夠順利接手的範圍之中。
再論人月神話
- 1974 人月神話出版第一版
- 1986 引發論辯的沒有銀彈發表
- 1996 人月神話二十週年紀念版,沒有銀彈十週年被認為是真實的
必須說,雖然資訊產業通常稱為科技業、智慧產業,但其骨子裡與傳產並無二致, 只不過傳產是最大化實體的生產,資訊業最大化的則是程式碼的生產, 不斷精進的專案管理,將專案精細切割到不同部門,並套上數不盡的文件、測試、臭轟回報工具, 才能維持每人每年區區千行的生產力。
與我十年前心得相同的,我認為銀彈問題在千禧年之際已經獲得一定的解決, 我們開發大型軟體的複雜度已經提升了十倍,由我這個時間點回看,我認為關鍵在於三點:
- 統一的處理器架構與基於相同架構的硬體,人月神話中提的軟體系統產品大多是執行在某種特規機器上的, 開發前都還要先準備好開發機種,在管理上切分工作時間讓大家在上面除錯
- 網際網路的發展,帶動全球規模協作的開放原始碼專案,在許多利基市場提供了關鍵的工具, 開發環境容器化、即時溝通、bug 追蹤、套件安裝、版本控制、CI/CD。
- 高階程式語言函式庫與好用的膠水語言的進步,包括但不限於 C/C++ 標準函式庫與 Python 工具鏈的發展,有助於概念的溝通與進展,減輕高階設計的溝通難點。
三者的加乘,讓我們擺脫了麻煩的硬體除錯,不用神經兮兮處理 memory 問題,直接使用套件工具載入需要的
library,得以站在巨人肩膀上面應對更為困難,更大型的軟體系統。
當然不是說軟體開發再也沒有困難,而是我們成長得更高,足以挑戰更加困難的問題,在
2008 年,我們看到網路服務與伺服器成長到足以撐起全球人口量的使用者,這在人月神話年代幾乎是難以想像的。
人手一台的智慧型手機,軟體進到身邊每一個可以運算的裝置,網路串流與會議在突然殺到的疫情之下維繫並連結著大家。
於是,時間來到了人月神話 50 年後的 2024 以及 沒有銀彈 40 年後的 2026 年,人類發明了 AI,從此我們有銀彈了。
突破人月神話
其實原作者曾經就銀彈這個議題多加著墨,而且裡面也曾提到人工智慧,只是那跟現有的 AI 顯然是完全不一樣的東西;儘管我們不完全了解背後的原理,但 AI 的能力在於足以理解軟體的本質問題,從大量的文本與人類模糊的描述中理解軟體的概念。
這裡小弟我最近剛好有切身的經歷,之前寫過了一篇 Reed Solomon 編碼 的介紹,但故事進到解碼,那就是完全不一樣的故事了,光是要搞懂背後的數學理論就先去掉半條命,我覺得這就是 Brooks 所說的本質性的問題。
當程式的連結到背後複雜的數學(沒錯,數學不會就是不會),實作程式就必須先理論本質的困難問題。 儘管我用的已經是 Python ,能夠有效抽象化一些 Galois Field 上的運算,但在 decode 上還是搞到灰頭土臉,花費大半天才實作完這套快 60 年前的編碼;我也不預期 Brooks 提過的諸如圖形化程式設計等方法能有效解決這個難題。
而 AI ,顯然具有攻克本質性問題的能力,我相信我只要給 AI 一行指令,Reed Solomon code
對他來說根本小菜一碟,有需要的話我還能請他解釋 code 給我看。
AI 也打破了人力和工時可以互換這件事,開一個 agent
它就能飛速理解現有的環境、工具以及使用方式,並能立即開始接受指令開始工作。這完全省去了人類所需
(透過語言這種低效的媒介)的訓練和相互交流成本。
更重要的是 AI 真正做到老嫗能解,過往開發者抱怨使用者說不清楚需求,而使用者抱怨開發者誤解他們的意思,未來能透過 AI 模型,讓使用者快速生成一個原型,再由開發者接手(或是砍了開發者讓 AI 模型獨立完成),再模糊的需求也能透過 AI 一步步釐清並且快速完成原型。
未來的焦油坑
我認為在未來,AI 公司會更近似於一種人力外包,有效但仍不是免費的,在大型專案中使用 Tier 1 高效能的 AI 是需要規劃與審慎執行的,否則專案執行完成,產品推出了,然後財務拿了一張報表跟你請款: Token 費 300 萬

負責人不吐血才怪。
對 AI 的客戶來說,不鼓勵甚至禁用 Tier 1 的 AI 模型是有動機的,核心資料與程式碼送進外部
API,也不知道是否可能變成訓練資料,甚至競爭對手提問的回答;比較有能力的公司,
一定會想辦法使用自建的機櫃與自己的運算能力,在系統中建構一定的 Tier2 本地模型。
這類 Tier2 本地模型也許沒有 Tier 1 強大,但要幫忙下層的小組件經理快速完成
coding,或是整理公司內部的文件、生成文件等工作,應該是綽綽有餘。
在供應鏈戰爭 裡面有一句話
如果不是種的,那就是挖的
If it isn't grown, it's mined.
這句話說的是原物料的狀況,它不包括第三級的服務業,我覺得可以小修一下:
如果不是種的、挖的,那就是服務別人
If it isn't grown or mined, it is served.
在 AI 年代,如果你提供的東西不是種的、不是挖的也不是在服務人,那你可能要小心了。
未來的軟體世界預期會是非常嚴酷的速度戰,如果 AI 模型能夠平均分配給每個工程師,並且依照重複獨立發現發明定律 ,這世界上總有人跟你想到一樣的點子,那麼,競爭已經不是點子,而是誰能最快的驅動模型推出產品。
在寫 code 本身已經不費時間的狀況下,身為架構師,比的就是好的架構與壞的架構,
好的時程規劃與壞的時程規劃,怎麼調和專案中極快的(軟體實作)與極慢的(硬體打樣、規格制定),
實作完成後系統整合的順利程度,以及能夠用最小的成本去微調以符合使用者的需求。
困難仍會在由程式組合為系統時出現,系統層級的錯誤很難在架構設計上預見並預先排除,
規格擴大之後由大型語言模型進行分析與除錯仍是耗時(可預期還是比人快)與消耗 Token 的工作。
架構設計關乎到系統能不能儘早完成並上線,一但搶先上線就有機會得到使用者的回饋並儘早改善開發方向。
未來陷在焦油坑煩惱的是 AI Model,專案管理的痛苦則是錢包跟著
AI 模型一起沉在焦油坑裡,邊燒錢邊看到競爭對手同樣的產品大發利市。
AI 最大的敵人,正是人類
相比 AI 這樣孜孜不倦當人類在睡覺的時候AI都在努力學習還能完整複製模型參數,
人類根本是又蠢又遲鈍,易騙又難教,但也因此,AI 要能滲透進人類社會,最大的難關也許正是人類。
回歸一下最上面 windows 的例子,即便 AI 可以如閃電般生成 code 完成開發,說到大規模成為大家日常的工具還是力有未逮。 就算是人類開發者,人與人的信任這件事無可取代,沒有足夠的眼球,整個社會仍然會質疑這段 code 究竟有沒有問題。
用在網頁、遊戲、App 等成熟、容易回滾、即便出錯造成損失也不大的領域
(注意,我認為"服務停擺"是損失不大的),使用 AI 仍然能換到極大的生產力提升。
但在基礎建設的領域,例如 Linux 核心、標準函式庫、需要操作實體機械的領域,程式再快也無法加速實體物質的移動,
快速生成的 code 未必能換到審查人員的信任,對於開發人員的確認就愈來愈重要,未來將不是:
Talk is cheap, show me your code
而是
Code is cheap, tell me your thought
如果無法清楚表述你對這段修改的想法,甚至這個人的身份都無法確認,那你是在偷懶刷貢獻還是別有所圖?
人類的注意力如此有限之下,AI 時代的資格篩選就會被放到最優先的地位。
這讓我想到 AI 進逼的另一個與電腦科學息息相關的領域 -
數學,電影天才無限家 the man who knows the infinity
裡面的台詞
Ramanujan: I found another series
G. H. Hardy: I don't want more series, I need your proof.
透過 AI 大量生成似是而非的證明時,數學也會從:
Talk is cheap; Show me your proof
轉變為
Proof is cheap; Tell me your thought
未來可能是自我表達最為重要的年代,腦袋中的思想是沒有價值的,它必須要被口語、寫作表述出來,
讓周邊的眾人理解、吸收、被賦予意義,才是對廣羅大眾有用的東西,其餘只會被掛上黑魔法而被無視,或是被唾棄。
如同你叫 AI 寫一本書的讀書心得,任誰都能看出這一點意義也沒有;誠然我可以用 AI 一秒寫完
Reed Solomon decoder,寫一個遊戲,但結束之後我還是對
Reed Solomon code 一竅不通,對遊戲引擎一竅不通,那麼這段過程,對我這個人又帶來什麼呢?
人生經驗與時間淀積無可取代,我們也許無法相信一個 AI 驗證過的軟體產品,但我們會願意相信一個長時間活著而且大家都用的產品,儘管後者對於安全性毫無保證; 活著,這或許是 AI 時代最沒用也最有用的一句話。
老實說,過去這幾年關乎 AI 的各種演講之中,我最不喜歡的一句就是 Jensen Huang
在台北帝國大學台灣大學畢業典禮致詞的那句:
Run. Don't walk. Either you're running for food, or running from being food.
把奔跑當成某種人生的競爭方式,我認真覺得超不符合 AI 時代。
AI 最大的特色就是做事超快又不會累,在這個時代跑起來,
就好像跑車已經在街上跑了,然後鼓勵大家跑快一點,看能不能跑贏車子。
很多人不是沒在跑,台灣地震預測研究所的人跑得不認真嗎?疫苗陰謀論者跑得不認真嗎?
不他們超級認真,只是方向偏了只會跑到錯誤的目的地。
不是說努力無用,而是 AI 這套放大器能將你的能力放大百倍、千倍的時候,跟
AI 比速度是沒用的,先慢下來思考一下怎麼跑?往哪跑?需要什麼樣的能力才足以駕馭
AI,識別 AI 並沒有在撒謊、沒有出幻覺,培養出鑑識出好題目的品味,遠比拚命跑拚命衝還來得重要得多。
偉大的旅程
回到這本書,是否在 AI 時代,人月神話這本書已經不再重要?
我認為正好相反,現在正是人人都能成為軟體專案工程師的年代,只是管理的不再是人而是一群 AI 模型。
這是有好處的,人月神話提倡的:專制的架構設計 vs 民主的實作,在這個年代得到完全的體現:
架構全部由人類統籌,實作全部交給高效的 AI,保證產品的整體概念性完美達標。
E.F. Schumacher 提到,那些對人類社會影響最大的科技或技術,必須符合下列三個條件:
- 每個人都便宜負擔得起
- 即使是小型的應用也很合用
- 能夠配合人類創作的需要
從這個角度來說,將 AI 普及與利用火、發明電、電腦普及並列,並不算太過份; 未來的人類解除操縱電腦的枷鎖之後,究竟能蹦出多少全新的創意與巧思呢?
身為一個從 DevC++ 時代一路走來的工程師(好啦我知道看倌想必都是用打孔卡開始寫程式的),看到同事們用
Fable5 在一個星期中打造出一套飛行模擬程式,能親身參與這樣的技術躍遷,真的有一種難以言喻的感動。
也很遺憾,本書的作者 Fred Brooks 在 2022 年就過世了,無法讓他見識到人工智慧與
Vibe Coding 的崛起,人類終於脫離程式碼流水線,從辦公室隔間中解放出來。
有了 AI,今日大型純軟體專案管理,與其他大型事業相比已然不再類似,未來的大型軟體更可能唾手可得, 不再是需要管理的東西,我們仍要感謝 Brooks 前輩為我們帶來如此精彩的著作, 如同博物館或是傳藝中心一般,讓我們得以一窺前 AI 時代,那個曾經吞噬無數人月的焦油坑。
敬所有軟硬體界的先賢先烈,沒有他們的努力,就沒有我們眼前的這顆 AI 銀彈。
其他
寫這篇文章的時候,我有想到幾個與本書有關,比較零碎的有趣問題,在這裡先不細想,歡迎大家留言提出自己的看法
- 出自巴別塔為什麼會失敗:你覺得在大型專案中,AI 是否有溝通成本?各模組是否都能順利整合?
- 出自第二系統效應:你覺得 AI 在大型專案的設計中,是否會偏向過度設計?你覺得使用 AI 進行設計的人,會不會有第二系統效應?
- 第一支類神經網路是在 1969 年左右出現的,但因為一些原因 沉寂了幾十年,如果當年類神經網路的發展勢頭沒有停下來,你覺得 AI 奇點能夠提早到來嗎?
歡迎大家留下你們的看法