《TO》導讀：本篇原文來自《FasrCompany》，本篇後半將有原文作者 Ciara Byrne 訪問軟體工程師、電腦科學家 Fred Brooks 的訪談紀錄，討論為何現今的工程師，仍和四十年前的工程師犯同樣的錯誤。
1964 年 Fred Brooks 接下電腦史上最大程式設計計畫之一，負責 IBM 電腦公司 System/360 開發。此計畫問世代表著世界上的電腦有一種共同的語言，這也成為現在大型電腦系統的前身，影響深遠。
Brooks 在進行此計畫時，發現到軟硬體設計之間的不同，於後他將他的工作經驗談，與對於軟體設計的見解，寫成一本軟體書籍的經典《The Mythical Man-Month》，此本書中最有名的論點之一就是千萬不要在計畫死線前加入新血，那樣只會幫倒忙。
雖然這本書為 40 多年前的老書，但對映現今社會，仍是發人深省。Brooks 以風趣直白的風格講述人類工程史上一項里程碑：大型複雜軟體系統的開發經驗，以及程式設計者內心到底在想什麼。（他曾說過所有軟體工程師都是樂觀主義者。）
Brooks 後來創立了北卡羅萊納大學的電腦資訊工程系，並在 1999 年時獲頒專門鼓勵電腦工程人員的 Turing Award；2010 年，發行最新書籍《The Design of Design: essays from a Computer Scientist》。
如今 Brooks 以 82 歲的高齡，以見證現代電腦資訊工程發展的角色，與我們分享軟體工程、程式設計的相關問題，以及為何工程師仍然會犯些早在 40 年前就發生過的同樣錯誤。
以下以訪談形式進行。
- 與 Fred Brooks 的訪談內容：
Q: 你如何發現自己對於電腦的興趣？
A：我在北卡羅萊納州的 Greenville 長大，當時在圖書館裡看到一本雜誌封面上，印有第一部大型自動數位電腦馬克一號（Havard Mark I），我立刻瘋狂著迷於它，並決定這就是我想要畢生投入、研究的事物。
Q: 經典著作《The Mythical Man-Month》是根據你在 IBM 電腦公司領導 OS/360 計畫而寫成的書籍，你是如何開始領導這個計畫的？
A: 我就讀於哈佛電腦資訊工程系（那時後被稱為應用數學系），後來在馬克一號的創立者 Harvard Mark 教授指導下完成論文。然後我加入 IBM 工作，在研發幾個後來並沒有量產的產品後，1961 年我被選為 System 360 開發計畫的部分硬體負責人。三年後 system 360 的硬體設計開始日上軌道，並且準時投入工廠生產，可是關於軟體設計部分仍然一團糟，於是我的老闆決定讓我試試看領導軟體設計的計畫，看看可以闖出些什麼成就來。
Q: IBM 的 OS/360 計畫規模有多大？
A：我不知道此計畫的總成本，但我曾聽說過此計畫在 1960 年代就燒掉 3 億到 5 億美金，當時的美金比現在貴十倍，所以以現在的幣值來講，可能是 30 至 50 億美金。此計畫最多曾招募到近千人，不過大部分時間並沒有這麼多。IBM 也因此在全球廣設實驗室：德國、英國、法國、瑞典、加州、紐約都有此計畫的專用實驗室。
Q：你曾說過「大家都引用《The Mythical Man-Month》；有一些人會閱讀；但很少人真的學到書中經驗」，為什麼呢？
A：其實此書就是有關軟體工程師在領導時所做的重大性決策，只要看看現在美國健保所發生的重大程式設計錯誤，就可發現那些人犯下書中所有曾提及過的錯誤。
現在這本書已經被翻印超過五十萬次，並且應用於許許多多資工系課程上，照理講應該很多人都知道軟體設計應該避免哪些錯誤，但只要領導重大軟體設計計畫的工程師不是資工系出身，就很難期待他們會注意到這些過往經驗，因此錯誤總是一再重演。
美國健保系統所犯下最嚴重的錯誤就是，整個團隊沒有一個領導人，這是導致後續情況越走越錯的關鍵，此計畫沒有人主導架構，更沒有人負責管理，我簡直不敢想像後續會有多糟。
Q：為什麼一個軟體設計計畫需要有人負責管理和進行整體架構？
A：我認為就算是個小團隊，分工也要非常明確：有人負責管理團隊進度，有人負責架構整個計畫大綱。
當我在北卡羅來納大學電腦工程學系任教時，我總是讓學生清楚的辨別各個職位的不同之處。負責統合軟體整體架構的角色，就必須要負責所有的科技技術部分；管理團隊運行的角色，就得扛起團隊進度、排程、資源搜尋等事項，兩者工作內容皆十分重要且大不相同。
我發現在電影業，也有如此系統性的分工，製作人負責協調大小事項，可是最終功勞仍舊歸給導演；導演負責藝術方面的發想，製作人就要負責讓這些想像成真。我認為套用到軟體設計上，計畫管理者就如同製作人，得想辦法使技術架構出的理論變成事實。
計畫管理者第一要素就是要具備堅毅性格，也必須要能夠隨機應變。一句最適合管理者的格言就是 「對於未知事物，永遠保持開放的心」，並且永遠朝著目標前進，但是在朝著計畫前進的過程中，也必須因應事實而修正方向。計畫管理者就代表著打理團隊大小事務的負責人，所以處事必須圓融，團隊裡是由每個人協心同力才能完成，不過通常問題發生，也是來自於溝通不良。
Q: 為什麼在《The Mythical Man-Month》發行將近四十年後，要預估一件大型軟體計畫所需時間仍然很困難？
A: 因為我們必須要面對的是，設計一個全新的程式，或是發想一件全新的科技。而研發新程式總是會藏有許多不定性因子，就像是第一次建造核彈潛艇或是火箭是一模一樣的道理，你永遠不知道接下來可能會碰到什麼問題，只要是程式設計，永遠是在探索新可能。
Q: 在新書《The Design of Design》內，你提到「設計的科學」是個不可能，也是個誤導的概念，為什麼？
A: 科學家與工程師若是以實際作為上來做區別，有著本質上的差異。科學家需要花很多時間，形成一套假設，他設立一套假設是為了學習未知的科學真理；工程師每天花很多時間研究既有資料，以做研究的精神來創見新事物，兩者雖然相輔相成，其中的差異卻十分重要。
所以我認為國家科學機構（National Science Foundation）計畫要在設計、研發新技術的步驟中，找出既有脈絡是不可能的。物理學的理論可以被系統化，可是沒有人可以將物理學家做研究的過程也跟著建立一定步驟。
換言之，設計的科學是一個誤導概念，因為其根本就無法找出一個既定的過程。
Q: 你也曾說過「標準作業設計流程，其實是創新與偉大設計的絆腳石」，但是標準化的作業流程，也有助於提昇一般設計的水平，程式作業者在設計程式時，該如何面對這樣的狀況？
A: 這就是辨別優秀的程式設計師與一般的程式設計師的差別。
其實根本無法教導一個人怎樣進行程式設計，唯有經歷不同的程式設計經驗後，當事人才有辦法逐漸抓到那種感覺，以及思考判斷的能力。有句俗話說「好的判斷來自於經驗，經驗來自於先前的失敗」，我認為這句話應用在程式設計師的訓練上，非常適合。
Q: 該如何訓練程式設計師？
A: 應該藉由不同種類的計畫，使新的程式設計師能夠多方吸取不同經驗，並且在不同職位上，對於程式設計發展出全面的見解。因為設計師是介於使用者與開發者之間的媒介，他必須要了解使用者的需求，也要了解這個程式的設計目的，以及它想達到的功用，因此不管是使用者面，或是設計者面，設計師都要認真花時間下去了解。
大多數的大公司皆有這種計畫，以角色轉換的方式來訓練設計師，從學術面到實際應用面的各種職位，都會讓設計師實際參與。在 IBM，最有潛力的年輕設計師皆是從助手開始做起，財政總監、CEO、執行總監身邊都有助手，這些人日後或許都有相當潛力，可以接替決策大位。而負責決定哪些人該受訓的管理人也很重要，他們知道訓練新人的重要性，不過有些人卻會選擇不給新人受訓機會，以免新人日後成就超越自己。
Q: IBM 的 CEO 帶給你什麼樣的啟發？
A: 當我離開 IBM 前往北卡羅萊納大學教書時，IBM 的 CEO Thomas Waston Jr. 邀請我前去共進私人午餐，他希望我能夠繼續留在公司，可是我並無此意。當時我擔任的是第三級的工程師，我對他說：「我很喜歡研究、製造東西，所以我要回到學校裡貼近那個領域。」
CEO 只問我你有沒有看過團隊最新的 Poughkeepsie（IBM 最大的電腦設計計畫），此計畫底下有一萬個人在位此工作，而整個實驗的計畫是由 IBM 的 CEO 領導。
在那個瞬間我的視野被整個提昇了，我從來沒有想過所謂的「製造東西」可以巨大到這種層級，也讓我對於個人的觀點，有了不一樣的見解。
（資料來源：FastCompany；圖片來源： EagerEyes , CC Licensed）
Source: techorange.com
