Filozofia inżynierii: Margaret Hamilton

Najważniejsze wnioski

• Ukuła termin „software engineering”, aby wywalczyć tej dyscyplinie należną jej rangę. Kierując pracami nad oprogramowaniem lotu Apollo w MIT Instrumentation Laboratory, Margaret Hamilton zaczęła określać tę pracę mianem „software engineering” — i robiła to świadomie, by przekonywać, że pisanie kodu, który zaniósł ludzi na Księżyc, zasługuje na tę samą rygorystyczność i ten sam szacunek co inżynieria sprzętu i systemów, w czasach, gdy oprogramowanie traktowano jak sprawę drugorzędną.¹²
• Jej oprogramowanie uratowało lądowanie Apollo 11, gdy komputer naprowadzania zgłosił alarmy 1202 i 1201. Podczas końcowego zejścia źle ustawiony przełącznik radaru spotkaniowego zlecił komputerowi naprowadzania Apollo (Apollo Guidance Computer) zbędną pracę, której nigdy nie powinien był wykonywać, a programowi wykonawczemu zabrakło pamięci, by ją zaplanować — stąd słynne alarmy 1202 („no core sets”) i 1201 („no VAC areas”). Ponieważ zespół Hamilton zbudował oprogramowanie z planowaniem priorytetowym i ochroną przez restart, komputer odrzucił niskopriorytetowe zadania radaru, utrzymał krytyczne dla lądowania naprowadzanie, i lądowanie się powiodło.³⁴⁵
• Jej naczelną zasadą jest projektowanie defensywne: projektuj z myślą o przypadku awarii, bo drugiej szansy nie ma. „Nie było drugiej szansy. Wiedzieliśmy o tym” — mówiła o Apollo.² Wykrywanie i odzyskiwanie po błędach, asynchroniczne planowanie priorytetowe oraz wyświetlacze z człowiekiem w pętli nie były dodatkami dokręconymi po tym, jak ścieżka optymistyczna już działała — stanowiły rdzeń projektu, powód, dla którego oprogramowanie degradowało się łagodnie, zamiast się zawieszać.⁶
• Wbudowywała poprawność od samego początku — „Development Before the Fact”. Po Apollo założyła Higher Order Software (1976) i Hamilton Technologies (1986), rozwijając Universal Systems Language (USL) oraz metodologię projektowania systemów tak, by całe klasy błędów były z konstrukcji niemożliwe, zamiast wyłapywane testami. Otrzymała NASA Exceptional Space Act Award (2003) oraz Prezydencki Medal Wolności (2016).¹⁶

Zasada

„Nie było drugiej szansy. Wiedzieliśmy o tym. Traktowaliśmy naszą pracę poważnie, a wielu z nas rozpoczynało tę drogę, mając niewiele ponad dwadzieścia lat.” — Margaret Hamilton o oprogramowaniu lotu Apollo²

Większość inżynierii optymalizuje pod przypadek, w którym wszystko działa. Buduje się ścieżkę optymistyczną, obsługuje kilka błędów, które da się sobie wyobrazić, i wypuszcza produkt — a kiedy coś psuje się na produkcji, łata się to i wdraża ponownie. Ta pętla jest wygodą, w której żyje niemal całe oprogramowanie: awaria jest do naprawienia, bo zawsze istnieje kolejna szansa. Praca Hamilton wychodziła z odwrotnego założenia. Oprogramowanie, którym kierowała, miało zanieść trzech ludzi ćwierć miliona mil od Ziemi i posadzić dwóch z nich na Księżycu — i nie było żadnej łatki, żadnego ponownego wdrożenia, żadnej kolejnej szansy. Musiało zadziałać za pierwszym razem, w warunkach, których nikt nie był w stanie w pełni przećwiczyć, na komputerze o pamięci mniejszej niż kartka z życzeniami odgrywająca melodię.² Gdy ceną jednego nieprzechwyconego błędu jest życie załogi, „projektuj z myślą o przypadku awarii” przestaje być dobrą radą, a staje się całą istotą pracy.

Zasada, która z tego wynika, brzmi: projektowanie defensywne to rdzeń projektu, a nie sprzątanie po fakcie. Jeśli oprogramowanie ma przetrwać to, co nieprzewidziane, to wykrywanie błędów, odzyskiwanie po nich i łagodna degradacja nie mogą być funkcjami dodawanymi po skończeniu działającej ścieżki — muszą stanowić szkielet, na którym ta ścieżka się opiera. Zespół Hamilton zbudował oprogramowanie Apollo tak, by komputer mógł zauważyć, że proszony jest o więcej, niż jest w stanie wykonać, odrzucić pracę, która nie ma znaczenia, zrestartować się czysto do znanego dobrego stanu i robić dalej tę jedną rzecz, której zatrzymanie zabiłoby załogę. System nie został zbudowany tak, by uniknąć każdej awarii — na tak małej maszynie, przy tak bezlitosnej misji, jest to niemożliwe. Został zbudowany tak, by gdy awaria nadejdzie, dało się ją przeżyć.³⁶

Zasada ma jeszcze drugą połowę i to ona urzeczywistnia pierwszą: wbudowuj poprawność od początku, zamiast wytestowywać błędy na końcu. Wykrywanie błędu i odzyskiwanie po nim w czasie działania to ostatnia linia obrony; głębsza dyscyplina to zaprojektowanie systemu tak, by całe kategorie błędów w ogóle nie mogły się pojawić. Hamilton poświęciła drugą połowę swojej kariery właśnie na sformalizowanie tego — metodologii, którą nazwała „Development Before the Fact”, oraz języka stworzonego po to, by błędy interfejsów stały się strukturalnie niemożliwe.⁶ Obie połowy to jedna idea oglądana z dwóch odległości: gdy nie ma drugiej szansy, bronisz się w czasie działania i zarazem sprawiasz, że awaria jest niereprezentowalna już na etapie projektu, bo jedyny błąd, któremu można w pełni zaufać, to ten, którego system nigdy nie był w stanie popełnić.

Kontekst

Margaret Hamilton urodziła się jako Margaret Heafield 17 sierpnia 1936 roku w Paoli w stanie Indiana.¹ Studiowała matematykę w Earlham College, gdzie w 1958 roku zdobyła dyplom z dodatkowym kierunkiem z filozofii — połączenie, które później widać w jej sposobie myślenia o systemach, nie tylko o kodzie.¹ Nie trafiła do Apollo przez ścieżkę informatyczną, bo pod koniec lat 50. coś takiego nie istniało; trafiła tam przez matematykę i przez samą pracę.

Jej pierwsze programowanie od początku dotyczyło realnych, wysokiej stawki problemów. W 1959 roku zaczęła pracować w wydziale meteorologii MIT u Edwarda Lorenza — twórcy teorii chaosu — pisząc oprogramowanie do prognozowania pogody na maszynach LGP-30 i PDP-1.¹ Od mniej więcej 1961 do 1963 roku pracowała przy projekcie SAGE w MIT Lincoln Laboratory, pisząc oprogramowanie dla komputera AN/FSQ-7, którego Siły Powietrzne USA używały do wykrywania nadlatujących samolotów.¹ SAGE był jednym z pierwszych dużych systemów oprogramowania działających w czasie rzeczywistym i wrażliwych na awarie, jakie kiedykolwiek zbudowano, a reputacja, którą tam zdobyła — za podejmowanie się najtrudniejszego, najbardziej podatnego na błędy kodu — zaprowadziła ją do Apollo.

W 1965 roku dołączyła do MIT Instrumentation Laboratory (później Draper Lab), które miało kontrakt na zbudowanie pokładowego oprogramowania lotu dla programu Apollo NASA. Awansowała na stanowisko kierowniczki Software Engineering Division, prowadząc zespół odpowiedzialny za pokładowe oprogramowanie lotu działające na komputerze naprowadzania Apollo, zarówno w module dowodzenia, jak i w module księżycowym.¹ To właśnie tutaj, w trakcie tej pracy, zaczęła używać terminu „software engineering” — nie jako modnego hasła, lecz jako argumentu. Jak sama to ujęła, używała tego terminu, by „odróżnić to od inżynierii sprzętu i innych rodzajów inżynierii, a zarazem traktować każdy z tych rodzajów inżynierii jako część całościowego procesu inżynierii systemów”.¹ Oprogramowanie, jak twierdziła, było dyscypliną, która zasługuje na nazwę i na rygor, który się z nią wiąże. Po Apollo założyła Higher Order Software w 1976 roku oraz Hamilton Technologies w 1986 roku, gdzie rozwinęła Universal Systems Language oraz metodologię „Development Before the Fact”.¹⁶

Dzieło

Alarm 1202 Apollo 11: planowanie priorytetowe i ochrona przez restart

Zacznijmy stąd, bo to zasada przekuta w mechanizm pod najgorszą możliwą presją. Komputer naprowadzania Apollo był maleńką maszyną — kilkadziesiąt kilobajtów pamięci, bez systemu operacyjnego w nowoczesnym sensie — działającą na programie wykonawczym czasu rzeczywistego, który zaprojektował zespół Hamilton. Aby uruchomić zadanie, program wykonawczy musiał znaleźć wolną pamięć: „core set” (mały blok na stan zadania) oraz, dla zadań operujących na liczbach zmiennoprzecinkowych, „VAC area”.⁴ Jeśli zadanie zostało zaplanowane, a żaden core set nie był wolny, program wykonawczy przechodził do swojej procedury alarmowej i zgłaszał alarm 1202; jeśli wolnego nie było żadnego VAC area, zgłaszał 1201.⁴ To nie były kody awarii. To program wykonawczy oznajmiał, że poproszono go o więcej, niż mieścił w swojej pojemności — i robił z tym coś.

Podczas ostatnich minut zejścia Apollo 11 stało się dokładnie to. Lista kontrolna astronautów kazała załodze zostawić przełącznik radaru spotkaniowego w niewłaściwym położeniu, przez co radar zaczął podkradać cykle procesora i sprawił, że program wykonawczy wielokrotnie planował zadania przetwarzania danych, które w ogóle nie powinny były działać.³⁴ Zbędna praca pochłonęła całą wolną pamięć i zgłoszony został alarm 1202 — potem znowu, a do tego alarm 1201, cztery razy w sekundach poprzedzających przyziemienie. Naiwny komputer poproszony o zrobienie wszystkiego próbowałby zrobić wszystko, zacząłby zostawać w tyle z tym jednym zadaniem, które miało znaczenie, i zamarłby. Komputer Hamilton tego nie zrobił.

Lądowanie uratowały dwie decyzje projektowe. Pierwszą było planowanie priorytetowe: program wykonawczy uruchamiał zadania według priorytetu i mógł odrzucać te o najniższym priorytecie, dzięki czemu krytyczne dla lądowania naprowadzanie oraz wyświetlacz załogi (DSKY) działały zawsze, podczas gdy śmieciowe zadania radaru były zagładzane.³⁵ Drugą była ochrona przez restart: każdy alarm wyzwalał programowy restart, który czyścił przeciążoną kolejkę zadań i ponownie uruchamiał system do znanego dobrego stanu, restartując „to, co ważne, jak sterowanie silnikiem zejścia i obsługę DSKY”, ale nie restartując błędnie zaplanowanych zadań radaru.⁴⁵ Komputer w praktyce odrzucał szum, wciąż prowadził statek i informował załogę, że sobie radzi — i dlatego centrum sterowania lotem mogło zezwolić na kontynuację mimo alarmu, który przy słabszym projekcie oznaczałby przerwanie misji.

Dlaczego ma to znaczenie jako inżynieria: alarm nie był awarią — był obsługą awarii działającą zgodnie z projektem. Zespół zbudował program wykonawczy tak, by spodziewał się przeciążenia, by w jego trakcie dokonywał triażu i by się po nim odzyskiwał — a odzyskiwanie to przetestowali tak gruntownie, że kontrolerzy zaufali mu pod największą presją, pod jaką kiedykolwiek znalazło się jakiekolwiek oprogramowanie. To cała doktryna zamknięta w jednej chwili: awarię założono z góry, przypadek awarii był rdzeniem projektu, a system degradował się do „rób tylko tę jedną rzecz, która utrzymuje załogę przy życiu”, zamiast się przewrócić. Ten sam instynkt żyje dziś w każdej kolejce priorytetowej, która odrzuca obciążenie, w każdym nadzorcy, który restartuje uszkodzonego pracownika do czystego stanu, w każdym systemie zbudowanym tak, by przetrwać własne przeciążenie.

Ukucie terminu „software engineering” i walka o rangę

Historia alarmu 1202 jest sławna; nazwanie dyscypliny ma jednak prawdopodobnie jeszcze większe znaczenie. W latach 60. oprogramowanie powszechnie traktowano jako miękkie, niepoważne rodzeństwo „prawdziwej” inżynierii — coś, co rozgryza się po zaprojektowaniu sprzętu, a nie dyscyplinę z własnym rygorem. Hamilton odrzuciła to ujęcie. Wewnątrz Apollo zaczęła świadomie nazywać tę pracę „software engineering” i jasno tłumaczyła, dlaczego: by „odróżnić to od inżynierii sprzętu i innych rodzajów inżynierii, a zarazem traktować każdy z tych rodzajów inżynierii jako część całościowego procesu inżynierii systemów”.¹ Nie chodziło o słownictwo. Chodziło o pozycję. Jeśli kod, który prowadził misję, był inżynierią, to zasługiwał na inżynierską dyscyplinę: specyfikacje, przeglądy, testowanie, identyfikowalność oraz oczekiwanie, że zostanie uczyniony poprawnym, a nie tylko zmuszony do działania.

Sama mówiła, że termin początkowo spotkał się z rozbawieniem — pomysł, że oprogramowanie mogłoby być „inżynierią”, wydawał się ludziom naciągany.¹ Lecz ranga, o którą walczyła, była nośna. Nie da się wymagać od zespołu, by projektował z myślą o przypadku awarii, wbudowywał odzyskiwanie po błędach w fundamenty systemu i traktował poprawność jako rzecz nienegocjowalną, jeśli tę pracę uznaje się za luźne skryptowanie, które ktoś później posprząta. Nazwanie dyscypliny było warunkiem koniecznym, by móc ją rozliczać z określonego standardu. Pod koniec dekady termin wyrwał się poza MIT i stał się nazwą całej dziedziny; dziś „software engineering” jest tak zwyczajne, że niewidzialne — co jest najpewniejszym znakiem, że argument został wygrany.¹²

Projektowanie defensywne: „błąd Lauren” i inżynieria wbrew człowiekowi

Jeśli ktoś chce najwyraźniejszego okna na to, jak myślała Hamilton, jest nim „błąd Lauren”. Jej mała córeczka Lauren przychodziła czasem do laboratorium i bawiła się w astronautę na symulatorze modułu dowodzenia, aż pewnego dnia go zawiesiła — wybierając P01, program przedstartowy, podczas gdy symulowany statek był już w połowie drogi na Księżyc.⁷ Załadowanie inicjalizacji przedstartowej w trakcie lotu wymazywało dane nawigacyjne i pozostawiało komputer zagubionym. Instynkt Hamilton nie brzmiał: „żaden astronauta nigdy by tego nie zrobił”. Brzmiał: skoro symulator pozwolił zrobić to dziecku, oprogramowanie na to zezwoliło, a wszystko, na co oprogramowanie zezwala, prędzej czy później się wydarzy. Zaproponowała dodanie kodu wykrywającego błędy, który zabezpieczyłby przed wyborem P01 w trakcie lotu.⁷

Przegłosowano ją — usłyszała, że astronauci to wyszkoleni profesjonaliści, którzy nigdy nie popełniliby takiego błędu — i pozwolono jej jedynie dopisać uwagę do dokumentacji.⁷ A potem, podczas kolejnej misji, Apollo 8, Jim Lovell zrobił dokładnie to, co Lauren, wybierając P01 w trakcie lotu i wymazując dane nawigacyjne podczas pierwszej w dziejach ludzkości podróży wokół Księżyca.⁷ Po tym poprawkę wprowadzono. Lekcja, którą Hamilton wyciągnęła i powtarzała, jest sercem projektowania defensywnego: nie wolno uznać, że jakaś awaria „nie może się zdarzyć”, i projektować tak, jakby się nie zdarzyła. Astronauta, przełącznik radaru, operator o trzeciej nad ranem — system musi być odporny na człowieka w pętli, a nie chroniony przed odpowiedzialnością założeniem, że człowiek będzie nieomylny. Jej priorytetowe wyświetlacze ucieleśniały tę samą ideę z drugiej strony: utrzymuj człowieka poinformowanym i panującym nad sytuacją, tak by gdy komputer dokonuje triażu pod przeciążeniem, załoga rozumiała, co on robi, i mogła decydować.⁶

Higher Order Software, USL i „Development Before the Fact”

Apollo nauczyło Hamilton, skąd biorą się błędy, a ona resztę swojej kariery poświęciła na atakowanie ich u korzenia. Analizując błędy Apollo, zauważyła, że spora ich część żyła nie wewnątrz poszczególnych modułów, lecz w interfejsach między nimi — w miejscach, gdzie jeden fragment oprogramowania przekazywał dane drugiemu, a założenia nie do końca się zgadzały. W Higher Order Software (1976), a następnie w Hamilton Technologies (1986) zbudowała dorobek wokół eliminowania tych błędów przez konstrukcję, zamiast wyłapywania ich testami.¹⁶

Metodologia nazywa się „Development Before the Fact”. Nazwa jest tezą: zamiast budować system, a potem polować na defekty po fakcie, definiuje się go — przy użyciu formalnego systemu, Universal Systems Language (USL) — tak rygorystycznie, że całe klasy błędów, zwłaszcza błędy interfejsów i integracji, stają się strukturalnie niemożliwe. Model jest dowodliwie spójny, a z niego da się wygenerować poprawny kod, więc defekt zostaje uniemożliwiony na etapie projektu, zamiast wykrywany w czasie działania.⁶ To to samo przekonanie co w programie wykonawczym Apollo, dociśnięte o poziom głębiej: odzyskiwanie w czasie działania jest siatką bezpieczeństwa, ale prawdziwą wygraną jest system, który nigdy nie był w stanie popełnić błędu. Większość branży wciąż kręci odwrotną pętlę — wypuść, znajdź błędy, załataj — czyli dokładnie tę pętlę, o której Hamilton przez trzydzieści lat dowodziła, że jest postawiona na głowie, gdy poprawność naprawdę ma znaczenie.

Metoda

Spójrzmy łącznie na program wykonawczy Apollo, ukucie terminu „software engineering”, błąd Lauren i Development Before the Fact, a powracają te same zobowiązania. Metoda Hamilton jest mniej hasłem, a bardziej zbiorem trwałych nawyków.

Projektuj najpierw z myślą o przypadku awarii — drugiej szansy nie ma. Program wykonawczy Apollo nie był planistą z dokręconą obsługą przeciążenia; przetrwanie przeciążenia było projektem, bo zamarły komputer nad Księżycem oznaczał śmierć załogi.³⁴ Lekcja przenosi się daleko poza loty kosmiczne: wylicz, jak system zawodzi, zanim napiszesz ścieżkę, na której działa, i pozwól, by działająca ścieżka wyłoniła się ze struktury, która już przetrwa awarie. To bramka dowodów zastosowana do niezawodności — „działa w symulatorze” nie jest dowodem; „odrzuca obciążenie i wciąż prowadzi statek, gdy zalewa go radar” jest — ten sam standard łagodnej degradacji, który Werner Vogels uczynił dekady później założycielską przesłanką chmury.

Zakładaj, że człowiek zrobi rzecz niemożliwą. Błąd Lauren to ta reguła w miniaturze: jeśli system zezwala na niebezpieczną akcję, ktoś — dziecko, astronauta, zmęczony operator — w końcu ją podejmie, więc „nikt by tego nigdy nie zrobił” nie jest obroną.⁷ Trwały nawyk to pilnowanie granicy przed danymi wejściowymi, o których zapewniano cię, że nigdy nie nadejdą, bo awarie, które bolą najbardziej, to te, o których z góry uznałeś, że nie mogą się zdarzyć. To ten sam instynkt odporności na przeciwnika, który Radia Perlman wbudowała w trasowanie pozostające poprawnym nawet wtedy, gdy węzły kłamią.

Dokonuj triażu pod obciążeniem — odrzuć nieważne, chroń krytyczne. Gdy programowi wykonawczemu zabrakło pamięci, nie próbował obsłużyć każdego żądania; uruchamiał zadania o najwyższym priorytecie i zagładzał resztę, a potem restartował się czysto.³⁵ Dyscyplina polega na tym, by z góry zdecydować, co jest tą jedną rzeczą, która nigdy nie może się zatrzymać, i zbudować system tak, by pod presją poświęcił wszystko inne, byle utrzymać tę jedną rzecz w ruchu. System bez priorytetów to system, który zawodzi w najgorszym momencie, bo potraktował wyświetlacz załogi i śmieciowe zadanie radaru jak równych sobie.

Wbudowuj poprawność, nie wytestowuj jej. Development Before the Fact to odmowa pętli „wypuść, potem debuguj”: zdefiniuj system tak, by błąd nie dał się wyrazić, zamiast budować go i polować na błąd po fakcie.⁶ Lekcja brzmi: najtańszy, najbardziej godny zaufania defekt to ten, który projekt uczynił niemożliwym — to samo przekonanie, które Barbara Liskov przekuła w dyscyplinę typów i abstrakcję, a które Leslie Lamport przekuł w precyzyjne specyfikowanie poprawności przed napisaniem kodu. To jakość jest jedyną zmienną przekute w przepływ pracy: poprawność nie jest etapem na końcu, jest kształtem rzeczy od samego początku.

Nazwij dyscyplinę, byś mógł rozliczać ją ze standardu. Nazwanie tej pracy „software engineering” było aktem, który dał licencję na wszystko inne — specyfikacje, przeglądy, oczekiwanie rygoru.¹ Trwały nawyk to upieranie się, że praca ma nazwę i standard, bo nie da się wymagać kunsztu od czegoś, co organizacja uznaje za jednorazowe. To duch minimalnego godnego produktu: rzecz jest warta zrobienia jak należy, więc robi się ją jak należy, i mówi się głośno, że „jak należy” to jedyny dopuszczalny sposób.

Łańcuch wpływów

Kto ją ukształtował

Tradycja matematyki i czasu rzeczywistego na MIT. Hamilton wyrosła z matematyki, z SAGE — jednego z pierwszych dużych systemów oprogramowania czasu rzeczywistego, wrażliwych na awarie — oraz z modelowania pogody u Edwarda Lorenza, twórcy teorii chaosu.¹ Ten fundament jest widoczny: myślała o oprogramowaniu jako o systemie, który musi pozostać poprawny w warunkach, których nikt nie był w stanie w pełni przewidzieć, na długo zanim dotarła do Apollo. (Wpływ formujący)

Bezlitosna dyscyplina samych lotów kosmicznych. Misja Apollo była nauczycielem nie mniej niż jakakolwiek osoba. Dziedzina, w której pojedynczy błąd kosztuje życie załogi, w której nie ma łatki ani drugiej szansy, wymusza sposób pracy — broń przypadku awarii, odzyskuj w czasie działania, uniemożliwiaj błąd na etapie projektu — którego zwyczajne oprogramowanie nigdy nie wymaga.² Ograniczenie ukształtowało filozofię. (Wpływ bezpośredni)

Kultura inżynierii systemów programu Apollo. Praca wewnątrz programu, w którym jej oprogramowanie musiało integrować się ze sprzętem, centrum sterowania lotem i ludzkimi procedurami, pchnęła ją ku postrzeganiu oprogramowania jako jednej z kilku dyscyplin inżynierskich — co jest dokładnie tym ujęciem, które stoi za jej ukuciem terminu „software engineering” jako części „całościowego procesu inżynierii systemów”.¹ (Wpływ formujący)

Kogo ona ukształtowała

Samą dyscyplinę inżynierii oprogramowania. Nazywając tę dziedzinę i argumentując za jej rygorem z wnętrza najwyższej stawki projektu programistycznego swojej epoki, Hamilton pomogła przemienić programowanie ze sprawy drugorzędnej w dyscyplinę inżynierską ze specyfikacjami, przeglądami i oczekiwaniem poprawności.¹²

Każdy odporny na awarie system czasu rzeczywistego. Planowanie priorytetowe, odrzucanie obciążenia, restart do znanego dobrego stanu oraz wyświetlacze z człowiekiem w pętli — wzorce, których program wykonawczy Apollo użył, by przetrwać alarm 1202 — są dziś standardowym słownikiem systemów odpornych, od sterowania lotem po nadzorców utrzymujących usługi sieciowe przy życiu pod przeciążeniem.³⁶

Formalne metody poprawne z konstrukcji. Development Before the Fact oraz Universal Systems Language są częścią linii, która dowodzi, że poprawność powinna być projektowana i dowodliwa, a nie wytestowywana po fakcie — argument, który przewija się przez metody formalne i rozwój sterowany modelem aż po dziś.⁶

Nić przewodnia

Hamilton jest punktem początkowym linii niezawodności w tej serii — miejscem, gdzie „projektuj z myślą o przypadku awarii” przestało być preferencją, a stało się rzeczą nienegocjowalną, bo zależały od tego ludzkie życia, dekady przed tym, nim reszta dziedziny nadgoniła. Werner Vogels zbudował chmurę na zasadzie „wszystko zawodzi przez cały czas” i projektował pod łagodną degradację w planetarnej skali; Hamilton projektowała pod łagodną degradację na komputerze wielkości teczki, z załogą na pokładzie, i udowodniła, że doktryna działa, gdy naprawdę nie ma drugiej szansy.³ Radia Perlman zbudowała sieci, które same się leczą i pozostają poprawne nawet wtedy, gdy węzły kłamią; program wykonawczy Hamilton leczył sam siebie w czasie rzeczywistym nad Księżycem, restartując się czysto i odrzucając kłamstwa, którymi karmił go zepsuty radar.⁴ A Leslie Lamport uczynił z poprawności coś, co definiuje się precyzyjnie i dowodzi przed budową — czyli dokładnie to, do czego sięga Development Before the Fact, pokolenie wcześniej i wymierzone w ten sam cel.⁶ Tam gdzie Vogels mówi wszystko zawodzi, więc bądź dostępny mimo to, a Perlman mówi buduj tak, by samo się leczyło, Hamilton powiedziała to pierwsza i najdobitniej: nie ma drugiej szansy, więc projektuj z myślą o awarii, zanim się wydarzy, odzyskuj po niej, gdy się wydarzy, i buduj system tak, by najgorsze błędy w ogóle nie były możliwe. (Pomost serii)

Co z tego biorę dla siebie

Lekcja, którą zachowuję od Hamilton, to budować tak, jakby drugiej szansy nie było, nawet gdy oczywiście istnieje. Niemal wszystko, co wypuszczam, żyje w wygodzie, której ona nie miała: jeśli się zepsuje, wysyłam poprawkę. Ta siatka bezpieczeństwa jest realna i po cichu obniża poprzeczkę — pozwala mi wypuścić ścieżkę optymistyczną i wmówić sobie, że przypadkiem awarii zajmę się później, bo „później” istnieje. Apollo jest reprymendą. Gdy naprawdę nie możesz tego załatać, odkrywasz, że „zajmę się awarią później” nigdy nie było inżynierią; przypadek awarii jest inżynierią, a działająca ścieżka to tylko to, co zostaje, gdy system już przetrwa rozbicie. Więc kiedy buduję coś teraz — zadanie, które można zalać, API, które można wywołać błędnie, ścieżkę, którą można obrać w niewłaściwym momencie — staram się zapytać „co jest tutaj przełącznikiem radaru w niewłaściwym położeniu i czy to coś to odrzuci i będzie wciąż prowadzić statek?”, zanim zapytam, czy ścieżka optymistyczna działa. System, który przetrwa tylko poprawne dane wejściowe, to system, którego nie skończyłem.

Druga lekcja brzmi: najbardziej godnym zaufania błędem jest ten, który projekt uczynił niemożliwym. Błąd Lauren zostaje ze mną, bo Hamilton miała rację i przegłosowano ją argumentem „nikt by tego nigdy nie zrobił” — a wszechświat natychmiast to zrobił, podczas kolejnej misji. Mój instynkt to wyłapywać błędy w czasie działania, owinąć niebezpieczne wywołanie w zabezpieczenie i iść dalej. Głębszy ruch Hamilton, ten, na który poświęciła trzydzieści lat, to zaprojektować system tak, by niebezpiecznego wywołania nie dało się wykonać — uczynić zły stan niereprezentowalnym, a nie jedynie wykrywanym. Odzyskiwanie w czasie działania jest siatką; wbudowanie poprawności jest podłogą, na której stoisz, byś nie potrzebował siatki. Nie zawsze potrafię sięgnąć tej poprzeczki, lecz przeformułowała ona cel: pytanie brzmi nie tylko „czy to wyłapię, gdy pójdzie nie tak?”, ale „czy mogę nadać temu kształt, by w ogóle nie mogło pójść nie tak?” — a to drugie pytanie, gdy potrafię na nie odpowiedzieć, jest zawsze lepsze.

FAQ

Czy Margaret Hamilton ukuła termin „software engineering”?

Margaret Hamilton jest powszechnie uznawana za osobę, która ukuła — lub przynajmniej spopularyzowała — termin „software engineering”, którego zaczęła używać, kierując pracami nad oprogramowaniem lotu Apollo w MIT Instrumentation Laboratory w latach 60.¹² Używała go świadomie, by przekonywać, że pisanie oprogramowania zasługuje na tę samą rangę i rygor co inżynieria sprzętu i inne dyscypliny inżynierskie, wyjaśniając, że chciała „odróżnić to od inżynierii sprzętu i innych rodzajów inżynierii, a zarazem traktować każdy z tych rodzajów inżynierii jako część całościowego procesu inżynierii systemów”.¹ W tamtym czasie sam pomysł, że oprogramowanie mogłoby być „inżynierią”, spotkał się z pewnym rozbawieniem; dziś termin jest tak standardowy, że niewidzialny — co jest miarą tego, jak gruntownie argument został wygrany.¹

Czym były alarmy 1202 i 1201 podczas Apollo 11?

Były to alarmy programowe zgłoszone przez program wykonawczy komputera naprowadzania Apollo podczas ostatnich minut księżycowego zejścia. Źle ustawiony przełącznik radaru spotkaniowego sprawił, że radar zaczął podkradać cykle procesora i skłonił program wykonawczy do wielokrotnego planowania zadań przetwarzania danych, które nie powinny były działać, co pochłonęło całą wolną pamięć.³⁴ Gdy nie był dostępny żaden „core set” pamięci, program wykonawczy zgłaszał alarm 1202; gdy niedostępny był żaden „VAC area”, zgłaszał 1201.⁴ Alarmy nie były awariami — były to zgłoszenia programu wykonawczego, że poproszono go o więcej, niż był w stanie wykonać, i że dokonuje triażu. Ponieważ oprogramowanie korzystało z planowania priorytetowego i ochrony przez restart, odrzuciło zbędne zadania radaru, zrestartowało się do znanego dobrego stanu, utrzymało krytyczne dla lądowania naprowadzanie oraz wyświetlacz załogi w działaniu, i lądowanie się powiodło.³⁵

Co Margaret Hamilton zrobiła dla programu Apollo?

Hamilton dołączyła do MIT Instrumentation Laboratory w 1965 roku i awansowała na kierowniczkę Software Engineering Division odpowiedzialnej za pokładowe oprogramowanie lotu działające na komputerze naprowadzania Apollo, zarówno w module dowodzenia, jak i w module księżycowym.¹ Jej zespół zaprojektował program wykonawczy czasu rzeczywistego z asynchronicznym planowaniem priorytetowym, ochroną przez restart, wykrywaniem i odzyskiwaniem po błędach oraz priorytetowymi wyświetlaczami, które utrzymywały astronautów poinformowanych i panujących nad sytuacją — architekturę, która pozwoliła komputerowi Apollo 11 przetrwać alarm 1202 i dokończyć lądowanie.³⁶ Uzasadnienie jej Prezydenckiego Medalu Wolności przypisuje jej wkład w „koncepcje oprogramowania asynchronicznego, planowania priorytetowego i priorytetowych wyświetlaczy oraz zdolności decyzyjnej z człowiekiem w pętli, które położyły fundament pod nowoczesne, ultraniezawodne projektowanie i inżynierię oprogramowania”.⁶

Czym jest „Development Before the Fact”?

„Development Before the Fact” to metodologia systemowa, którą Hamilton rozwinęła w Higher Order Software i Hamilton Technologies po Apollo, zbudowana wokół jej Universal Systems Language (USL).¹⁶ Jej teza brzmi, że zamiast budować system, a potem polować na defekty „po fakcie” przez testowanie, definiuje się system tak rygorystycznie i formalnie, że całe klasy błędów — zwłaszcza błędy interfejsów i integracji, które, jak odkryła, dominowały wśród defektów Apollo — są z konstrukcji strukturalnie niemożliwe.⁶ Model jest dowodliwie spójny, a z niego da się wygenerować poprawny kod, więc defekt zostaje uniemożliwiony na etapie projektu, zamiast wykrywany w czasie działania. To wyraz jej przekonania z Apollo w języku metod formalnych: najbardziej godnym zaufania błędem jest ten, którego system nigdy nie był w stanie popełnić.

Źródła