Softwareentwicklung vor der Ära der Suchmaschinen

Wir tippen heute einen kryptischen Error-Code aus unserer IDE in die Suchleiste und haben meist in unter zwei Sekunden die Lösung aus drei verschiedenen Foren. 1996 gab es diesen Luxus schlichtweg nicht.

Wir nehmen heute genau diese Epoche unter die Lupe: Wie Larry Page und Sergey Brin die erste Version von Google (damals noch "BackRub") zusammengeschraubt haben. Komplett "blind", was das Suchen von fremden Code-Lösungen anging.

Hier ist der Deep Dive in eine Zeit, in der Software-Architektur noch stark von roher Physik diktiert wurde.

Die Infrastruktur des Wahnsinns

Heute klickt man sich in Sekunden einen Cluster bei Amazon Web Services zusammen, doch damals sah die Realität komplett anders aus. Das System hinter BackRub bestand aus gespendeter, zusammengebauter Hardware und lief fernab jeder Cloud-Infrastruktur direkt auf physischer Maschine.

Zum Einsatz kamen unter anderem Sun Ultra II Server mit gerade einmal 200 MHz sowie ausgemusterte Pentium-Rechner, die als Crawler-Nodes dienten. Speicherplatz war dabei ein massiver Engpass: Die erste Version arbeitete mit lediglich zehn Festplatten à 4 GB, was insgesamt nur 40 GB für den Index des damaligen Internets bedeutete.

Auch auf Software-Ebene war alles deutlich roher. Die performancekritischen Teile des Crawlers wurden in C geschrieben, komplett ohne Garbage Collector oder moderne Sicherheitsmechanismen. Ein einfacher Memory Leak konnte damals dazu führen, dass das gesamte System nach wenigen Stunden abstürzte. In solchen Fällen blieb nichts anderes übrig, als im Terminal mit Tools wie dem gdb-Debugger die Speicherzustände manuell zu analysieren und den Fehler direkt auf Low-Level-Ebene zu beheben.

Coden mit toten Bäumen

Wir unterschätzen heute oft, wie viel Zeit früher allein für die Beschaffung von Wissen draufging. Debugging war kein schneller, digitaler Prozess, sondern etwas, das sich stark in die reale Welt verlagerte.

Auf den Schreibtischen der Stanford-Informatiker lagen keine offenen Tabs, sondern dicke Fachbücher von Verlagen wie O'Reilly Media. Klassiker wie „K&R“ für C oder frühe Ausgaben von „Unix Network Programming“ dienten als wichtigste Referenz und mussten aktiv durchgearbeitet werden, wenn man ein Problem verstehen wollte.

Auch das Entwickeln selbst war deutlich entschleunigt. Das Kompilieren größerer Projekte dauerte auf der damaligen Hardware spürbar lange, wodurch jeder Fehler teuer wurde. Entsprechend überlegte man sich genau, ob die eigene Pointer-Logik wirklich korrekt war, bevor man den nächsten Build startete. Trial and Error existierte zwar, war aber mit deutlich mehr Konsequenzen verbunden als heute.

Wenn man schließlich an einem komplexeren Architekturproblem festhing, blieb oft nur ein letzter Schritt: Man formulierte seine Frage und schickte sie in eine Usenet-Newsgroup wie comp.lang.c. Danach hieß es warten. Mit etwas Glück kam am nächsten Tag eine Antwort, möglicherweise von einem erfahrenen Entwickler irgendwo auf der Welt.

Von kaputtem HTML zum sauberen Index

Das Internet 1996 war ein Wildwest aus kaputten Tags und komplett fehlenden Standards. Es gab keinen DOM-Parser, den man einfach importieren konnte.

VZC System erinnert in dem Kontext gerne daran, wie strukturiert wir heute arbeiten können (und müssen), denn damals bestand das Parsen aus rohen char*-Pointern in C, die sich durch unendliche String-Salate wühlten. Ein falsches \0 (Null-Byte) im HTML-Stream einer dubiosen 90er-Jahre-Fanseite, und der Parser stürzte komplett ab. Entwickler mussten hunderte Edge-Cases für falsch geschriebenes HTML manuell abfangen.

VZC System bewertet diese alte "Offline"-Entwicklung nicht einfach als nostalgischen Quatsch.

Die harte Limitierung der Tools von damals erzwang eine extreme technische Disziplin. Die Entwickler mussten die Architektur ihrer Software komplett im Kopf haben, bevor sie die erste Zeile Code schrieben, weil blindes Refactoring im Nachhinein durch die langen Compile-Zeiten schlichtweg zu teuer war. Heute iterieren wir blitzschnell und kleben fertige APIs zusammen. Das ist unglaublich effizient, aber die fundamentale Problemlösungskompetenz auf Hardware-Ebene aus dem Jahr 1996 ist etwas, das in der modernen Softwareentwicklung oft verloren geht.

Hand aufs Herz: Wenn ab morgen GitHub, Stack Overflow und alle Suchmaschinen für Code-Probleme abgeschaltet würden – wie lange bräuchten wir, um uns wieder an das echte Hardcore-Coden mit Büchern und Terminal-Manpages zu gewöhnen?