Source Reflection #5: Programmieren als Experiment
Das Programmieren sollte heute nicht mehr wie ein Bauen mit dem Stabilbaukasten gelernt werden, sondern wie das Experimentieren mit Bakterien und Chemikalien im Forschungslabor.
- Jörg Friedrich
Das Programmieren sollte heute nicht mehr wie ein Bauen mit dem Stabilbaukasten gelernt werden, sondern wie das Experimentieren mit Bakterien und Chemikalien im Forschungslabor.
Die Generation derer, die die ersten kommerziellen Softwaresysteme für Unternehmen programmiert haben, hat sich inzwischen aus den Code-Werkstätten weitgehend zurückgezogen. Hier und da sitzt noch ein alter COBOL-Kenner am Bildschirm, denn bekanntlich sind die Systeme, die vor Jahrzehnten in Banken und Versicherungen kreiert wurden, zwar in die Jahre gekommen, aber sie gleichen weniger klapprigen Invaliden als vielmehr rüstigen Senioren, die bei guter Pflege noch eine Menge Arbeit verrichten können.
Source Reflection – die Kolumne
"Was tun wir hier eigentlich?" – Das wird sich schon mancher im Softwareprojekt gefragt haben. Wer so fragt, wird schnell philosophisch und kommt ins Staunen über das Selbstverständliche. Dieses Reflektieren macht Software nicht auf die Schnelle besser, aber auf lange Sicht ändert es die Art, wie man Problemen begegnet, und darum geht es in dieser Kolumne.
Das ändert nichts daran, dass heute anders programmiert wird als in den 1960er- oder 1970er-Jahren, als Großrechner und Software begannen, sich aus dem Halbdunkel der Labors der Wissenschaftler, der Raumfahrt und der Rüstungsindustrie ins Licht des geschäftlichen Alltags zu kommen und sich dort rasant zu verbreiten. Es ist an der Zeit, eine Geschichte der Softwareentwicklung zu schreiben. Geschichtsschreibung ist aber nicht nur dazu da, sich zu verdeutlichen, wie man dort hingekommen ist, wo man heute angelangt ist. Vor
allem erkennt man an dem wesentlichen Unterschied zwischen dem, was am Anfang stand, und dem, was heute Alltag ist, erst richtig, was heute eigentlich getan wird.
Programmieren war in seinen Anfängen eine sehr geplante Angelegenheit. Man schrieb Programmablaufpläne und konnte Algorithmen in dicken Büchern nachschlagen. Natürlich konnte der Plan einen Fehler enthalten, der dann in der Software zu falschen Ergebnissen führte, aber der Plan, sozusagen das Modell der Software, und der fertige laufende Code auf dem Computer hatten, wenn alles richtig war, bis ins Detail die gleiche Struktur.
In den Anfängen der kommerziellen Softwareentwicklung hatte ein Programmierer einer Buchhaltung oder einer Lagerverwaltung noch das gleiche Wissen, das heute noch Hacker und Trojaner-Bauer brauchen: Er wusste über die Register des Prozessors ebenso Bescheid wie über Speicher- und Portadressen der seriellen Schnittstelle.
Die Entfernung zur Hardware wächst
Inzwischen liegen viele Softwareschichten zwischen dem Anwendungsprogramm und der Hardware. Und nicht nur das: Um eine betriebswirtschaftliche Software zu programmieren, wird selbstverständlich auf Frameworks, Open-Source- und Schnittstellenbibliotheken sowie andere Werkzeuge zurückgegriffen. Entwickler vertrauen ihnen, weil sie sich bewährt haben und weil sie zumeist zuverlässig funktionieren.
Die ersten Programmierer kannten ihre Werkzeuge nahezu hundertprozentig. Sie beherrschten ihre Programmiersprache und waren mit jeder ihrer Funktionen vertraut. Mit diesem Werkzeugkasten bauten sie ihre ihnen ebenso vollständig bekannten Systeme. Es war ein Konstruieren und Montieren wie mit einem Baukasten, in dem ein Dutzend verschiedener einfacher Komponenten verfügbar sind, die sich planvoll zu immer neuen Gebilden zusammenstecken und -schrauben lassen.
Davon ist man heute weit entfernt. Den genauen Aufbau und den Funktionsumfang der heutigen Bibliotheken und Toolkits kennen zu lernen, hätte man gar keine Zeit mehr. Das wäre auch gar nicht effektiv, denn jedes Werkzeug stellt eine Vielzahl von Funktionen bereit, von denen die allermeisten niemals genutzt werden, zumal schon in wenigen Jahren, also zwei oder drei Projekte später, neue Bibliotheken mit neuer Architektur und neuen Möglichkeiten bereitstehen.
Experimentieren wie die Biologen
Programmieren ähnelt heute eher einem Experimentieren, und zwar weniger dem der Physiker im Grundstudium als dem der Biologen in den Forschungslabors. Hans-Jörg Rheinberger [1] hat die Experimentalsysteme dieser Wissenschaftler als Kombination aus technischer Umgebung und epistemischem Ding beschrieben. Die Umgebung ist das, was man kennt und benutzt, von dem man hinreichend gut weiß, wie es sich verhält. Das epistemische Ding ist hingegen das, was man kennen lernen und manipulieren will. So geht es auch Programmierern. Sie haben eine stabile, ausreichend vertraute Umgebung, mit der sie schon das eine oder andere erfolgreiche System geschaffen haben, und versuchen, darin ein neues Gebilde zum Leben zu erwecken, ein Teilsystem durch ein anderes auszutauschen.
Zur technischen Umgebung des Experimentierens gehört nicht nur die Technik im engeren Sinne, also die Apparatur des Labors, so wie beim Programmierer dazu nicht nur die Hardware, die Datenbanksysteme, die Compiler und die verschiedenen Test-, Projektmanagement- und Dokumentationstools gehören. Alle Erfahrungen gehen in diese Umgebung ein, die ausdrücklich gelernten und die nebenbei abgeschauten Verfahren und Vorgehensweisen.
In dieser Umgebung untersucht man das Verhalten eines noch unvertrauten Teils, das "epistemische Ding". Es ist vielleicht eine neue Bibliothek, zumeist ist es aber der gerade geschriebene Code, der die Überraschungen bereithält und erst einmal in seinem Zusammenspiel mit den anderen Komponenten zu verstehen ist.
Oft probiert der Programmierer etwas aus, er studiert das Verhalten des Systems, das aus vertrauten und neuen Komponenten sowie aus dem gerade geschriebenen Code besteht. Er wundert sich nicht selten, warum sich das System gerade so verhält. Er wiederholt einen Test, so wie ein Experimentator einen Versuch wiederholt, und verändert vorsichtig ein paar Umgebungsparameter. So lernt der Programmierer zu verstehen, was das System tut. Er stellt Hypothesen auf und testet sie. Irgendwann hat er die Sache dann im Griff, vielleicht einen Fehler in den eigenen Komponenten entdeckt oder auch das Verhalten einer Funktion des Frameworks besser verstanden als zuvor.
Erfahrene Programmierer wissen, dass sie nicht viele Komponenten ihrer Entwicklungsumgebung gleichzeitig verändern sollten und dass man komplexe neue Funktionen am besten in einer vertrauten Umgebung implementiert, deren Teile man sicher beherrscht. Sie wissen auch, dass das Unbekannte, das sich im Fehlerverhalten des Systems zeigt, seine Ursache nicht unbedingt im gerade geschrieben Code haben muss, sondern auch in einem noch unverstandenen, noch nicht sicher vertrauten Teil der technischen Umgebung begründet sein kann.
Rheinberger schreibt, dass im Experimentalsystem die Grenze zwischen technischer Umgebung und epistemischem Ding unscharf ist und sich jederzeit ändern kann. So geht es auch dem Programmierer. Vielleicht steckt der Fehler, der das merkwürdige Verhalten der Software hervorruft, gar nicht im Code, den er gerade geschrieben hat, sondern in einer schon lang genutzten Bibliothek? Wenn ja, ist die Teststrategie umzustellen und ganz neue Experimente sind durchzuführen.
Vielleicht wäre es eine gute Idee, den Informatik-Studenten im Praktikum eher Aufgaben zu stellen, die denen der Biologie-Studenten im Labor ähneln, als sie in stabilen und gut bekannten Umgebungen überschaubare Aufgaben lösen zu lassen. Sie müssen heute lernen, die ganze Dynamik des experimentellen Arbeitens in den Softwarelaboren der Praxis beherrschen zu lernen. Und zwar die Praktiken, in denen das Verhalten komplexer Systeme stabilisiert wird, die oft intuitiven und trotzdem systematischen Vorgehensweisen des "Tasten und Tappens" durch die verschlungenen Pfade des Codes, aus denen die Systeme heute gebaut sind.
Jörg Friedrich
ist Philosoph und Geschäftsführer eines Münsteraner Softwarehauses. Im vergangenen Jahr erschien sein Buch "Kritik der vernetzten Vernunft".
Literatur
- Hans-Jörg Rheinberger; Experimentalsysteme und epistemische Dinge; Suhrkamp 2006, S.22 ff.
(ane)
