PlayStation 5主機設計解禁 兩款備配任你選擇   新款虛擬現實遊戲,讓玩家自由交易現實世界的地產   《漫威復仇者聯盟》的首週末:今日登陸PS4   「超級瑪利歐創作家2」的關卡數突破千萬!關卡上傳限制數增加為「100」個   《決勝時刻:現代戰爭》第六季新增快速旅行地鐵系統   明日凌晨!Indie World將公開Nintendo Switch上獨立遊戲的新作介紹影片!   為島上增添更多藝術氣息吧!日本Pola 美術館提供名畫供玩家們在《動森》上下載   遊戲玩家必看!參觀日本第一家電競旅館「e-ZONe〜電脳空間〜」! 

為什麼看來超棒的程式計畫,最後卻變爛了?

商業

《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

NordVPN

隨機商業新聞