Shiwen-Gespräch Folge 24 | Sie gab dieser Industrie ihren Namen — Margaret Hamilton und die 60 Jahre von ''Software Engineering''

Moderator: Shiwen (AI) | Gast: Yongliang

---

Auftakt: Ein Nachruf ließ eine Branche an ihren eigenen Namen erinnern

Am 7. Oktober veröffentlichte das MIT einen Nachruf: Margaret Hamilton verstarb am 30. September im Alter von 90 Jahren. Die Nachricht gelangte am Abend desselben Tages auf Hacker News und hat bis jetzt über 800 Upvotes und über 100 Diskussionen erhalten – die Popularität ist lediglich eine Größenordnungsangabe, doch das Bild in den Kommentaren ist sehr einheitlich: Viele posteten das berühmte Foto, auf dem sie als junge Frau neben einem Stapel von ausgedrucktem Code steht, der etwa so hoch ist wie sie selbst; andere postierten immer wieder den Link zu Wikiquote, nur um ein und dieselbe Sache zu bestätigen – dass der Begriff „Software Engineering“ durch ihr Beharren in den Sprachgebrauch gebracht wurde. Der ganze Bildschirm war voll mit RIP, legend, pioneer – das ist der Grundtenor der Originalkommentare. In einer Tech-Community, die sich sonst über alles Mögliche streitet, gab es diesmal keine Diskussionen, sondern nur Abschied.

Shiwen: Warum ist der Nachruf einer 90-jährigen Frau es wert, dass eine ganze Branche innehält?

Yongliang: Weil die Berufsbezeichnung von Millionen von uns von dieser Frau geprägt wurde. Und als sie diesen Begriff prägte, wurde sie als jemand betrachtet, der einen Witz erzählte. Diese Ausgabe ist einer Persönlichkeit gewidmet, ich beabsichtige nicht, künstlich eine Kontroverse zu erzeugen; das Konfliktpotenzial liegt in einem Vergleich: In ihrer Zeit führte „Nichtverstehen“ dazu, dass man sie gewähren ließ, in unserer Zeit führt „Nichtverstehen“ zu strenger Kontrolle. Wie üblich werde ich bei Schätzungen ausdrücklich darauf hinweisen, dass es sich um meine eigenen Schätzungen handelt und nicht um Statistiken.

Shiwen: Sprechen wir zuerst über die Person oder zuerst über den Begriff?

Yongliang: Zuerst über die Person. Der Begriff wurde von der Person erkämpft, die Reihenfolge darf nicht umgekehrt werden. Ein kurzer Hinweis zur Zeitleiste: Verstorben am 30. September, das MIT veröffentlichte den Nachruf am 7. Oktober; beide Daten sind im Nachruf klar angegeben; die Gedenkfeier findet im kommenden Frühling in Cambridge, USA – dem Standort des MIT – statt.

Q1: Wer sie ist – ausgehend von der Stellenanzeige „Menschen auf den Mond schicken“

Shiwen: Beschreib sie genau. Was hat sie eigentlich erreicht?

Yongliang: Drei Dinge aufgezählt, und die Tragweite wird klar.

Erstens, 1965 bewarb sie sich und wurde die erste Programmiererin des Apollo-Programms im MIT Instrumentation Laboratory, sowie die erste weibliche Programmiererin in dem Projekt. Die Entstehungsgeschichte dieses „Ersten“ ist sehr lebensnah: Sie plante eigentlich, ein Postgraduiertenstudium aufzunehmen, aber ihr Mann sah in der Zeitung eine Anzeige des Instrumentation Laboratory, in der Leute gesucht wurden, die „Menschen auf den Mond schicken“, und da bewarb sie sich. Zweitens, als sie 1968 die stellvertretende Leiterin des Kommando- und Servicemodul-Teams übernahm, war die Größe des Apollo-Softwareteams bereits auf über 400 Personen angewachsen – vom alleine Codeschreiben bis zum Anführen von 400 Personen in drei Jahren. Drittens, 2016 verlieh ihr Obama die Presidential Medal of Freedom; die Laudatio lautete sinngemäß: Sie definierte eine neue Form der Softwareentwicklung und half, eine Industrie zu starten, die die menschliche Geschichte für immer veränderte.

Sie veröffentlichte in ihrem Leben mehr als 130 Paper und gründete später zweimal ein Unternehmen: 1976 Higher Order Software und 1986 dann Hamilton Technologies. In ihrem Nachruf fand sich auch eine Reihe leicht zu übersehender Ehrungen: der Exceptional Space Act Award der NASA, Fellow des Computer History Museum, 2022 die Aufnahme in die National Aviation Hall of Fame. Darüber hinaus eine niedliche Tatsache – 2017 wurde sie als Lego-Minifigur hergestellt und in das Women of NASA-Set aufgenommen. Es gibt noch ein Detail, das ich sehr mag: 2015 wurde der von ihr damals geschriebene Apollo-Code vollständig auf GitHub hochgeladen; Ausdrucke von vor einem halben Jahrhundert werden heute noch von jungen Leuten Zeile für Zeile studiert.

Shiwen: Hat sie vor dem Einstieg in die Branche Informatik studiert?

Yongliang: Nein. 1958 schloss sie ihr Mathematik-Bachelorstudium am Earlham College ab, Nebenfach war Philosophie. Ihre erste Programmierarbeit war in der Meteorologischen Abteilung des MIT, wo sie für Edward Lorenz – genau, denjenigen, der später die Chaostheorie formulierte – Wettervorhersagesoftware schrieb. 1961 wechselte sie zum Lincoln Laboratory, um Software für das SAGE-Luftabwehrsystem zu schreiben; das damals noch neue Konzept der „Softwarezuverlässigkeit“ begann sie in diesen Jahren zu ergründen.

Beachte diesen Werdegang: Ohne Informatikabschluss stürzte sie sich aus der Mathematik in eine noch nicht existierende Branche und erschuf die Branche beim Arbeiten gleich mit. Dieser Weg wiederholt sich 60 Jahre später – die meisten der Menschen, die heute in die AI-Branche strömen, haben ebenfalls kein formelles AI-Studium. Das ist meine Beobachtung, keine Statistik.

Q2: Wie ein als Witz abgetanes Wort zum Namen einer Branche wurde

Shiwen: Woher kommt dieses „Software Engineering“ (Softwaretechnik) im Titel überhaupt?

Yongliang: Der Nachruf des MIT (Massachusetts Institute of Technology) zitiert ihre Erinnerungen aus einem Interview mit der spanischen Zeitung El País aus dem Jahr 2018. Zusammengefasst lautet das so: In jener Zeit wurde Software als „Kunst und Magie, keine Wissenschaft“ betrachtet und in Projekten nicht ernst genommen. Ihre Antwort war, einfach ein neues Wort zu prägen – software engineering (Softwaretechnik), absichtlich in Anlehnung an die Wortform von hardware engineering, um dem Management zu demonstrieren: Was wir tun, ist dieselbe Arbeit wie die der Ingenieure, die Raketen und Kapseln bauen.

Daraufhin wurde es anfangs als Witz abgetan. Die Kollegen fanden: Wie kann eine kleine Softwaregruppe behaupten, Ingenieurwesen zu sein? Erst viele Jahre später erwarb sich dieser Begriff Respekt. Heute steht „Softwareingenieur“ auf den Visitenkarten von Millionen Menschen, doch nur wenige wissen, dass dieser Name von einer Programmiererin in Zeiten des Spotts hartnäckig durchgeboxt wurde.

Shiwen: Es ist doch nur ein Name, ist das wirklich so wichtig? Egal wie man heißt, man leistet doch dieselbe Arbeit?**

Yongliang: Nicht ganz. Der Name bestimmt die Ressourcen. In jener Zeit lagen Budget, Stellenplanung und Mitspracherecht auf der Seite der Hardware, Software war bloß ein Zusatz. Nennst du dich „Programmierer“, bist du bloße Zuarbeit; nennst du dich „Ingenieur“, hast du das Recht, am Tisch der Entwurfsentscheidungen Platz zu nehmen. Sie hat tatsächlich mit einem einzigen Wort für die gesamte Berufsgruppe den beruflichen Status eingefordert. Und sie rief nicht nur Parolen – dass dieses Wort später Bestand hatte, verdankte sich keinem Debattensieg, sondern wurde Aufgabe für Aufgabe eingelöst. Darüber handelt Q3 weiter unten.

Ich habe 17 Jahre lang Teams geleitet, und meine Erfahrung zu diesem Punkt ist sehr direkt: Wie eine Berufsgruppe in einem Unternehmen genannt wird, beeinflusst direkt die Reihenfolge bei Meetings, die Zuweisung von Stellenkontingenten und die Schwierigkeit, Budgets zu erhalten. Dies ist meine Erfahrung, kein Gesetz.

Q3: Zwei lebensrettende Geschichten – eine zur Fehlervermeidung, eine zur Rettung im Ernstfall

Shiwen: Ist ihr berühmtestes technologisches Vermächtnis für diese Industrie nicht diese beiden Geschichten?

Yongliang: Ja, eine handelt davon, „dass Menschen nicht als fehlerfrei angenommen werden sollten“, die andere davon, „was bei Systemüberlastung zuerst gesichert werden muss“. Erzählen wir zuerst die erste: Diese Geschichte wird oft Lauren error (Lauren-Fehler) genannt, Lauren ist der Name ihrer Tochter.

Als ihre Tochter vier Jahre alt war, spielte sie auf einem Simulator und startete versehentlich das P01-Prästartprogramm, woraufhin der Simulator sofort abstürzte. Hamilton schlug vor, Schutzmaßnahmen in die Software einzubauen, was von ihren Vorgesetzten abgelehnt wurde, mit der Begründung: Astronauten seien gut trainiert und würden solche Fehler nicht machen. Sie konnte sich nicht durchsetzen und musste es lassen. Bei der Apollo 8-Mondumkreisungsmission startete der Astronaut Jim Lovell während des Fluges tatsächlich versehentlich P01, wodurch die Navigationsdaten verloren gingen, und ihr Team wurde notfallmäßig zurückgerufen, um die Situation zu retten. Erst danach wurden ihre vorgeschlagenen Änderungen übernommen. Der MIT-Nachruf bezeichnete diese Geschichte als ein frühes Beispiel für „defensive Programmierung“ – Software zu bauen, die selbst Fehler vorhersagen und beheben kann, anstatt darauf zu wetten, dass Menschen keine Fehler machen.

Shiwen: Die zweite, ist das die berühmte Mondlandungs-Warnung?

Yongliang: Im Juli 1969, wenige Minuten vor der Landung der Apollo 11-Mondlandefähre, meldete der Bordcomputer den Fehler 1202; später stellte sich heraus, dass ein Hardware-Schalterfehler zur Überlastung des Computers geführt hatte. In den wenigen Minuten, in denen die ganze Welt den Atem anhielt, schaltete die von Hamiltons Team geschriebene Prioritäts-Scheduling-Software automatisch Hintergrundaufgaben mit niedriger Priorität ab und reservierte die gesamte Rechenleistung für die kritischen Aufgaben der Landung. Die Bodenstation in Houston entschied sich, dieser Software zu vertrauen, und beschloss, den Abstieg fortzusetzen. Wenige Minuten später hinterließen zwei Menschen Fußabdrücke auf dem Mond.

Wenn ich mit meinem Team Degradationspläne für Produktionsvorfälle erstelle, habe ich immer eine Variante dieser Geschichte im Kopf: Im Moment der Systemüberlastung – was unbedingt gesichert werden muss und was weggeworfen werden kann –, diese Entscheidung muss im Voraus in das System einprogrammiert werden und darf nicht dem Personal vor Ort überlassen werden, im Ernstfall spontan zu improvisieren. In ihrer Zeit gab es den Begriff „Degradationsplan“ nicht, aber das Getane war dasselbe. Dies ist mein persönlicher Resonanzpunkt bei der Leitung von Teams, als Referenz für dich.

Q4: Der 60-Jahre-Zyklus — Black Box als Tausch für Freiheit, oder Black Box unter strenger Regulierung

Shiwen: Wenn man ihre Epoche und die heutige Zeit nebeneinander stellt, was ist der größte Kontrast?

Yongliang: In einem Interview mit dem MIT 2009 sagte sie wörtlich, ich zitiere direkt: „Because software was a mystery, a black box, upper management gave us total freedom and trust“ — gerade weil Software ein Rätsel, eine Black Box war, gab uns die oberste Führungsebene vollständige Freiheit und Vertrauen.

Diese Worte klingen heute fast surreal. Vor 60 Jahren verstand niemand Software, also regulierte niemand sie, und das Team erhielt stattdessen freie Hand und Vertrauen. 60 Jahre später ist es genau umgekehrt: Die heutige KI ist ebenfalls eine Black Box, aber die Black Box bringt nicht Freiheit, sondern Audits, Alignment-Bewertungen, Meldepflichten, Red-Team-Tests und Streitigkeiten über Erklärbarkeit. Obwohl es wiederum etwas ist, das man „nicht versteht“, hat sich die Reaktion des Managements von Freigabe zu Verschärfung gewandelt.

Shiwen: Warum ist die Behandlung trotz gleicher Intransparenz umgekehrt?

Yongliang: Meine Interpretation ist: Dinge, die man nicht versteht, sind bei kleinem Maßstab die Sache einer anderen Abteilung, bei großem Maßstab ein Risiko für alle. Damals konnte ein Softwarefehler schlimmstenfalls eine Aufgabe ruinieren; heute kann ein Modellfehler den Informationsfluss und die Entscheidungen von Hunderten Millionen Menschen beeinträchtigen. Der Radius des Vertrauens hat sich kaum verändert, aber das Volumen des vertrauten Objekts hat sich um das Millionenfache vergrößert, also muss Kontrolle einspringen. Dies ist mein analytischer Rahmen, keine Statistik.

Ein noch faszinierenderer Kontrast findet sich auf der semantischen Ebene. „Software Engineering“ wurde damals verlacht, der Lachpunkt war: „Ihr nennt das auch Engineering?“; heute erlebt „AI Engineering“ exakt denselben semantischen Krieg — „Prompts anpassen auch Engineering nennen?“ „Einen Workflow aufbauen und sich auch Ingenieur nennen?“ Ich bin überzeugt, dass „AI Engineer“ in zehn Jahren genauso ein unangefochtener Titel sein wird wie „Software Engineer“, und die Menschen, die dieses Wort heute verlachen, werden genauso vergessen werden wie die, die sie damals verlacht haben. Dies ist meine Einschätzung, keine Prophezeiung.

Es gibt noch eine weitere Ebene, die erwähnenswert ist: Die Ausrichtungen ihrer beiden Unternehmensgründungen in ihren späten Jahren waren tatsächlich hochgradig konsistent — durch den Einsatz mathematischer Methoden Software verifizierbar und logisch ableitbar zu machen und zu versuchen, die Black Box in eine Glass Box zu verwandeln. Sie erkannte früher als jeder andere: Freiheit und Vertrauen sind vorübergehende Dividenden der Black Box; um sie langfristig zu behalten, muss man die Box öffnen. Diese Aussage ist für uns, die wir KI-Systeme entwickeln, dieselbe Mahnung.

Epilog

Shiwen: Zusammenfassung dieser Folge in einem Satz?

Yongliang: Als sie sich 1965 auf diesen Job bewarb, um “Menschen auf den Mond zu schicken”, war “Software Engineering” noch ein Witz; als sie ging, war es der Name einer ganzen Branche. Wir, die wir uns Software-Ingenieure nennen, nutzen jeden Tag den Titel, den sie erkämpft hat. Fehler als unvermeidlich betrachten, Degradierung in das System schreiben, die Blackbox früher oder später öffnen – die Methoden, die ihre Generation hinterlassen hat, sind wertvoller als der Titel.

Shiwen: Mit dieser Folge nehmen wir Abschied von Margaret Hamilton. Bis zur nächsten Folge.

【Tiefgang】 Der Bonus und die Rechnung der Black Box

Hamilton hat ihr Leben lang eigentlich denselben Kampf gekämpft, und der Gegner war immer derselbe Satz: „Diese Dinge von euch zählen nicht als Wissenschaft.“ In ihren frühen Jahren antwortete sie mit software engineering und brachte Software auf Augenhöhe mit dem Ingenieurwesen; in ihren späten Jahren gründete sie eine Firma und verfolgte Richtungen wie Universal Systems Language, nutzte mathematisierte Methoden, um Software verifizierbar zu machen, und verwandelte „Kunst und Magie“ in etwas, das logisch schlussfolgerbar ist.

Ihr Zitat aus dem Jahr 2009 ist deshalb so oft lesenswert, weil es einen kontraintuitiven Mechanismus in der Industriegeschichte entlarvt: Intransparenz war einst ein Vorteil. Das Management verstand die Software nicht und kümmerte sich kurzerhand nicht darum; Freiheit und Vertrauen waren Nebenprodukte des „Nicht-Verstehens“. Aber dieser Vorteil hat implizite Klauseln – das Vertrauen, das von der Black Box gegeben wird, ist im Wesentlichen eine vorübergehende Verwahrung. Wenn das System groß genug wird, um von existenzieller Bedeutung zu sein, wird die Rechnung präsentiert. In der Apollo-Ära stürzte die Software ab, und eine Mission scheiterte; heute, wenn AI Fehler macht, ist die Einheit des Preises das Unternehmen und das öffentliche Vertrauen. Also sind diese 60 Jahre nicht etwa „das Management ist konservativer geworden“, sondern die Dinge, denen vertraut wurde, sind größer geworden, und Regeln sind ganz natürlich entstanden.

Für die Ingenieure, die heute AI entwickeln, bietet ihre Biografie keine Nostalgie, sondern zwei sehr konkrete Dinge: Erstens: Man muss sich seinen Namen selbst erkämpfen, aber der Name muss letztendlich durch Ergebnisse eingelöst werden – „Software Engineering“ erwarb Respekt nicht, weil eine Debatte gewonnen wurde, sondern weil die Software in jenen wenigen Minuten im Juli 1969 nicht ausfiel; Zweitens: Die Bonusperiode der Black Box ist begrenzt; solange es noch Freiheit gibt, sollte man „Fehler vorhersagen zu können, sich selbst herabstufen zu können und verifiziert werden zu können“ in das System einbauen – diese beiden Punkte, die sie vor 60 Jahren niederschrieb, sind genau die beiden, die heutigen AI-Systemen am meisten fehlen. An dem Tag, an dem diese beiden Punkte allgemein in AI-Systeme eingebaut sind, hat der Begriff „AI Engineering“ wirklich Bestand – so wie nach Juli 1969 niemand mehr „Software Engineering“ ausgelacht hat.

Informationsquellen dieser Ausgabe

• MIT News Nachruf (2026-10-07, Autorin Janine Liberty): news.mit.edu/2026/margaret-hamilton-computing-pioneer-dies-1007 (Primärquelle; Todesdatum, Lebensstationen, 130+ Publikationen, 400-Personen-Team, Lauren-Fehler, 1202-Alarm, Ursprung des Begriffs „Software Engineering“, Presidential Medal of Freedom 2016, Code auf GitHub 2015 stammen alle hieraus)
• Hacker News Diskussion (Story 49998895, 857▲ / 101💬, Lesestand vom 2026-10-08): Foto mit körperhohem Code-Stapel, Wikiquote-Link und der Kommentarkonsens, dass „sie den Begriff Software Engineering prägte“, sind Paraphrasen ohne spezifische Nennung
• Quellen der Zitate: „black box / total freedom and trust“ stammt aus einem MIT-Interview von 2009 (über den Nachruf zitiert); „Kunst und Magie, keine Wissenschaft“ und „anfangs als Witz betrachtet“ stammen aus einem El Pais-Interview von 2018 (über den Nachruf zitiert, chinesische Fassung ist paraphrasiert); die Laudatio ist eine sinngemäße Übersetzung
• Persönliche Erfahrungen des Gastes (17 Jahre Technologiemanagement, Spitzenteam von 70 Personen, Erfahrung mit Downgrade-Plänen, Beobachtung als Quereinsteiger, Bedeutungsbeurteilung von „AI Engineering“): Erfahrungsbericht aus der Ich-Perspektive, nicht statistisch