工程哲學：Margaret Hamilton

重點摘要

• 她創造了「軟體工程」一詞，為這門學科贏得正當性。 在麻省理工儀器實驗室領導阿波羅飛行軟體工作時，Margaret Hamilton 開始刻意將這份工作稱為「軟體工程」——她要主張，撰寫那些把人類送上月球的程式碼，理應獲得與硬體工程、系統工程同等的嚴謹與尊重；而在當時，軟體只被當成事後才考慮的附帶之物。¹²
• 當導引電腦拋出 1202 與 1201 警報時，是她的軟體救下了阿波羅 11 號的登月。 在最後降落階段，一個設定錯誤的會合雷達開關，餵給阿波羅導引電腦它本不該處理的虛假工作，使得執行系統耗盡了排程所需的記憶體——這就是著名的 1202（「無核心組可用」）與 1201（「無 VAC 區可用」）警報。由於 Hamilton 的團隊以優先權排程與重啟保護打造了這套軟體，電腦得以拋棄低優先權的雷達工作，讓登月關鍵的導引持續運作，登月也因此成功。³⁴⁵
• 她最核心的信念是防禦式設計：為失敗情境而設計，因為沒有第二次機會。 談到阿波羅時，她說：「沒有第二次機會。我們很清楚這一點。」² 錯誤偵測、復原、非同步優先權排程，以及納入人類判斷的顯示介面，並非在順利路徑跑通之後才加裝上去的功能——它們本身就是設計的核心，正是軟體得以優雅降級而非當機的原因。⁶
• 她從一開始就把正確性建構進系統——「事前開發」。 阿波羅之後，她創立了 Higher Order Software（1976 年） 與 Hamilton Technologies（1986 年），開發出 通用系統語言（USL） 以及一套方法論：以建構的方式讓整類錯誤從根本上不可能發生，而非靠測試去捕捉。她獲頒 NASA 傑出太空法案獎（2003 年） 與 總統自由勳章（2016 年）。¹⁶

核心原則

「沒有第二次機會。我們很清楚這一點。我們認真看待自己的工作，許多人在二十多歲時就踏上了這段旅程。」——Margaret Hamilton，談阿波羅飛行軟體²

大多數工程是為一切順利運作的情境而最佳化。你寫出順利路徑、處理幾種想得到的錯誤，然後出貨——當某處在正式環境壞掉時，再修補、重新部署。這個迴圈，是幾乎所有軟體賴以安身的慰藉：失敗是可復原的，因為永遠還有下一次機會。Hamilton 的工作卻是從相反的前提出發。她所領導的軟體，要載著三個人飛離地球二十五萬英里，並讓其中兩人登上月球，而沒有修補、沒有重新部署、沒有下一次機會。 它必須一次就成功，在無人能完整演練的條件下，跑在一台記憶體比會奏樂的賀卡還少的電腦上。² 當單一未捕捉錯誤的代價是整組機組人員時，「為失敗情境而設計」就不再只是好建議，而成了工作的全部。

由此而生的原則是：防禦式設計是設計的核心，而非善後。 如果軟體必須在意外中存活，那麼偵測錯誤、從中復原、優雅降級就不能是順利路徑完成後才補上的功能——它們必須是順利路徑賴以掛靠的骨架。Hamilton 的團隊這樣打造阿波羅軟體：讓電腦能察覺自己被要求做超出能力的事，拋棄無關緊要的工作，乾淨地重啟回到已知良好的狀態，並持續做那件一旦停下就會害死機組人員的事。 這套系統並非為了避免一切失敗而打造——在如此渺小的機器上、面對如此不容差錯的任務，你做不到。它是為了在失敗來臨時，讓失敗是可存活的而打造。³⁶

這原則還有後半段，正是它讓前半段成真：從一開始就把正確性建構進系統，而非到最後才把錯誤測試出來。 在執行期偵測並復原錯誤，是最後一道防線；更深層的修養，是把系統設計成讓整類錯誤從一開始就不可能出現。Hamilton 的職業生涯後半段，正是在把這件事形式化——她稱之為「事前開發」的方法論，以及一套讓介面錯誤在結構上不可能發生的語言。⁶ 這兩個半段其實是同一個理念，從兩種距離看：當沒有第二次機會，你既在執行期防禦，也在設計期讓失敗無從表述，因為你唯一能完全信任的錯誤，是系統根本無從犯下的那種。

背景脈絡

Margaret Hamilton 於 1936 年 8 月 17 日出生於印第安納州的 Paoli，本名 Margaret Heafield。¹ 她在 Earlham College 攻讀數學，1958 年取得學位，並輔修哲學——這個組合後來體現在她思考系統（而不只是程式碼）的方式上。¹ 她並非透過電腦科學的培養管道走進阿波羅，因為在 1950 年代末根本沒有這種東西；她是憑藉數學、憑藉工作本身走進來的。

她最早的程式設計，從一開始就是真槍實彈、攸關重大。1959 年，她開始在麻省理工的氣象學系工作，與混沌理論之父 Edward Lorenz 共事，在 LGP-30 與 PDP-1 上撰寫天氣預測軟體。¹ 大約從 1961 到 1963 年，她在麻省理工林肯實驗室參與 SAGE 計畫，為美國空軍用來偵測來襲航空器的 AN/FSQ-7 電腦撰寫軟體。¹ SAGE 是史上最早的大型即時、對故障敏感的軟體系統之一，而她在那裡贏得的聲譽——敢於接下最艱難、最容易出錯的程式碼——正是把她帶向阿波羅的原因。

1965 年，她加入麻省理工儀器實驗室（後來的 Draper Lab），該實驗室握有為 NASA 阿波羅計畫打造機載飛行軟體的合約。她一路晉升到主掌軟體工程部門，領導團隊負責那套跑在指揮艙與登月艙阿波羅導引電腦上的機載飛行軟體。¹ 正是在這裡、在這份工作的當中，她開始使用「軟體工程」一詞——不是當成流行語，而是當成一項主張。如她所言，她使用這個詞是「為了把它與硬體及其他種類的工程區分開來，同時把每一種工程都當成整體系統工程流程的一部分」。¹ 她堅持，軟體是一門應有其名、並隨之而來該有其嚴謹的學科。阿波羅之後，她於 1976 年創立 Higher Order Software、1986 年創立 Hamilton Technologies，在那裡開發出 通用系統語言 與「事前開發」方法論。¹⁶

這份工作

阿波羅 11 號的 1202 警報：優先權排程與重啟保護

就從這裡開始，因為這是原則在最嚴酷壓力下化為機制的時刻。阿波羅導引電腦是一台極小的機器——記憶體僅數十 KB，沒有現代意義上的作業系統——跑著一套 Hamilton 團隊設計的即時執行系統。要執行一個工作，執行系統必須找到空閒記憶體：一個 「核心組」（存放該工作狀態的小區塊），以及（對於做浮點運算的工作）一個 「VAC 區」。⁴ 若一個工作被排程卻沒有空閒的核心組，執行系統就會跳轉到它的警報常式，並發出 1202 警報；若沒有空閒的 VAC 區，就發出 1201。⁴ 這些不是當機代碼。它們是執行系統在宣告它被要求做超出自身容量的事——然後對此採取行動。

在阿波羅 11 號降落的最後幾分鐘，發生的正是這件事。太空人檢查清單讓機組人員把會合雷達開關留在錯誤的位置，導致雷達竊取處理器週期，使執行系統反覆排程那些本不該運作的資料處理工作。³⁴ 這些虛假工作耗盡了所有空閒記憶體，於是 1202 警報觸發——接著再次觸發，1201 警報也出現，在著陸前的數秒間共響了四次。一台天真的電腦，被要求做每一件事，就會試圖去做每一件事，在那唯一重要的工作上落後，然後凍結。Hamilton 的電腦沒有。

是兩項設計決策救下了登月。第一項是優先權排程：執行系統依優先權執行工作，並能拋棄優先權最低的工作，因此登月關鍵的導引與機組顯示介面（DSKY）始終運作，而垃圾雷達工作則被餓死。³⁵ 第二項是重啟保護：每次警報都觸發一次軟體重啟，清空過載的工作佇列，重開機回到已知良好的狀態，重新啟動「重要的東西，比如操控下降引擎、運作 DSKY」，但不重啟那些被錯誤排程的雷達工作。⁴⁵ 電腦實際上把雜訊丟掉、繼續駕駛太空船，並告訴機組人員它正在處理——這正是為什麼任務管制中心能對一個警報喊出「go」；若換成較差的設計，那個警報本意味著中止。

它作為工程之所以重要的原因：警報本身不是失敗——它是失敗處理依設計正常運作。 團隊把執行系統打造成預期過載、在過載下分流、並從中復原，而且他們把這套復原測試得如此徹底，以至於管制員在任何軟體所承受過的最大壓力下，仍然信任它。這就是整套信條濃縮於一瞬：失敗是被預設的，失敗情境就是設計的核心，系統會降級到「只做那件讓機組人員活命的事」，而不是垮掉。同樣的本能至今活在每一個會卸載負荷的優先權佇列裡、每一個會把當掉的工作者重啟回乾淨狀態的監督程序裡、每一個為了在被壓垮時仍能存活而打造的系統裡。

創造「軟體工程」一詞，以及對正當性的爭取

1202 的故事很有名；但這個命名，可以說影響更為深遠。在 1960 年代，軟體被廣泛當成「真正」工程那柔軟、不正經的弟弟——是硬體設計完之後才弄出來的東西，而非一門有自身嚴謹的學科。Hamilton 拒絕這種框架。在阿波羅內部，她開始刻意把這份工作稱為「軟體工程」，而且對原因直言不諱：要「把它與硬體及其他種類的工程區分開來，同時把每一種工程都當成整體系統工程流程的一部分」。¹ 重點不在於用詞。重點在於地位。 如果飛行任務的程式碼是工程，那它就應得工程的修養：規格、審查、測試、可追溯性，以及它必須被做正確、而不只是被做到能跑的期待。

她說過，這個詞一開始招來的是莞爾——軟體竟然能是「工程」，這想法讓人覺得有點牽強。¹ 但她所爭取的正當性，是承重的。如果這份工作被當成隨手寫的腳本、之後總有人會來收拾，你就無法要求一個團隊為失敗情境而設計、把錯誤復原打進系統的骨子裡、並把正確性視為不可妥協。為這門學科命名，是要求它達到某種標準的先決條件。到了那個十年的尾聲，這個詞已逃出麻省理工，成為一整個領域的名稱；如今「軟體工程」如此尋常以至於隱形，而這正是那場爭辯已然勝出最確鑿的徵兆。¹²

防禦式設計：「Lauren bug」與對抗人性的工程

若你想要一扇最清楚的窗，看見 Hamilton 如何思考，那就是 「Lauren bug」。她年幼的女兒 Lauren 有時會來實驗室，在指揮艙模擬器上扮太空人，有一天她把它弄當機了——在模擬太空船已飛往月球的途中，選了 P01，也就是發射前程式。⁷ 在航程中段載入發射前初始化，抹掉了導航資料，讓電腦失去方向。Hamilton 的本能不是「沒有哪個太空人會那樣做」。而是：如果模擬器讓一個孩子做得到，那軟體就允許了它；而軟體所允許的任何事，終究都會發生。 她提議加入錯誤偵測程式碼，以防在飛行中選到 P01。⁷

她的提議被駁回了——理由是太空人都是受過訓練的專業人士，絕不會犯這種錯——她只被允許在文件中加一條註記。⁷ 然後，就在緊接著的下一次任務 阿波羅 8 號上，Jim Lovell 做了和 Lauren 一模一樣的事，在飛行途中選了 P01，在人類首次繞月之旅中抹掉了導航資料。⁷ 在那之後，修正才被加了進去。Hamilton 得出並一再重申的教訓，正是防禦式設計的核心：你不能斷定一個失敗「不可能發生」，然後當它不會發生那樣去設計。太空人、雷達開關、凌晨三點的操作員——系統必須對迴圈中的人保持穩健，而不是靠假設人會完美無瑕來免於究責。她的優先權顯示介面從另一個方向體現了同樣的理念：讓人保持知情並掌握控制，如此一來，當電腦在過載下分流時，機組人員明白它在做什麼，並能做出決定。⁶

Higher Order Software、USL 與「事前開發」

阿波羅教會了 Hamilton 錯誤從何而來，而她用餘下的職業生涯，從根源攻擊它們。研究阿波羅的錯誤時，她觀察到其中很大一部分並非住在個別模組內部，而是住在模組之間的介面裡——也就是一段軟體把資料交給另一段、而雙方假設並不完全相符的地方。在 Higher Order Software（1976 年） 以及後來的 Hamilton Technologies（1986 年），她圍繞著以建構方式消除這些錯誤、而非靠測試捕捉它們，建立起一整套成果。¹⁶

這套方法論名為 「事前開發」。這個名字就是論點本身：與其先打造一套系統、然後在事後獵捕缺陷，你改用一套形式系統——通用系統語言（USL）——如此嚴謹地把它定義出來，使得整類錯誤，尤其是介面與整合錯誤，在結構上不可能發生。這個模型是可證明一致的，而且可以從中產生正確的程式碼，因此缺陷是在設計期被預防，而不是在執行期被發現。⁶ 這與阿波羅執行系統是同一個信念，只是再往深推一層：執行期復原是安全網，但真正的勝利，是一套從一開始就無從犯下那個錯誤的系統。業界大多數人至今仍跑著相反的迴圈——出貨、找出 bug、修補——而這正是 Hamilton 花了三十年主張、在正確性真正攸關重大時根本顛倒了的那個迴圈。

方法

橫看阿波羅執行系統、「軟體工程」一詞的創造、Lauren bug，以及事前開發，同樣的信念一再出現。Hamilton 的方法與其說是一句口號，不如說是一組長存的習慣。

先為失敗情境而設計——沒有第二次機會。 阿波羅執行系統不是一個外掛了過載處理的排程器；在過載中存活本身就是設計，因為一台在月球上方凍結的電腦會害死機組人員。³⁴ 這個教訓遠遠超出太空飛行：在寫下系統能運作的路徑之前，先列舉它如何失敗，並讓能運作的路徑從一個早已能撐過那些失敗的結構中自然落出。這是把證據門檻套用在可靠性上——「它在模擬器裡能跑」不是證據；「當雷達把它淹沒時，它卸載負荷並持續飛行」才是——這正是數十年後 Werner Vogels 把優雅降級立為雲端開創前提時所用的同一個標準。

假設人會做出那件不可能的事。 Lauren bug 是這條規則的縮影：如果系統允許一個危險動作，終究會有人——一個孩子、一個太空人、一個疲憊的操作員——去執行它，所以「沒有人會那樣做」不構成辯護。⁷ 長存的習慣，是去守衛邊界、防範那個你被保證永遠不會抵達的輸入，因為傷害最深的失敗，正是那些你事先斷定不可能發生的。這與 Radia Perlman 打進路由裡、讓它即使在節點說謊時仍保持正確的「對抗對手的穩健性」本能，是同一個。

在負荷下分流——拋棄不重要的，保護關鍵的。 當執行系統耗盡記憶體時，它沒有試圖服務每一個請求；它執行優先權最高的工作、餓死其餘，然後乾淨重啟。³⁵ 這份修養，是事先決定那件絕不能停下的事是什麼，並把系統打造成在壓力下犧牲其他一切、好讓那一件事持續運作。一個沒有優先權的系統，是一個會在最糟時刻失敗的系統，因為它把機組顯示介面和垃圾雷達工作當成了同等。

把正確性建構進去，別把它測試進去。 事前開發是對「先出貨再除錯」迴圈的拒絕：把系統定義成讓錯誤無從表述，而不是先打造它、再事後獵捕錯誤。⁶ 教訓在於，最便宜、最值得信任的缺陷，是被設計弄成不可能的那一個——這與 Barbara Liskov 化為型別修養與抽象的信念相同，也與 Leslie Lamport 化為「在寫程式碼之前先精確指定正確性」的信念相同。這是把品質是唯一的變數化為一套工作流程：正確性不是最後的一個階段，它從一開始就是這個東西的形狀。

為這門學科命名，好讓你能據以要求它達到某種標準。 把這份工作稱為「軟體工程」，是那個授權了其餘一切的舉動——規格、審查、對嚴謹的期待。¹ 長存的習慣，是堅持這份工作有其名、有其標準，因為你無法對一個組織視為可拋棄的東西要求匠藝。這是最低限度值得之作的精神：這件事值得好好做，所以你好好做，並且大聲地把「好好做才是唯一可接受的方式」這個論點講出來。

影響鏈

是誰塑造了她

麻省理工的數學與即時系統傳統。 Hamilton 是憑數學、憑 SAGE——史上最早的大型即時、對故障敏感的軟體系統之一——以及憑與混沌理論之父 Edward Lorenz 一同進行的天氣建模一路走來的。¹ 這份根柢看得出來：早在抵達阿波羅之前，她就把軟體想成一套必須在無人能完整預測的條件下保持正確的系統。（奠基性影響）

太空飛行本身那不容差錯的修養。 阿波羅任務，和任何一個人一樣，都是老師。一個單一錯誤就要付出機組人員代價、沒有修補也沒有第二次機會的領域，逼出了一種工作方式——防禦失敗情境、在執行期復原、在設計期預防錯誤——而這是平凡的軟體從不會要求的。約束塑造了哲學。（直接影響）

阿波羅計畫的系統工程文化。 在一個她的軟體必須與硬體、任務管制和人類程序整合的計畫內部工作，推使她把軟體看成數種工程學科中的一種——而這正是她把「軟體工程」創造為「整體系統工程流程」一部分背後的那個框架。¹（奠基性影響）

是她塑造了誰

軟體工程這門學科本身。 透過為這個領域命名、並從那個時代最高風險的軟體計畫內部主張它的嚴謹，Hamilton 幫助把程式設計從一件事後才考慮的附帶之物，轉變成一門有規格、有審查、有正確性期待的工程學科。¹²

每一套容錯的即時系統。 優先權排程、負荷卸載、重啟回已知良好狀態，以及納入人類判斷的顯示介面——阿波羅執行系統用來撐過 1202 警報的這些模式——如今已是韌性系統的標準詞彙，從飛行控制，到讓網路服務在過載下存活的監督程序。³⁶

形式化、以建構保證正確的方法。 事前開發與通用系統語言，是那條主張「正確性應在設計期被建構並可被證明、而非在事後被測試出來」的脈絡的一部分——這條論點貫穿形式化方法與模型驅動開發，直至今日。⁶

貫穿的主線

Hamilton 是本系列中可靠性脈絡的起源點——是「為失敗情境而設計」從一種偏好變成不可妥協之事的那個地方，因為有生命繫於其上，而這比領域中其他人趕上來早了數十年。Werner Vogels 把雲端建立在「一切總會以各種方式失敗」之上，並為行星級規模的優雅降級而設計；Hamilton 則是在一台公事包大小的電腦上、頭頂還載著機組人員的情況下，為優雅降級而設計，並在真正沒有第二次機會時，證明了這套信條行得通。³ Radia Perlman 打造了能自我修復、即使節點說謊也保持正確的網路；Hamilton 的執行系統則是在月球上方即時自我修復，乾淨重啟，並拋掉壞掉的雷達餵給它的謊言。⁴ 而 Leslie Lamport 讓正確性成為你在動手打造之前先精確定義並證明的東西——這正是事前開發所企及的，只是早了一個世代，並瞄準同一個目標。⁶ Vogels 說一切都會失敗，所以要撐過它保持可用，Perlman 說把它打造成能自我修復，而 Hamilton 說得最早、也最徹底：沒有第二次機會，所以要在失敗發生之前就為它而設計，在它發生時從中復原，並把系統打造成最糟的錯誤根本從來不可能發生。（系列橋接）

我從中學到什麼

我從 Hamilton 身上保留的教訓，是要把每件事都當成沒有第二次機會那樣去打造，即使明明就有。我所出貨的幾乎一切，都活在她不曾擁有的那份慰藉裡：如果壞了，我推一個修正。那張安全網是真實的，而它悄悄拉低了門檻——它讓我出貨順利路徑，並告訴自己稍後再來處理失敗情境，因為「稍後」是存在的。阿波羅就是那記當頭棒喝。當你真的無法修補它時，你會發現「稍後處理失敗」根本從來不是工程；失敗情境就是那份工程，而能運作的路徑，只是系統已先撐過被弄壞之後剩下的東西。所以現在當我打造某樣東西時——一個可能被淹沒的工作、一個可能被錯誤呼叫的 API、一條可能在錯誤時機被走過的路徑——在我問順利路徑是否能跑之前，我會試著先問「此處那個位置錯誤的雷達開關是什麼，而這套東西能否把它卸掉並持續飛行？」一個只在輸入正確時才能存活的系統，是一個我尚未完成的系統。

第二個教訓，是最值得信任的錯誤，是被設計弄成不可能的那一個。Lauren bug 一直留在我心裡，因為 Hamilton 是對的，卻被「沒有人會那樣做」駁回了——而宇宙立刻就做了那件事，就在下一次任務上。我的本能是在執行期捕捉錯誤，把危險的呼叫包進一個防護裡然後繼續往前。Hamilton 更深的一步、她花了三十年的那一步，是把系統設計成讓那個危險的呼叫根本無法被做出來——讓壞掉的狀態無從表述，而不只是被偵測到。執行期復原是那張網；把正確性建構進去，才是你立足、好讓自己不需要那張網的地面。我並非總能搆到那個門檻，但它重新框定了目標：問題不只是「當它出錯時我會捕捉到嗎？」，而是「我能否把它塑造成從一開始就不可能出錯？」——而第二個問題，當我能回答它時，永遠是更好的那一個。

常見問題

Margaret Hamilton 創造了「軟體工程」一詞嗎？

Margaret Hamilton 被廣泛認為創造了——或至少推廣了——「軟體工程」一詞，她在 1960 年代於麻省理工儀器實驗室領導阿波羅飛行軟體工作時開始使用這個詞。¹² 她刻意用它來主張，撰寫軟體理應獲得與硬體及其他工程學科同等的正當性與嚴謹，並解釋說她想要「把它與硬體及其他種類的工程區分開來，同時把每一種工程都當成整體系統工程流程的一部分」。¹ 在當時，軟體竟然能是「工程」這個想法招來了一些莞爾；如今這個詞如此標準以至於隱形，而這正是衡量那場爭辯被贏得有多徹底的尺度。¹

阿波羅 11 號期間的 1202 與 1201 警報是什麼？

它們是阿波羅導引電腦的執行系統，在登月降落最後幾分鐘所發出的程式警報。一個設定錯誤的會合雷達開關導致雷達竊取處理器週期，使執行系統反覆排程那些本不該運作的資料處理工作，耗盡了所有空閒記憶體。³⁴ 當沒有記憶體「核心組」可用時，執行系統發出 1202 警報；當沒有「VAC 區」可用時，發出 1201。⁴ 這些警報不是當機——它們是執行系統回報它被要求做超出能力的事，然後進行分流。由於軟體採用了優先權排程與重啟保護，它拋棄了虛假的雷達工作，重啟回到已知良好的狀態，讓登月關鍵的導引與機組顯示介面持續運作，登月也因此成功。³⁵

Margaret Hamilton 為阿波羅計畫做了什麼？

Hamilton 於 1965 年加入麻省理工儀器實驗室，一路晉升到主掌軟體工程部門，負責那套跑在指揮艙與登月艙阿波羅導引電腦上的機載飛行軟體。¹ 她的團隊以非同步優先權排程、重啟保護、錯誤偵測與復原，以及讓太空人保持知情並掌握控制的優先權顯示介面，設計出那套即時執行系統——正是這套架構，讓阿波羅 11 號的電腦得以撐過 1202 警報並完成登月。³⁶ 她的總統自由勳章引文，讚揚她貢獻了「非同步軟體、優先權排程與優先權顯示，以及納入人類判斷的決策能力等概念，為現代、超高可靠性的軟體設計與工程奠定了基礎」。⁶

什麼是「事前開發」？

「事前開發」是 Hamilton 在阿波羅之後，於 Higher Order Software 與 Hamilton Technologies 開發出的系統方法論，圍繞著她的 通用系統語言（USL） 建構。¹⁶ 它的論點是：與其先打造一套系統、然後透過測試在「事後」獵捕缺陷，你改用如此嚴謹而形式化的方式去定義系統，使得整類錯誤——尤其是她發現主宰了阿波羅缺陷的那些介面與整合錯誤——以建構的方式在結構上不可能發生。⁶ 這個模型是可證明一致的，而且可以從中產生正確的程式碼，因此缺陷是在設計期被預防，而非在執行期被發現。這是她阿波羅信念的形式化方法版本：最值得信任的錯誤，是系統根本從未能犯下的那一個。

來源