„Software is eating the world“ – das Bonmot des Internet-Unternehmers Marc Andreessen ist in aller Munde. Konkret zeigte sich seine Bedeutung wohl zum ersten Mal drastisch im Sommer 2015 in den USA. An einem einzigen Tag geschah folgendes: Die Fluggesellschaft United Airlines erteilte Flugverbot wegen eines Defekts im Abflugkontrollsystem; der Handel an der New Yorker Börse fiel aus wegen eines unerklärlichen „internen“ Fehlers; die Webseite des Wall Street Journals stürzte zeitweilig ab; die Notrufnummer 911 in Seattle antwortete nur mit dem Besetztsignal.
Eine Cyberattacke? Schlimmer: purer Zufall – als ob sich die Software spontan zu einer Konspiration entschlossen hätte. Der Code beisst zurück. Der amerikanische Programmierer und Autor James Somer hat kürzlich im Magazin „The Atlantic“ vor der „kommenden Software-Apokalypse“ gewarnt.
Nichtintendierte Effekte
Die Ironie ist unverkennbar: Wir suchen den Zufall durch automatisierte Systeme zu verbannen und bereiten ihm gerade dadurch den Boden. Im Jahre 2007 fuhr die Amerikanerin Jean Bookout mit ihrer Freundin in einem Toyota auf der Autobahn. Plötzlich schien das Gaspedal festzuklemmen. Frau Bookout nahm den Fuss vom Pedal, aber das Auto verlangsamte die Fahrt nicht. Sie betätigte die Bremsen, keine Reaktion. Als sie mit über 60 km/h auf eine Ausfahrt zuschlingerte, zog sie die Notbremse. Nach einer Bremsspur von 50 Metern prallte der Wagen in eine Böschung. Die Mitfahrerin wurde getötet, Frau Bookout wachte einen Monat später im Spital auf. Nach zähen juristischen Verhandlungen um die Verantwortlichkeit fand ein Expertenteam schliesslich den Grund für die Widerspenstigkeit des Autos heraus: einen „nichtintendierten Effekt“.
Das ist beschönigender Jargon für ein sich verbreitendes beunruhigendes Phänomen bei automatischen Artefakten. Man könnte von der zunehmenden Prekarität der Systeme sprechen: je komplexer, desto anfälliger für Fehler. Die Rede ist von „Spaghetti-Code“, von Software, die sich immer unentwirrbarer verknäuelt. Zum Beispiel dann, wenn sie über die Jahre anwächst mit neuen Features, die auf bereits bestehende gehäuft werden. Schliesslich ist der Code nicht mehr entschlüsselbar, geschweige denn auf Fehler zu testen. Noch fataler: Ein einziger Bit-Flip im Speicher – eine Eins wird zu einer Null oder umgekehrt – kann sich zur unvorhergesehenen Kalamität auswachsen.
30 Millionen Zeilen Code
Das sind Indizien für die Notwendigkeit, unseren Blick auf die Technik neu zu eichen, vor allem jetzt, da autonome Vehikel sich in den Verkehr einzufädeln beginnen. Früher baute man Software in Autos oder Flugzeuge ein. Heute baut man Autos oder Flugzeuge um die Software herum: mechanische Gehäuse für den Code. Auto- und Flugzeugindustrie sind wesentlich Software-Industrie. Die Software eines Airbus umfasst etwa 30 Millionen, die Software eines Tesla etwa 100 Millionen Codezeilen.
Emmanuel Ledinot, Forschungsleiter beim Flugzeughersteller Dassault, sieht den Grund für die Fehlerinflation in der Unmenge von Software: „Als ich 1988 an militärischer Avionik zu arbeiten begann, stellten ich und meine Kollegen eine wachsende Zahl von Bugs fest.“ An die Stelle eines einzigen Bordcomputers seien Dutzende getreten, jeder davon spezialisiert für besondere Funktionen der Kontrolle, Navigation, Kommunikation. Solche Rechner zu koordinieren, wenn eine Flut von Flugdaten anströmt, erfordere quasi eine symphonische Leistung perfekt getimter Aktionen. „Das Handling Hunderter, ja Tausender von möglichen Aktionen in der richtigen Abfolge und zum richtigen Zeitpunkt“, so Ledinot, „wurde als die Hauptursache der Fehlerinflation diagnostiziert.“
Defizit in der Fehlerkultur
Der Standardrahmen, in dem wir über technische Fehler nachdenken, stammt aus der Zeit kurz nach dem Zweiten Weltkrieg, vor dem Aufkommen der Software. Die Grundidee war, dass die Verlässlichkeit eines technischen Systems auf der Verlässlichkeit seiner Komponenten basiert. Man muss also gewappnet sein gegen den Zusammenbruch der Komponenten. Software aber bricht nicht in diesem mechanischen Sinn zusammen. Sie mag Defekte haben – Bugs –, aber sie führt nichtsdestoweniger Instruktionen aus. Sie hat keinen Begriff davon, dass sie Falsches tut.
Umsichtige Informatiker konstatieren deshalb ein grundlegendes Defizit in der Fehlerkultur des Programmierens und suchen nach einer neuen Herstellungsweise von Software. Ausgangspunkt ist das folgende Problem: Die Rechenstärke der Computer nimmt ständig zu, aber die herkömmlichen Programmiersprachen halten mit diesem Zuwachs immer weniger Schritt. Grund: viel zu viel überflüssiger Code. So sagt etwa Chris Granger, Entwickler der integrierten Programmsammlung Visual Studio von Microsoft: „Visual Studio hat über 55 Millionen Codezeilen. Und ich fand heraus, dass 98 Prozent völlig irrelevant sind. So viel Arbeit wurde in dieses Ding gesteckt, aber sie verfehlte die wesentlichen Probleme.“ Das heisst: Die Leute sind zu sehr auf den Code fixiert und fragen zu wenig, was eigentlich das Problem sei, das gelöst werden soll.
Nachhaltige Produktion von Software
So wie es ein nachhaltiges Produzieren von Hardware gibt – möglichst wenig stofflichen Müll in die Umwelt abführen –, so könnte man von einem nachhaltigen Produzieren von Software sprechen: möglichst wenig Codemüll in die automatischen Systeme einführen. Eine Avantgarde – oder eher Randgruppe – von Informatikern plädiert heute dafür, neue Programmiermethoden zu entwickeln. Sie sollten der Komplexität moderner Systeme besser angepasst sein, indem sich nicht nur Anforderungen und Vorgaben klarer und expliziter formulieren, sondern auch Fehler leichter eruieren und beheben liessen.
Eric Batégnie zum Beispiel, Gründer des französischen Unternehmens Esterel Technologies, ist ein Pionier des sogenannten modellgetriebenen Programmierens. Hier wird der Code nicht mehr direkt geschrieben, sondern zuerst ein Flussdiagramm erstellt, das die wesentlichen Funktionen und Aufgaben des zu bauenden Systems explizit macht. Anschliessend produziert der Computer automatisch den entsprechenden Code. Der Vorteil liegt darin, dass der Designer und die Maschine sich am gleichen Modell orientieren. Solcherart produzierte Software wird heute bereits erfolgreich im Flugzeugbau, in der Schwerindustrie, in Kernkraftwerken oder in der Medizinaltechnologie implementiert.
Eine neue Software-Sprache?
Leslie Lamport, einer der brilliantesten Köpfe der Informatik, hat eine Sprache entwickelt, in der Systeme auf erwünschte und unerwünschte Eigenschaften theoretisch geprüft werden können. Und hier wird ein anderes Problem manifest. Die Sprache ist sehr mathematiklastig, und schon dies schreckt viele Programmierer ab, die in der Regel nach Trial and Error vorgehen: Zeile um Zeile schreiben oder Modul um Modul einfügen und schauen, ob das Ganze läuft.
Lamports Verdikt über die gängige Programmierpraxis ist nicht eben gnädig: Man spricht von der Computerarchitektur. Architekten würden detaillierte Pläne zeichnen, bevor sie mit dem Bau beginnen; aber wenige Softwaredesigner würden, bevor sie mit Codieren beginnen, auch nur in groben Zügen skizzieren, wie der ganze Bau eigentlich aussehen soll.
Das Programm irrt sich nicht
Wie gesagt, es handelt sich hier nicht um Mainstream. Im Mainstream der Softwareentwicklung dominiert nach wie vor der Scheuklappenblick auf die Codezeilen. Man muss sich das vergegenwärtigen: Dieser Mainstream pflegt einen Denkstil, von dem wir immer abhängiger werden und den wir heute mit der Verantwortung für das Wohlergehen von Millionen von Menschen betrauen. In den Algorithmen und Datenspeichern der Grossunternehmen ist der Code der heimliche unsichtbare Herrscher. Seine Fehler sind unsichtbar. Oder vielmehr: Das wohl Bedrohlichste an ihm ist, dass er den Begriff des Fehlers eigentlich gar nicht kennt. Das Programm irrt sich nicht. Es läuft einfach – auch über den Weltuntergang hinaus.
Ach ja, die Apokalypse ist auch nicht mehr, was sie war. Fast etwas wehmütig erinnert man sich der Szenarien vor fünfzig Jahren, als ein Knallkopf im Weissen Haus oder im Kreml auf den roten Knopf drückte. Wie „romantisch“ war doch eine solche mechanische Vorstellung: Apokalypse von Hand ausgelöst. Heute ist sie in die Systeme eingebaut. Code genügt.
Die Beispiele stammen aus dem erwähnten sehr ausführlichen Artikel von James Somers: The Coming Software Apocalypse. A small group of programmers wants to change how we code – before catastrophe strikes. In: The Atlantic, Sep 26, 2017