#27 人月神話

人月神話》,就像《戰爭與和平》、《麥田捕手》跟《簡愛》一樣,都是明明沒看過,卻說得自己好像有看過一樣的書。

十大最多人「號稱」看完的書……只是號稱而已

拜發達的網路所賜,現在就算沒有看過某某書,也能在網路上看到別人幫你整理好的書摘。有些書摘甚至還會幫你引經據典,讓你可以從這本書出發,點點超連結就可以知道同意作者觀點的人怎麼支持作者、不同意的人又提出了哪些不一樣的看法。我從不反對這種看書方式,如果這種搜集資訊的方式百害而無一益,那網路早該廢掉了。(來自亞米胥派的同學請坐,我只是假設而已)但問題是網路上的文章整理的再詳盡,總還是會有與原書不一樣的地方——所以要了解經典,最好的方式就是直接去看經典,宗教改革萬歲,馬丁·路德萬歲。

我看的是城邦出版社初版第 28 刷的「二十週年紀念版」。

TL;DR

為了服務沒有時間看完文章的讀者,順便提綱契領,我列出我看完這本書之後的幾個重點:

  1. 進度落後時加人是個餿主意
  2. 二流團隊比不上一流孤狼
  3. 程序可以民主,但文件必須獨裁
  4. 第二套系統通常會是一場災難
  5. 軟體總是會迎來「老子改不動啦」的那一天
  6. 以文件說服人,而不是以文件很重要來說服人
  7. 可能只是你還沒找到銀彈而已

進度落後時加人是個餿主意

「九個孕婦合作也不可能在一個月內生出小孩」

加人之所以只會讓進度更落後的原因在於,這個新人對團隊來說就是一顆未爆彈。這裡指的不是新人的技術上的能力,而是團隊必須開始習慣有這個新人加入的「新日常」。可能這個新人寫程式時會有某些固定的 pattern,跟團隊已經培養起來的默契相抵觸,就必須重新磨合——不管這個新人是否真心相信這個團隊的運作方式。我還記得我在現在這份工作送出的第一個 pull request,被前輩下了 42 個 comment。除了我的寫法會踩到他們已知的地雷,更多的是討論不同的寫法所帶來的新刺激。

往往加人這件事情,在規劃專案時程的時候根本沒有被考慮進去,所以勢必只會讓時程延遲的更嚴重。

但加人一定是不對的嗎?我認為作者也沒有這個意思,他主要的用意在破除「人月神話」——將工業時代延續下來的傳統跟軟體工程時代的實際情況做切割。作者在書中也有提到,短小精悍的團隊做不出大系統。所以如果要做出更大的系統,加人是一個必要的決定。

二流團隊比不上一流孤狼

作者在提出這個觀點的章節之後的其他章節,多次提到軟體工程是一件腦力工作的概念。既然是腦力工作,一流的工程師跟二流的工程師在腦力上可能是一個數量級的差距。所以作者借鑑外科手術團隊的配置,提出一個圍繞、支援這個大神級工程師的團隊架構。

書中團隊有很多角色,是一個分工很精細的系統;但現實世界的小公司,可能連要湊成一個外科手術團隊的人力都沒有。所以我在看這個章節的時候,看的是每一位團隊成員的職責。我的想法是,即使是小團隊,也可以在不同的角色中相互切換,讓每一個職責都有人擔。例如文件可能就是要專案經理來寫(書中是由文書編輯 editor 負責),程式助理 program clerk 的部分職責(例如版本控管)可能交由 Git 或 GitHub 來處理了。

程序可以民主,但文件必須獨裁

這一點會成立我覺得更多的是基於文字是一種會丟棄大量資訊的載體。討論的過程可以讓所有人參與,但撰寫文件的工作還是讓少數幾個人來就好。如果一份文件有十個人經手,那就有可能冒出十種以上的寫法。所以最好的方式是讓同一個人來撰寫、更新文件,也可以藉此確保專案整體一致性。在書中,作者將這個工作分派給外科手術團隊中一位專門的文書編輯 editor 來處理這件事;但現實狀況是小公司通常沒有多餘的人力來安排這種角色,所以通常會由專案經理來處理。

我最近發現自己好像不會很討厭寫文件,因為寫文件可以讓自己知道自己已經知道了什麼、漏掉了什麼,也算是一種重新檢視自己記憶、備份記憶的過程。

第二套系統通常會是一場災難

這一點我覺得是觀察得來的結果。

人總是喜歡追求完美,否則我們就不會有歷史上那些皇皇巨著或是雕梁畫棟了。但如果是在主觀上的重大失敗後追求完美,往往會演變成偏執。

通常工程師會遭遇到好幾次「第一套系統」⋯⋯

  1. 工程師生涯的第一套系統:剛學會寫 code,寫出一堆三個月後自己就看不懂的程式碼,自然會想要在第二套系統扳回一城。
  2. 在公司任職的第一套系統:前人留下來的產物,客觀上再好的系統,主觀上總還是能挑出一些毛病,然後就會想要在第二套系統使出渾身解術,可能是覺得這套系統真的有問題,也有可能是想證明自己的能力。

不管是基於什麼原因,此時工程師規劃出來的第二套系統,通常會過度設計(over-design)。而過度設計的潛台詞,就是對第二套系統的過度自信——不管是時程上還是實作上,相信自己有能力設計的出來就有能力實作完成。最後的結果要嘛是系統完成了但是複雜到使用者沒有辦法使用,要嘛就是刪減設計做一半,要嘛就是趕不上專案時程——無論是哪一種,都是災難。但弔詭的是,第三套系統就不會出現類似的問題。作者認為是因為第二套系統的災難讓工程師難以忘懷,痛定思痛後第三套系統再出災難的機會就小很多了。

最近我正要開始規劃、實作這種「第二套系統」,還好先看了《人月神話》,就祈禱自己不會重蹈書中的覆轍吧!

軟體總是會迎來「老子改不動啦」的那一天

最近跟一個前同事見面,就討論到這個問題:到底什麼時候要重寫程式?

他的觀點是,如果遇到太大的系統就想要重寫,那就永遠無法征服更大的系統;但我持相反的態度,如果一套系統已經改到大家心很累、成本很高的時候,就應該開始考慮重寫的選項。可能是我們那時候剛經歷了一場把 AngularJS 全部轉換到 React 的大混戰,導致前同事對重寫這件事情非常感冒。但重寫也有好幾種方法,先把一部分程式抽出來變成 microservice 也是一種做法,貿然把所有的資源全部梭哈進去重寫也不是一個明智的決定。

是說這個問題從一開始就對抱持著不應該重寫程式觀點的人很不利,因為如果程式不應該重寫的話,那我們可能到現在都還在用組合語言。所以問題變成什麼時候應該重寫程式?如果要把問題以經濟學的角度簡化,那就是什麼時候修改舊程式的邊際效益會開始小於邊際成本?但問題是這個問題本身就很難回答。如果是這個程式的商業價值已經在衰退了,即使修改完成也不會再創造更多商業價值了,那不要再繼續修改就是一個呼之欲出的決定了。但如果這是一個還有商業價值的程式,要怎麼衡量可能創造的商業價值與工程師投入的成本

作者在書中有提到一本《Software Engineering Economics》,好像還沒有中文譯本,等做好心理準備之後再來參拜一番。

以文件說服人,而不是以文件很重要來說服人

「文件很重要」這句話身為工程師的我們應該聽到耳朵長繭了,但問題是這句話就像是「吃虧就是占便宜」這種屁話一樣,說給別人很好聽,自己卻永遠做不到。

作者在書中舉了一個販賣收銀機的例子——讓學徒學會怎麼販賣收銀機最好的方式,就是將收銀機搬上車,出門拜訪客戶,直接示範怎麼賣。文件也是一樣,與其一直重複文件很重要這句話,不如先動手開始寫文件。技術文章都喜歡說 “Talk is cheap, show me the code”,文件也是一樣。

Talk is cheap, show me the documentation.

叉題 murmur 一下:開始工作之後,我也遇過很喜歡抱怨的工程師。會抱怨是好事,因為抱怨是一種情緒的正常抒發。不抱怨的人要嘛是委屈都往肚裡吞,要嘛就是心已死。但問題是:抱怨之後又做了什麼?問題解決的嗎?嘗試解決過了嗎?為什麼沒有辦法被解決?卡在哪裡了?卡住的地方是有辦法憑自己的力量解決的嗎?

為什麼一回到現實,工程師遇到問題就解決的態度就煙消雲散了呢

期許自己未來不會變成那種工程師。

可能只是你還沒找到銀彈而已

基於當代物理學,沒有任何帶有質量的物質可以超越光速,但我們還是懷抱著時空旅行、超空間旅行的癡心妄想。1901 年以前,人類在空中飛也是癡心妄想;100 年後,航空業已經達到了驚人的 10 億運量 [1]

我原本要寫說如果以 web 時代來說,我們應該或多或少找到 1/4 或半顆銀彈了,例如 Ruby on Rails、Git/GitHub、CI/CD 或是 Kubernetes;但由於是奠基於先進的工具,作者也強調了工具的改進並不是他所追求的銀彈,他追求的是層次更高的終極解決方案。我對作者的追求抱持比較悲觀的態度,畢竟我們的大腦四萬年來沒有什麼長進 [2];所以我寄望的反而是作者不想寄望的地方:工具的改進。看看 CI/CD、容器化等這些概念、技術,出現的時間也還不到 20 年,有些甚至還不到 10 年,我們開發軟體的方式就有了與 1990 年代相比如此巨大的變化。即使我們現在還是沒有辦法在軟體工程上取得質的飛躍,一點一滴的改進也是進步。

送萊特兄弟飛上天的那顆引擎,何嘗不是其他天才共同努力的成果?

後記

我希望作者長命百歲,因為我想看到人月神話 30 週年紀念版、40 週年紀念版。我希望作者如果還有力氣(剛剛查了一下,2019 年的現在他已經 88 歲了,比我爺爺還老),能夠再出版 40 週年紀念版,為千禧年後爆發的開源社群文化提出他自己的見解。

看完這本書之後,我發現有些事情 20 甚至 40 年(本書初版 1975 年)前到現在都沒有變過。加人在 40 年前是個餿主意,40 年後的現在也是;40 年前的工程師會過度樂觀的評估時程,40 年後的工程師還是會過度樂觀的評估時程;40 年前的工程師會過度設計第二套系統,40 年後的工程師一樣會對自己的第二套系統過度樂觀。或許正是因為這本書說的是「人」,而不是技術,才會那麼歷久彌新吧?


  1. Air transport, passengers carried https://data.worldbank.org/indicator/is.air.psgr

  2. The modern human brain may only be 40,000 years old, scientists say https://www.businessinsider.com/human-brains-may-only-be-40000-years-old-scientists-say-2018-1

  • 作者: Heng-Yi Wu
  • 文章連結: https://henry40408.com/weekly-27/
  • 版權聲明: 本網誌所有文章除特別聲明外,均採用 BY-NC-ND 許可協議。轉載請註明出處!