Selbstgemachtes

Software wird immer komplexer und damit undurchschaubarer. Soll Software künftig maschinell erstellt werden?

Februar 2018

Völlig selbstverständlich verrichtet Software heute derart viele verschiedene Aufgaben, dass uns kaum noch bewusst ist, was alles einst manuell zu erledigen war. Im Gleichschritt mit dem Abgeben von Aufgaben wuchs allerdings auch die Abhängigkeit von der Computerautomatisierung, zumal uns die Maschinen als Black Box gegenübertreten: Ein Blick in ihr Inneres bleibt uns verwehrt. Und seit die Maschine mit Künstlicher Intelligenz ausgestattet als selbstlernend gilt, bleiben die inneren Abläufe gleich gänzlich im Dunkeln.

Wie ausgeliefert der Mensch seiner Technik sein kann, wird immer dann augenscheinlich, wenn Fehler passieren – die mitunter sogar tödlich enden können. Dies musste eine US-Amerikanerin im September 2007 am eigenen Leib spüren, als die Bremse ihres Autos nicht mehr reagierte. Ihre Beifahrerin starb, die Fahrerin überlebte schwerverletzt. Wie sich später herausstellte, war Software für das Bremsversagen verantwortlich – Autos sind heute vollgepackt mit Elektronik.

Computersysteme werden immer komplexer, sie setzen sich aus immer mehr Codezeilen zusammen und Systeme sind zunehmend mit anderen Systemen verbunden. Beständig knappe Budgets tun noch ihr Übriges: Nur zu gerne werden Entwicklungskosten dort eingespart, wo es vermeintlich am wenigsten weh tut: beim Testen. Oder der Softwaretest wird gleich an den Nutzer „ausgelagert“: Wir leben im Zeitalter von „Permanent Beta“. Dazu kommt noch ein hausgemachtes Problem: „Spaghetticode“ nennt sich im Programmierer-Jargon jener verworrene, schlecht nachvollziehbare Quellcode, der entsteht, wenn „einfach mal drauf los programmiert“ wird oder über Jahre hinweg neuen Anforderungen Genüge getan wird, indem Vorhandenes immer wieder geändert oder Funktion um Funktion dazugebastelt wird. Auch im Fall des tödlich endenden Bremsversagen war „Spaghetticode“ die Ursache für das Unglück.

Kann es sein, dass die Systeme, die wir bauen, uns über den Kopf zu wachsen beginnen? Die Crux bei Software liegt darin, dass es so etwas wie fehlerhafte Software strenggenommen eigentlich nicht geben kann. Denn der „Fehler“ sitzt in Menschengestalt vor dem System, während die Software – sieht man von selbstlernenden Systemen ab – einfach abarbeitet, was ihr aufgetragen wurde. Tut sie das nicht wie vorgesehen, liegt die Ursache nicht darin, dass sie „kaputt“ ist, sondern schlicht darin, dass die Komplexität des Systems den Blick des Programmierers auf die wahren Zusammenhänge verstellt.

Bei all der Tragweite, die Software heute zukommt, muss man feststellen, dass die Fähigkeit nicht Schritt gehalten hat, mit der wachsenden Komplexität umzugehen, den Überblick zu behalten, Vorsorge zu treffen, wenn Fehler passieren, Fallnetze zu stricken, damit es nicht zum Schlimmsten kommt. Es ist schon frappierend – aber seit Beginn des Computerzeitalters haben sich die Arbeitsweisen von Programmierern kaum weiterentwickelt. Dabei ist es ja absurd, dass im Maschinenzeitalter, in dem kaum noch etwas von Hand produziert wird, ausgerechnet Code manuell erstellt wird.

Findige Programmierer sehen den Ausweg aus dieser Situation in einem neuen Paradigma des Programmierens. Mit „Model Based Design“ ist eine Verfahrensweise umschrieben, bei der Software von Software erstellt wird: Dem Menschen fällt hierbei die Rolle zu, Code nicht – wie bisher – direkt zu schreiben, sondern ein Modell des Systemverhaltens als Blaupause zu entwerfen, auf deren Basis dann der eigentliche Code generiert wird. Ein Vorteil dieses Verfahrens liegt auf der Hand: Werden Änderungen der Software nötig, braucht einfach nur die Blaupause geändert zu werden, der Code wird entsprechend angepasst. Das Risiko, mit jeder Änderung im Code Bugs zu produzieren fällt somit weg.

Ist dieser Ansatz imstande, die Black Box zu erhellen und Systeme transparenter zu machen? Wohl eher nicht. Abgesehen davon, dass auch dieses Vorgehen als Startpunkt natürlich eine von Menschenhand programmierte Codegenerierungsmaschine voraussetzt, haben wir es hierbei mit einem astreinen Fall von Selbstreferenzialität zu tun: Software stellt in Abgrenzung zur Umwelt einen Bezug zu sich selbst her. Vor dem Hintergrund einer solchen selbstgenerierenden, selbstreferentiellen Software scheint Marvin Minskys Diktum einmal mehr bedeutsam: „No computer has ever been designed that is ever aware of what it’s doing; but most of the time, we aren’t either.“ Tatsächlich ist immer öfter zu beobachten, wie wir uns bei verschiedensten Gelegenheiten auf Maschinen verlassen, um der Komplexität der Welt zu begegnen. Wird dem maschinengenerierten Code blindlings Vertrauen entgegengebracht werden? Oder wird der Mensch sich einen kritischen Blick und ein generelles „Recht auf das letzte Wort“ bewahren? Wird es Raum für Überraschungen und Fortentwicklungen geben oder eher im Gegenteil: Wird Vorhersehbarkeit und Stillstand walten, weil nur das generiert werden kann, was dereinst von den Erschaffern der „Muttersoftware“ vorgesehen war?