Der erste Computer-Bug war eine echte Motte – und der Fund erklärt dein Debugging von heute

Kurz vorweg, damit du nicht scrollen musst: Am 9. September 1947 fischte das Team am Harvard Mark II eine tote Motte aus einem Relais, klebte sie mit Tesa ins Logbuch und schrieb daneben „First actual case of bug being found“. Das Logbuch liegt bis heute im Smithsonian. Die Motte auch.

Netter Fun Fact für die nächste Standup-Runde. Aber der eigentliche Wert steckt woanders: Dieses Logbuch ist die erste dokumentierte Root-Cause-Analyse der Computergeschichte – und sie folgt exakt dem Workflow, den ich heute noch fahre, wenn ein Container um 23 Uhr grundlos stirbt. Ich zeige dir den Fund, räume drei Mythen ab und leite daraus einen 15-Minuten-Debug-Workflow ab, den du sofort nachbauen kannst.

Was am 9. September 1947 wirklich passierte

Der Harvard Mark II war ein elektromechanischer Relais-Rechner. Kein Silizium, keine Transistoren – tausende physische Schaltkontakte, die klackernd auf- und zugingen. Warm, offen, laut. Für ein Insekt auf Wärmesuche: ein Fünf-Sterne-Hotel.

Das Team am Computation Laboratory der Harvard University stellte an diesem Tag Fehlfunktionen fest, arbeitete sich zur Ursache vor und fand sie in Relais #70, Panel F: eine Motte, eingeklemmt zwischen den Kontakten. Der Logbuch-Eintrag ist auf 15:45 Uhr datiert und lautet sinngemäß „Relay #70 Panel F (moth) in relay. First actual case of bug being found.“

Die Formulierung ist der eigentliche Witz. „First actual case“ – also der erste echte, buchstäbliche Fall. Der Satz ergibt nur Sinn, wenn alle im Raum das Wort „Bug“ längst kannten. Es war ein Insider-Gag, kein Begriffs-Geburtstag. Das Computer History Museum führt den Tag deshalb völlig zu Recht als „First Instance of Actual Computer Bug Being Found“ – nicht als Erfindung des Begriffs.

Drei Mythen, die du ab jetzt richtigstellen kannst

Mythos 1: Grace Hopper hat den Begriff „Bug“ erfunden.

Nein. Thomas Edison schrieb schon in den 1870er-Jahren von „Bugs“ in elektrischen Schaltungen – kleine Fehler, die man mühsam aufspüren muss. Ingenieure benutzten das Wort also rund 70 Jahre vor der Motte. Hopper war Teil des Mark-II-Teams und hat die Geschichte in ihren Vorträgen weltberühmt gemacht. Das ist ihr Verdienst: Sie hat den Begriff popularisiert, nicht erfunden.

Mythos 2: Es war Hoppers Logbuch.

Auch nicht ganz. Das Smithsonian National Museum of American History, wo das Buch unter der Objektnummer 1994.0191.01 liegt, schreibt in der Objektbeschreibung selbst, dass das Logbuch vermutlich nicht Hoppers war. Wer den Eintrag geschrieben hat, ist nicht restlos bewiesen – Historiker schreiben die Handschrift jedoch meist dem Operator William „Bill“ Burke zu.

Mythos 3: Die Motte hängt im Museum an der Wand.

Nope. Der Status im Katalog ist „Currently not on display“. Von rund 1,7 Millionen Objekten der Sammlung ist immer nur ein Bruchteil ausgestellt. Wenn du also nach Washington fliegst, um die berühmteste Motte der IT-Geschichte zu sehen: vorher Verfügbarkeit prüfen.

Warum dieser Fund methodisch so sauber war

Schau dir an, was das Team gemacht hat – ohne Debugger, ohne Stack Trace, ohne Stack Overflow:

1. Symptom beobachtet (Rechner liefert falsche Ergebnisse)
2. Fehler eingegrenzt bis auf eine einzelne Komponente (Relais #70, Panel F)
3. Ursache physisch isoliert (Motte entfernt)
4. Beweis gesichert und dokumentiert (eingeklebt, mit Uhrzeit protokolliert)

Punkt 4 ist der, den heute die meisten überspringen. Der Fix wird gepusht, die Ursache verschwindet im Nichts, und drei Monate später sitzt jemand wieder vier Stunden am selben Problem. Die Motte im Logbuch ist Dokumentation im Reinformat: Symptom, Ort, Zeit, Beweis.

Und das ist typisch für die Frühzeit: Vieles, was wir heute als selbstverständlich hinnehmen, ist ein eingefrorener Workaround von damals. Warum dein System auf C: liegt und die Buchstaben A: und B: bis heute reserviert blieben, ist genau dieselbe Sorte Erbstück. Wer wissen will, warum Rechner überhaupt so aufgebaut sind, wie sie aufgebaut sind, findet die Antwort bei der von-Neumann-Architektur – der Rest der schönen Randnotizen steht in der Rubrik Computer History und im Bereich Nerd.

Mein 15-Minuten-Debug-Workflow (1947er Logik, 2026er Tools)

Ich habe mir aus genau diesen vier Schritten einen festen Ablauf gebaut. Kein Rumklicken, keine Bauchgefühl-Fixes.

Schritt 1 – Symptom in einem Satz aufschreiben (2 Min). „Login schlägt fehl“ reicht nicht. „Login schlägt bei Nutzern mit Umlaut im Nachnamen seit Deploy 14:20 mit 500 fehl“ ist eine Hypothese. Der Satz muss Wer, Wann, Was enthalten. Pro-Tipp: Schreib ihn in das Ticket, bevor du die erste Zeile Code anfasst. In 30 % der Fälle löst dich allein das Formulieren.

Schritt 2 – Zeitfenster eingrenzen (3 Min). Nutze git log --since="Zeitpunkt des ersten Fehlers". Was wurde zwischen „lief“ und „läuft nicht“ verändert? Das ist dein Panel F. Falls sich am Code nichts geändert hat, ist die Ursache außerhalb – Update, Treiber, Zertifikat, DNS. Speziell DNS ist die moderne Motte im Relais: unsichtbar, banal, legt alles lahm. Wenn du dir da unsicher bist, was DNS überhaupt macht, lies das nach – es zahlt sich bei jedem zweiten Netzwerkfehler aus.

Schritt 3 – Reproduzierbare Umgebung starten (5 Min). „Bei mir läuft’s“ ist kein Debugging, das ist Glück. Ich fahre jeden Bug in einem frischen Container nach. Wenn du das noch nicht standardmäßig machst, ist die Docker-Grundlagen-Anleitung der schnellste Einstieg; für Multi-Service-Setups nimmst du direkt Docker Compose. Für Web-Projekte lohnt sich zusätzlich eine saubere, gekapselte WordPress-Entwicklungsumgebung mit VirtualBox und Ubuntu – kaputt machen, wegwerfen, neu starten.

Schritt 4 – Logs an ein Modell werfen (3 Min). Hier bin ich 2026 schneller als jedes Team von 1947: Ich kippe Stack Trace plus die letzten 200 Logzeilen in ein lokales Modell und lasse mir drei Hypothesen priorisieren. Wichtig: lokal. Produktions-Logs enthalten Tokens, Mail-Adressen, interne Hostnames – das geht in keine fremde Cloud. Wie du dir das in 20 Minuten mit Ollama und OpenWebUI lokal aufsetzt, steht hier im Blog; wenn du dafür dedizierte Hardware willst, ist ein Mini-PC für lokale KI die günstigste Dauerlösung. Und ja, das Modell rät auch mal daneben – es liefert dir Suchrichtungen, keine Wahrheit.

Schritt 5 – Motte einkleben (2 Min). Ursache, Fix und Erkennungsmerkmal in eine DEBUG.md im Repo oder ins Ticket. Ein Satz. Das ist der Schritt, der dir beim nächsten Mal drei Stunden spart. Wie sich solche Mikro-Routinen zu echter Zeitersparnis addieren, habe ich im Praxisratgeber KI-Optimierung durchgerechnet.

Der Bug sitzt öfter außerhalb deines Codes, als dir lieb ist

Das ist die unbequemste Lehre aus 1947: Der Code war fehlerfrei. Die Hardware war fehlerfrei. Es lag an einem Insekt.

Übersetzt auf heute – die Klassiker, bei denen Entwickler stundenlang im eigenen Code suchen, obwohl die Ursache eine Ebene tiefer liegt:

• Thermik und Stromversorgung. Sporadische Abstürze unter Last sind selten Software. Staub, tote Lüfter, ein zu knapp dimensioniertes Netzteil. Wer beim Aufbau schon auf Airflow und Kabelmanagement achtet, spart sich diese Kategorie fast komplett.
• Das Betriebssystem. Wenn eine Maschine ohne erkennbaren Grund einbricht, sind es oft Hintergrunddienste und Update-Reste – die typischen unbekannten Ursachen, warum Windows langsam wird.
• Das Netzwerk. IoT-Geräte, die den Broadcast-Traffic fluten, sind der moderne Motten-Schwarm. Sauber per VLAN vom Heimnetz getrennt, und die Hälfte der „unerklärlichen“ Latenzspitzen ist weg.
• Fremde Infrastruktur. Dein Deploy ist grün, trotzdem ist der Dienst tot – weil ein Provider ein Zertifikat rotiert hat. Ein eigenes Homelab als Testumgebung ist die beste Investition, um solche Abhängigkeiten überhaupt sichtbar zu machen – den kompletten Einstieg gibt es im Homelab- und Self-Hosting-Guide.

Und wenn du glaubst, Hardware-Bugs seien ein Relais-Zeitalter-Problem: Intels FDIV-Bug im Pentium von 1994 war ein Rechenfehler in der Fließkomma-Division – festverdrahtet im Chip, per Software nicht heilbar. Die Rückrufaktion kostete Intel einen dreistelligen Millionenbetrag. Silizium schützt nicht vor Motten-Logik, es macht sie nur teurer. Weitere Fälle dieser Kategorie stehen in der Top 10 der Computerpannen – Pflichtlektüre für jeden, der glaubt, sein Bug sei schlimm.

Was du mitnimmst

Die Motte von 1947 ist kein Kuriosum, sondern eine Arbeitsanweisung: Symptom benennen, Bereich eingrenzen, Ursache physisch isolieren, Beweis dokumentieren. Vier Schritte, 15 Minuten, seit fast 80 Jahren unverändert gültig. Alles, was wir seitdem dazugebaut haben – Container, Observability, lokale Modelle – beschleunigt nur die Schritte 2 bis 4. Ersetzen tut es keinen davon.

Mein konkreter Vorschlag für heute: Leg eine DEBUG.md in dein aktuelles Projekt und trag den letzten Bug ein, den du gefixt hast. Zwei Minuten Aufwand. Das ist dein Logbuch – und die Motte klebst du diesmal in Textform ein.