Engineering-Philosophie: Margaret Hamilton

Die wichtigsten Erkenntnisse

• Sie prägte den Begriff „Software Engineering”, um der Disziplin ihre Legitimität zu erkämpfen. Während sie am MIT Instrumentation Laboratory die Entwicklung der Apollo-Flugsoftware leitete, begann Margaret Hamilton, die Arbeit bewusst „Software Engineering” zu nennen – mit dem Ziel zu zeigen, dass das Schreiben des Codes, der Menschen zum Mond brachte, dieselbe Strenge und denselben Respekt verdiente wie die Hardware- und Systemtechnik, und das zu einer Zeit, als Software als bloße Nebensache galt.¹²
• Ihre Software rettete die Landung von Apollo 11, als der Leitrechner die Alarme 1202 und 1201 auslöste. Während des finalen Abstiegs speiste ein falsch gestellter Schalter des Rendezvous-Radars dem Apollo Guidance Computer Arbeit zu, die er niemals hätte erledigen sollen, und der Executive hatte keinen Speicher mehr, um sie einzuplanen – die berühmten Alarme 1202 („no core sets”) und 1201 („no VAC areas”). Weil Hamiltons Team die Software mit prioritätsbasierter Ablaufplanung und Neustartschutz gebaut hatte, warf der Computer die niedrigpriorisierten Radaraufgaben ab, hielt die landungskritische Steuerung am Laufen, und die Landung gelang.³⁴⁵
• Ihr prägendes Bekenntnis ist defensives Design: für den Fehlerfall konstruieren, weil es keine zweite Chance gibt. „Es gab keine zweite Chance. Das wussten wir”, sagte sie über Apollo.² Fehlererkennung, Fehlerbehebung, asynchrone prioritätsbasierte Ablaufplanung und Anzeigen mit dem Menschen in der Schleife waren keine Funktionen, die nachträglich auf einen funktionierenden Idealfall aufgesetzt wurden – sie waren der Kern des Entwurfs, der Grund, warum die Software anmutig degradierte, statt abzustürzen.⁶
• Sie baute Korrektheit von Anfang an ein – „Development Before the Fact”. Nach Apollo gründete sie Higher Order Software (1976) und Hamilton Technologies (1986), entwickelte die Universal Systems Language (USL) und eine Methodik, um Systeme so zu entwerfen, dass ganze Fehlerklassen durch ihre Konstruktion unmöglich werden, statt durch Tests aufgespürt zu werden. Sie erhielt den NASA Exceptional Space Act Award (2003) und die Presidential Medal of Freedom (2016).¹⁶

Das Prinzip

„Es gab keine zweite Chance. Das wussten wir. Wir nahmen unsere Arbeit ernst, viele von uns begannen diese Reise noch in ihren Zwanzigern.” – Margaret Hamilton über die Apollo-Flugsoftware²

Die meiste Ingenieursarbeit optimiert für den Fall, dass alles funktioniert. Man baut den Idealfall, behandelt ein paar Fehler, die man sich vorstellen kann, und liefert aus – und wenn etwas in der Produktion bricht, flickt man es und deployt erneut. Diese Schleife ist der Komfort, in dem nahezu alle Software lebt: Der Fehler ist behebbar, weil es immer eine nächste Chance gibt. Hamiltons Arbeit setzte bei der gegenteiligen Prämisse an. Die Software, die sie verantwortete, sollte drei Menschen eine Viertelmillion Meilen von der Erde wegfliegen und zwei davon auf dem Mond landen lassen, und es gab keinen Patch, kein erneutes Deployment, keine nächste Chance. Sie musste beim ersten Mal funktionieren, unter Bedingungen, die niemand vollständig proben konnte, auf einem Computer mit weniger Speicher als eine Grußkarte, die eine Melodie abspielt.² Wenn ein einziger unbehandelter Fehler die Besatzung kostet, ist „für den Fehlerfall konstruieren” kein guter Rat mehr, sondern die gesamte Aufgabe.

Das daraus folgende Prinzip lautet: defensives Design als Kern des Entwurfs, nicht als Aufräumarbeit. Wenn die Software das Unerwartete überleben muss, dann können das Erkennen von Fehlern, das Beheben von Fehlern und das anmutige Degradieren keine Funktionen sein, die man hinzufügt, nachdem der funktionierende Pfad fertig ist – sie müssen das Gerüst sein, an dem der funktionierende Pfad hängt. Hamiltons Team baute die Apollo-Software so, dass der Computer bemerken konnte, dass von ihm mehr verlangt wurde, als er leisten konnte, die Arbeit aussortieren konnte, die keine Rolle spielte, sauber in einen bekannten, funktionierenden Zustand neu starten konnte und genau die eine Sache weiter erledigte, deren Ausfall die Besatzung getötet hätte. Das System wurde nicht gebaut, um jeden Fehler zu vermeiden – auf einer so kleinen Maschine, gegen eine so unbarmherzige Mission ist das unmöglich. Es wurde so gebaut, dass der Fehler, wenn er kam, überlebbar war.³⁶

Es gibt eine zweite Hälfte des Prinzips, und sie ist diejenige, die die erste Hälfte real macht: Korrektheit von Anfang an einbauen, statt Fehler am Ende herauszutesten. Einen Fehler zur Laufzeit zu erkennen und zu beheben ist die letzte Verteidigungslinie; die tiefere Disziplin besteht darin, das System so zu entwerfen, dass ganze Fehlerkategorien gar nicht erst entstehen können. Hamilton verbrachte die zweite Hälfte ihrer Laufbahn damit, genau das zu formalisieren – eine Methodik, die sie „Development Before the Fact” nannte, und eine Sprache, die geschaffen wurde, um Schnittstellenfehler strukturell unmöglich zu machen.⁶ Die beiden Hälften sind ein und dieselbe Idee aus zwei Entfernungen betrachtet: Wenn es keine zweite Chance gibt, verteidigt man zur Laufzeit und man macht den Fehler zur Entwurfszeit undarstellbar, denn der einzige Fehler, dem man vollständig trauen kann, ist der, den das System nie machen konnte.

Kontext

Margaret Hamilton wurde am 17. August 1936 als Margaret Heafield in Paoli, Indiana, geboren.¹ Sie studierte Mathematik am Earlham College und erwarb 1958 ihren Abschluss mit einem Nebenfach in Philosophie – eine Kombination, die sich später darin zeigt, wie sie über Systeme ebenso wie über Code nachdachte.¹ Sie kam nicht über eine informatische Laufbahn zu Apollo, denn Ende der 1950er Jahre gab es so etwas nicht; sie kam über die Mathematik und über die Arbeit selbst.

Ihre erste Programmierarbeit war von Anfang an praxisnah und mit hohem Einsatz verbunden. 1959 begann sie in der Meteorologie-Abteilung des MIT bei Edward Lorenz zu arbeiten – dem Begründer der Chaostheorie – und schrieb Software zur Wettervorhersage auf der LGP-30 und der PDP-1.¹ Von etwa 1961 bis 1963 arbeitete sie am SAGE-Projekt am MIT Lincoln Laboratory und schrieb Software für den Computer AN/FSQ-7, den die U.S. Air Force zur Erkennung anfliegender Flugzeuge einsetzte.¹ SAGE war eines der ersten großen, echtzeitfähigen und fehlerempfindlichen Softwaresysteme, die je gebaut wurden, und der Ruf, den sie sich dort erwarb – den schwierigsten, fehleranfälligsten Code zu übernehmen – ist es, was sie zu Apollo brachte.

1965 trat sie dem MIT Instrumentation Laboratory bei (später Draper Lab), das den Auftrag hatte, die bordeigene Flugsoftware für das Apollo-Programm der NASA zu bauen. Sie stieg auf, bis sie die Software Engineering Division leitete, und führte das Team, das für die bordeigene Flugsoftware verantwortlich war, die auf dem Apollo Guidance Computer sowohl im Kommandomodul als auch in der Mondlandefähre lief.¹ Hier, mitten in dieser Arbeit, begann sie den Begriff „Software Engineering” zu verwenden – nicht als Schlagwort, sondern als Argument. Wie sie es formulierte, verwendete sie den Begriff, „um es von der Hardware und anderen Arten der Ingenieurskunst zu unterscheiden und dennoch jede Art der Ingenieurskunst als Teil des gesamten systemtechnischen Prozesses zu behandeln.”¹ Software, beharrte sie, sei eine Disziplin, die einen Namen und die damit einhergehende Strenge verdiene. Nach Apollo gründete sie 1976 Higher Order Software und 1986 Hamilton Technologies, wo sie die Universal Systems Language und die Methodik „Development Before the Fact” entwickelte.¹⁶

Die Arbeit

Der 1202-Alarm bei Apollo 11: prioritätsbasierte Ablaufplanung und Neustartschutz

Hier setzt man an, denn dies ist das Prinzip, das unter dem denkbar größten Druck zum Mechanismus wird. Der Apollo Guidance Computer war eine winzige Maschine – ein paar Dutzend Kilobyte Speicher, kein Betriebssystem im modernen Sinne – auf der ein Echtzeit-Executive lief, den Hamiltons Team entworfen hatte. Um eine Aufgabe auszuführen, musste der Executive freien Speicher finden: ein „core set” (einen kleinen Block für den Zustand der Aufgabe) und, für Aufgaben mit Fließkommarechnung, einen „VAC area”.⁴ Wurde eine Aufgabe eingeplant und kein core set war frei, verzweigte der Executive in seine Alarmroutine und löste Alarm 1202 aus; war kein VAC area frei, löste er 1201 aus.⁴ Das waren keine Absturzcodes. Es war der Executive, der meldete, dass von ihm mehr verlangt wurde, als er bewältigen konnte – und der dann etwas dagegen unternahm.

Während der letzten Minuten des Abstiegs von Apollo 11 geschah genau das. Die Astronauten-Checkliste ließ die Besatzung den Schalter des Rendezvous-Radars in der falschen Position belassen, wodurch das Radar Prozessorzyklen stahl und den Executive wiederholt dazu brachte, Datenverarbeitungsaufgaben einzuplanen, die niemals hätten laufen dürfen.³⁴ Die überflüssige Arbeit verbrauchte den gesamten freien Speicher, und der Alarm 1202 wurde ausgelöst – dann erneut, und auch der Alarm 1201, viermal in den Sekunden vor dem Aufsetzen. Ein naiver Computer, dem man auftrüge, alles zu tun, hätte versucht, alles zu tun, wäre bei der einen Aufgabe, die zählte, ins Hintertreffen geraten und eingefroren. Hamiltons Computer nicht.

Zwei Entwurfsentscheidungen retteten die Landung. Die erste war die prioritätsbasierte Ablaufplanung: Der Executive führte Aufgaben nach Priorität aus und konnte die niedrigstpriorisierte Arbeit abwerfen, sodass die landungskritische Steuerung und das Display der Besatzung (DSKY) stets liefen, während die nutzlosen Radaraufgaben ausgehungert wurden.³⁵ Die zweite war der Neustartschutz: Jeder Alarm löste einen Software-Neustart aus, der die überlastete Warteschlange leerte und in einen bekannten, funktionierenden Zustand neu hochfuhr und dabei „das Wichtige neu startete, etwa die Steuerung des Abstiegstriebwerks und den Betrieb des DSKY”, aber nicht die fälschlich eingeplanten Radaraufgaben.⁴⁵ Der Computer warf das Rauschen praktisch weg, flog das Raumfahrzeug weiter und teilte der Besatzung mit, dass er die Lage im Griff hatte – weshalb Mission Control bei einem Alarm „go” geben konnte, der bei einem schwächeren Entwurf einen Abbruch bedeutet hätte.

Warum das als Ingenieurskunst zählt: Der Alarm war nicht der Fehler – er war die bestimmungsgemäß funktionierende Fehlerbehandlung. Das Team hatte den Executive so gebaut, dass er Überlast erwartete, unter ihr triagierte und sich von ihr erholte, und es hatte diese Erholung so gründlich getestet, dass die Controller ihr unter dem größten Druck vertrauten, unter dem je Software stand. Das ist die ganze Doktrin in einem Moment: Der Fehler wurde vorausgesetzt, der Fehlerfall war der Kern des Entwurfs, und das System degradierte zu „tue nur das, was die Besatzung am Leben hält”, statt umzukippen. Derselbe Instinkt lebt heute in jeder Prioritätswarteschlange weiter, die Last abwirft, in jedem Supervisor, der einen abgestürzten Worker in einen sauberen Zustand neu startet, in jedem System, das gebaut ist, um sein eigenes Überfordertwerden zu überstehen.

Die Prägung von „Software Engineering” und der Kampf um Legitimität

Die Geschichte von 1202 ist berühmt; die Namensgebung ist wohl folgenreicher. In den 1960er Jahren galt Software weithin als das weiche, unseriöse Geschwister der „echten” Ingenieurskunst – etwas, das man sich ausdachte, nachdem die Hardware entworfen war, keine Disziplin mit eigener Strenge. Hamilton lehnte diese Einordnung ab. Innerhalb von Apollo begann sie die Arbeit bewusst „Software Engineering” zu nennen, und sie sagte unverblümt, warum: um es „von der Hardware und anderen Arten der Ingenieurskunst zu unterscheiden und dennoch jede Art der Ingenieurskunst als Teil des gesamten systemtechnischen Prozesses zu behandeln.”¹ Es ging nicht um Vokabular. Es ging um Ansehen. Wenn der Code, der die Mission flog, Ingenieurskunst war, dann verdiente er die Disziplin der Ingenieurskunst: Spezifikationen, Reviews, Tests, Nachvollziehbarkeit und die Erwartung, korrekt gemacht zu werden und nicht bloß zum Laufen gebracht.

Sie hat erzählt, dass der Begriff zunächst mit Belustigung aufgenommen wurde – die Vorstellung, Software könnte „Engineering” sein, kam den Leuten weithergeholt vor.¹ Doch die Legitimität, für die sie kämpfte, war tragend. Man kann von einem Team nicht verlangen, für den Fehlerfall zu konstruieren, Fehlerbehebung in das Fundament eines Systems einzubauen und Korrektheit als nicht verhandelbar zu behandeln, wenn die Arbeit als beiläufiges Skripten gilt, das jemand später aufräumen wird. Die Disziplin zu benennen war die Voraussetzung dafür, sie an einem Maßstab zu messen. Bis zum Ende des Jahrzehnts hatte der Begriff das MIT verlassen und war zum Namen eines Fachgebiets geworden; heute ist „Software Engineering” so alltäglich, dass es unsichtbar ist, was das sicherste Zeichen dafür ist, dass das Argument gewonnen wurde.¹²

Defensives Design: der „Lauren-Bug” und das Konstruieren gegen den Menschen

Wenn man das klarste Fenster in Hamiltons Denken sucht, ist es der „Lauren-Bug”. Ihre kleine Tochter Lauren kam manchmal ins Labor und spielte Astronautin am Simulator des Kommandomoduls, und eines Tages brachte sie ihn zum Absturz – indem sie P01, das Vorstartprogramm, auswählte, während sich das simulierte Raumfahrzeug bereits mitten im Flug zum Mond befand.⁷ Das Laden der Vorstart-Initialisierung mitten im Kurs löschte die Navigationsdaten und ließ den Computer orientierungslos zurück. Hamiltons Instinkt war nicht „kein Astronaut würde das je tun”. Er war: Wenn der Simulator es einem Kind erlaubte, dann erlaubte es die Software, und alles, was die Software erlaubt, wird irgendwann geschehen. Sie schlug vor, Fehlererkennungscode hinzuzufügen, der die Auswahl von P01 im Flug verhinderte.⁷

Sie wurde überstimmt – mit dem Argument, Astronauten seien geschulte Profis, die einen solchen Fehler niemals machen würden – und durfte nur einen Hinweis in die Dokumentation aufnehmen.⁷ Dann, bei der allernächsten Mission, Apollo 8, tat Jim Lovell genau das, was Lauren getan hatte: Er wählte P01 mitten im Flug aus und löschte die Navigationsdaten auf der ersten Reise der Menschheit um den Mond.⁷ Danach wurde die Korrektur eingebaut. Die Lehre, die Hamilton daraus zog und immer wieder anführte, ist das Herzstück des defensiven Designs: Man kann nicht entscheiden, ein Fehler „kann nicht passieren”, und so konstruieren, als würde er nicht passieren. Der Astronaut, der Radarschalter, die Bedienperson um drei Uhr morgens – das System muss robust gegen den Menschen in der Schleife sein, nicht durch die Annahme vor Schuld geschützt, der Mensch werde perfekt sein. Ihre Prioritäts-Anzeigen verkörperten dieselbe Idee aus der anderen Richtung: den Menschen informiert und in Kontrolle halten, damit die Besatzung, wenn der Computer unter Überlast triagierte, verstand, was er tat, und entscheiden konnte.⁶

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

Apollo lehrte Hamilton, woher Fehler kommen, und sie verbrachte den Rest ihrer Laufbahn damit, sie an der Wurzel anzugehen. Beim Studium der Apollo-Fehler beobachtete sie, dass ein großer Teil von ihnen nicht innerhalb einzelner Module lebte, sondern in den Schnittstellen zwischen ihnen – an den Stellen, an denen ein Stück Software Daten an ein anderes übergab und die Annahmen nicht ganz zusammenpassten. Bei Higher Order Software (1976) und dann Hamilton Technologies (1986) baute sie ein Werk auf, das diese Fehler durch Konstruktion eliminierte, statt sie durch Tests aufzuspüren.¹⁶

Die Methodik heißt „Development Before the Fact”. Der Name ist die These: Statt ein System zu bauen und dann im Nachhinein nach Defekten zu jagen, definiert man es – mithilfe eines formalen Systems, der Universal Systems Language (USL) – so streng, dass ganze Fehlerklassen, insbesondere Schnittstellen- und Integrationsfehler, strukturell unmöglich sind. Das Modell ist nachweisbar konsistent, und aus ihm lässt sich korrekter Code erzeugen, sodass der Defekt zur Entwurfszeit verhindert statt zur Laufzeit entdeckt wird.⁶ Es ist dieselbe Überzeugung wie beim Apollo-Executive, nur eine Ebene tiefer geführt: Die Laufzeiterholung ist das Sicherheitsnetz, doch der eigentliche Gewinn ist ein System, das den Fehler von vornherein nie machen konnte. Der Großteil der Branche durchläuft noch immer die umgekehrte Schleife – ausliefern, Bugs finden, flicken – genau die Schleife, von der Hamilton dreißig Jahre lang argumentierte, sie sei verkehrt herum, wenn Korrektheit wirklich zählt.

Die Methode

Liest man quer über den Apollo-Executive, die Prägung von „Software Engineering”, den Lauren-Bug und Development Before the Fact, kehren dieselben Bekenntnisse wieder. Hamiltons Methode ist weniger ein Slogan als ein Satz dauerhafter Gewohnheiten.

Zuerst für den Fehlerfall konstruieren – es gibt keine zweite Chance. Der Apollo-Executive war kein Planer mit aufgesetzter Überlastbehandlung; das Überleben der Überlast war der Entwurf, denn ein eingefrorener Computer über dem Mond tötete die Besatzung.³⁴ Die Lehre überträgt sich weit über die Raumfahrt hinaus: Zählen Sie auf, wie das System versagt, bevor Sie den Pfad schreiben, auf dem es funktioniert, und lassen Sie den funktionierenden Pfad aus einer Struktur hervorgehen, die die Fehler bereits übersteht. Es ist die Beweisschwelle, angewandt auf Zuverlässigkeit – „es funktioniert im Simulator” ist kein Beweis; „es wirft Last ab und fliegt weiter, wenn das Radar es überflutet” ist einer – derselbe Maßstab für anmutiges Degradieren, den Werner Vogels Jahrzehnte später zur Gründungsprämisse der Cloud machte.

Gehen Sie davon aus, dass der Mensch das Unmögliche tun wird. Der Lauren-Bug ist die Regel im Kleinen: Wenn das System eine gefährliche Handlung erlaubt, wird sie irgendwann jemand vornehmen – ein Kind, ein Astronaut, eine erschöpfte Bedienperson – und damit ist „das würde niemand je tun” keine Verteidigung.⁷ Die dauerhafte Gewohnheit besteht darin, die Grenze gegen die Eingabe zu schützen, von der man Ihnen versicherte, sie könne niemals eintreffen, denn die Fehler, die am meisten schaden, sind jene, von denen man im Voraus entschied, sie könnten nicht passieren. Es ist derselbe Instinkt der Robustheit gegen den Gegenspieler, den Radia Perlman in das Routing einbaute, das selbst dann korrekt bleibt, wenn Knoten lügen.

Triagieren Sie unter Last – werfen Sie das Unwichtige ab, schützen Sie das Kritische. Als dem Executive der Speicher ausging, versuchte er nicht, jede Anfrage zu bedienen; er führte die höchstpriorisierten Aufgaben aus und hungerte den Rest aus, dann startete er sauber neu.³⁵ Die Disziplin besteht darin, im Voraus zu entscheiden, was die eine Sache ist, die niemals aufhören darf, und das System so zu bauen, dass es unter Druck alles andere opfert, um diese eine Sache am Laufen zu halten. Ein System ohne Priorität ist ein System, das im schlimmsten Moment versagt, weil es das Display der Besatzung und die nutzlose Radaraufgabe als gleichrangig behandelte.

Bauen Sie Korrektheit ein, testen Sie sie nicht ein. Development Before the Fact ist die Weigerung, die Schleife aus Ausliefern-dann-Debuggen zu durchlaufen: das System so definieren, dass der Fehler nicht ausgedrückt werden kann, statt es zu bauen und den Fehler hinterher zu jagen.⁶ Die Lehre ist, dass der günstigste, vertrauenswürdigste Defekt derjenige ist, den der Entwurf unmöglich gemacht hat – dieselbe Überzeugung, die Barbara Liskov in Typdisziplin und Abstraktion verwandelte und die Leslie Lamport dazu brachte, Korrektheit präzise zu spezifizieren, bevor er den Code schrieb. Es ist Qualität ist die einzige Variable, zu einem Arbeitsablauf gemacht: Korrektheit ist keine Phase am Ende, sie ist die Gestalt der Sache von Anfang an.

Benennen Sie die Disziplin, damit Sie sie an einem Maßstab messen können. Die Arbeit „Software Engineering” zu nennen war der Akt, der alles andere lizenzierte – Spezifikationen, Reviews, die Erwartung von Strenge.¹ Die dauerhafte Gewohnheit besteht darin, darauf zu bestehen, dass die Arbeit einen Namen und einen Maßstab hat, denn man kann keine Handwerkskunst von etwas verlangen, das die Organisation als entbehrlich betrachtet. Es ist der Geist des minimal lohnenswerten Produkts: Die Sache ist es wert, ordentlich gemacht zu werden, also macht man sie ordentlich, und man legt laut dar, dass ordentlich der einzig akzeptable Weg ist.

Einfluss-Kette

Wer sie prägte

Die Tradition der Mathematik und Echtzeit am MIT. Hamilton wuchs über die Mathematik und über SAGE heran – eines der ersten großen, echtzeitfähigen, fehlerempfindlichen Softwaresysteme – und über die Wettermodellierung bei Edward Lorenz, dem Begründer der Chaostheorie.¹ Diese Grundlage zeigt sich: Sie dachte über Software als ein System nach, das unter Bedingungen korrekt bleiben musste, die niemand vollständig vorhersagen konnte, lange bevor sie zu Apollo kam. (Prägender Einfluss)

Die unbarmherzige Disziplin der Raumfahrt selbst. Die Apollo-Mission war ebenso sehr die Lehrmeisterin wie irgendein Mensch. Ein Bereich, in dem ein einziger Fehler die Besatzung kostet, in dem es keinen Patch und keine zweite Chance gibt, erzwingt eine Arbeitsweise – den Fehlerfall verteidigen, zur Laufzeit beheben, den Fehler zur Entwurfszeit verhindern – die gewöhnliche Software nie verlangt.² Die Einschränkung formte die Philosophie. (Direkter Einfluss)

Die systemtechnische Kultur des Apollo-Programms. Die Arbeit innerhalb eines Programms, in dem ihre Software sich mit Hardware, Mission Control und menschlichen Abläufen integrieren musste, drängte sie dazu, Software als eine Ingenieursdisziplin unter mehreren zu sehen – was genau die Einordnung hinter ihrer Prägung von „Software Engineering” als Teil „des gesamten systemtechnischen Prozesses” ist.¹ (Prägender Einfluss)

Wen sie prägte

Die Disziplin des Software Engineering selbst. Indem sie das Fachgebiet benannte und vom Inneren des Software-Projekts mit dem höchsten Einsatz seiner Ära aus für dessen Strenge argumentierte, half Hamilton dabei, das Programmieren von einer Nebensache in eine Ingenieursdisziplin mit Spezifikationen, Reviews und der Erwartung von Korrektheit zu verwandeln.¹²

Jedes fehlertolerante Echtzeitsystem. Prioritätsbasierte Ablaufplanung, Lastabwurf, Neustart in einen bekannten, funktionierenden Zustand und Anzeigen mit dem Menschen in der Schleife – die Muster, mit denen der Apollo-Executive den Alarm 1202 überstand – sind heute das Standardvokabular widerstandsfähiger Systeme, von der Flugsteuerung bis zu den Supervisorn, die Webdienste unter Überlast am Leben halten.³⁶

Formale, durch Konstruktion korrekte Methoden. Development Before the Fact und die Universal Systems Language gehören zur Linie, die dafür argumentiert, dass Korrektheit eingebaut und beweisbar sein sollte, nicht im Nachhinein hineingetestet – ein Argument, das sich bis heute durch formale Methoden und modellgetriebene Entwicklung zieht.⁶

Der rote Faden

Hamilton ist der Ursprungspunkt der Zuverlässigkeitslinie in dieser Reihe – der Ort, an dem „für den Fehlerfall konstruieren” aufhörte, eine Vorliebe zu sein, und nicht verhandelbar wurde, weil Leben davon abhingen, Jahrzehnte bevor der Rest des Fachgebiets aufholte. Werner Vogels baute die Cloud auf „alles versagt ständig” und entwarf für anmutiges Degradieren in planetarem Maßstab; Hamilton entwarf für anmutiges Degradieren auf einem Computer von der Größe einer Aktentasche, mit einer Besatzung obendrauf, und bewies, dass die Doktrin funktioniert, wenn es wirklich keine zweite Chance gibt.³ Radia Perlman baute Netzwerke, die sich selbst heilen und korrekt bleiben, selbst wenn Knoten lügen; Hamiltons Executive heilte sich selbst in Echtzeit über dem Mond, startete sauber neu und warf die Lügen ab, die das defekte Radar ihm einspeiste.⁴ Und Leslie Lamport machte Korrektheit zu etwas, das man präzise definiert und beweist, bevor man baut – genau das, wonach Development Before the Fact greift, eine Generation früher und auf dasselbe Ziel gerichtet.⁶ Wo Vogels sagt alles versagt, also bleibe trotzdem verfügbar und Perlman sagt baue es so, dass es sich selbst heilt, sagte Hamilton es zuerst und am entschiedensten: Es gibt keine zweite Chance, also konstruiere für den Fehler, bevor er geschieht, behebe ihn, wenn er eintritt, und baue das System so, dass die schlimmsten Fehler von vornherein nie möglich waren. (Reihen-Brücke)

Was ich daraus mitnehme

Die Lehre, die ich von Hamilton behalte, ist, so zu bauen, als ob es keine zweite Chance gäbe, selbst wenn es offensichtlich eine gibt. Nahezu alles, was ich ausliefere, lebt in dem Komfort, den sie nicht hatte: Wenn es bricht, schiebe ich eine Korrektur nach. Dieses Sicherheitsnetz ist real, und es senkt unmerklich die Messlatte – es erlaubt mir, den Idealfall auszuliefern und mir einzureden, ich kümmere mich später um den Fehlerfall, weil es ein Später gibt. Apollo ist der Tadel. Wenn man es wirklich nicht flicken kann, entdeckt man, dass „den Fehler später behandeln” nie Ingenieurskunst war; der Fehlerfall ist die Ingenieurskunst, und der funktionierende Pfad ist nur das, was übrig bleibt, sobald das System sein Brechen bereits übersteht. Wenn ich also jetzt etwas baue – eine Aufgabe, die überflutet werden kann, eine API, die falsch aufgerufen werden kann, einen Pfad, der zum falschen Zeitpunkt eingeschlagen werden kann – versuche ich zu fragen „was ist hier der Radarschalter in der falschen Position, und wirft dies ihn ab und fliegt weiter?”, bevor ich frage, ob der Idealfall funktioniert. Ein System, das nur korrekte Eingaben übersteht, ist ein System, das ich nicht fertiggestellt habe.

Die zweite Lehre ist, dass der vertrauenswürdigste Fehler derjenige ist, den der Entwurf unmöglich gemacht hat. Der Lauren-Bug bleibt mir, weil Hamilton recht hatte und von „das würde niemand je tun” überstimmt wurde – und das Universum tat es sofort, bei der nächsten Mission. Mein Instinkt ist, Fehler zur Laufzeit abzufangen, den gefährlichen Aufruf in eine Absicherung zu hüllen und weiterzumachen. Hamiltons tieferer Zug, der, dem sie dreißig Jahre widmete, ist, das System so zu entwerfen, dass der gefährliche Aufruf gar nicht gemacht werden kann – den schlechten Zustand undarstellbar zu machen, statt ihn bloß zu erkennen. Die Laufzeiterholung ist das Netz; Korrektheit einzubauen ist der Boden, auf dem man steht, damit man das Netz nicht braucht. Ich kann diese Messlatte nicht immer erreichen, aber sie hat das Ziel neu gerahmt: Die Frage ist nicht nur „werde ich das abfangen, wenn es schiefgeht?”, sondern „kann ich das so gestalten, dass es von vornherein nicht schiefgehen kann?” – und die zweite Frage ist, wenn ich sie beantworten kann, stets die bessere.

FAQ

Hat Margaret Hamilton den Begriff „Software Engineering” geprägt?

Margaret Hamilton wird weithin zugeschrieben, den Begriff „Software Engineering” geprägt – oder zumindest populär gemacht – zu haben, den sie in den 1960er Jahren zu verwenden begann, während sie am MIT Instrumentation Laboratory die Entwicklung der Apollo-Flugsoftware leitete.¹² Sie verwendete ihn bewusst, um zu argumentieren, dass das Schreiben von Software dieselbe Legitimität und Strenge verdiente wie Hardware und andere Ingenieursdisziplinen, und erläuterte, sie habe es „von der Hardware und anderen Arten der Ingenieurskunst unterscheiden, dennoch jede Art der Ingenieurskunst als Teil des gesamten systemtechnischen Prozesses behandeln” wollen.¹ Damals wurde die Vorstellung, Software könnte „Engineering” sein, mit einiger Belustigung aufgenommen; heute ist der Begriff so geläufig, dass er unsichtbar ist, was das Maß dafür ist, wie gründlich das Argument gewonnen wurde.¹

Was waren die Alarme 1202 und 1201 bei Apollo 11?

Es waren Programmalarme, die der Executive des Apollo Guidance Computer während der letzten Minuten des Mondabstiegs auslöste. Ein falsch gestellter Schalter des Rendezvous-Radars führte dazu, dass das Radar Prozessorzyklen stahl und den Executive wiederholt dazu brachte, Datenverarbeitungsaufgaben einzuplanen, die nicht hätten laufen dürfen, was den gesamten freien Speicher verbrauchte.³⁴ War kein „core set” an Speicher verfügbar, löste der Executive Alarm 1202 aus; war kein „VAC area” verfügbar, löste er 1201 aus.⁴ Die Alarme waren keine Abstürze – sie waren der Executive, der meldete, dass von ihm mehr verlangt worden war, als er leisten konnte, und der dann triagierte. Weil die Software prioritätsbasierte Ablaufplanung und Neustartschutz nutzte, warf sie die überflüssigen Radaraufgaben ab, startete in einen bekannten, funktionierenden Zustand neu, hielt die landungskritische Steuerung und das Display der Besatzung am Laufen, und die Landung gelang.³⁵

Was leistete Margaret Hamilton für das Apollo-Programm?

Hamilton trat 1965 dem MIT Instrumentation Laboratory bei und stieg auf, bis sie die Software Engineering Division leitete, die für die bordeigene Flugsoftware verantwortlich war, die auf dem Apollo Guidance Computer sowohl im Kommandomodul als auch in der Mondlandefähre lief.¹ Ihr Team entwarf den Echtzeit-Executive mit asynchroner prioritätsbasierter Ablaufplanung, Neustartschutz, Fehlererkennung und -behebung sowie Prioritätsanzeigen, die die Astronauten informiert und in Kontrolle hielten – die Architektur, die es dem Computer von Apollo 11 ermöglichte, den Alarm 1202 zu überstehen und die Landung abzuschließen.³⁶ Die Begründung ihrer Presidential Medal of Freedom schreibt ihr zu, „Konzepte asynchroner Software, prioritätsbasierter Ablaufplanung und Prioritätsanzeigen sowie der Entscheidungsfähigkeit mit dem Menschen in der Schleife” beigetragen zu haben, „die das Fundament für modernes, hochzuverlässiges Softwaredesign und -engineering legten.”⁶

Was ist „Development Before the Fact”?

„Development Before the Fact” ist die Systemmethodik, die Hamilton nach Apollo bei Higher Order Software und Hamilton Technologies entwickelte, aufgebaut um ihre Universal Systems Language (USL).¹⁶ Ihre These ist, dass man, statt ein System zu bauen und dann „im Nachhinein” durch Tests nach Defekten zu jagen, das System so streng und formal definiert, dass ganze Fehlerklassen – insbesondere die Schnittstellen- und Integrationsfehler, die nach ihrer Feststellung die Apollo-Defekte dominierten – durch ihre Konstruktion strukturell unmöglich sind.⁶ Das Modell ist nachweisbar konsistent, und aus ihm lässt sich korrekter Code erzeugen, sodass der Defekt zur Entwurfszeit verhindert statt zur Laufzeit entdeckt wird. Es ist der formalmethodische Ausdruck ihrer Apollo-Überzeugung: Der vertrauenswürdigste Fehler ist derjenige, den das System nie machen konnte.

Quellen