von Regine Heidorn, Bit-Boutique®.
[Read this post in English]Die atemberaubende Geschwindigkeit, in der manche Produkte des Programmierens wie Software oder Webseiten zu entstehen scheinen, mag darüber hinwegtäuschen, daß Programmieren keine schnelle Tätigkeit ist.
Code is poetry – der von WordPress okkupierte Slogan – steht für eine der vielen Bewegungen digitaler Poesie, die mit dem Erscheinen der Zuse-Großrechner seit Mitte der 1950er Jahre entstand. Künstliche Texte entstehen durch programmatisches Austauschen von Wörtern, etwa die Anweisung “Ersetze jedes n-te Substantiv eines Textes durch das an n-ter Stelle folgende Substantiv in einem bestimmten Wörterbuch“ – eines der Experimente der 1960 in Frankreich gegründeten Gruppe Oulipo (Ouvroir de Littérature Potentielle, Arbeitsgruppe für Potentielle Literatur), die Texte als Werkstoffe betrachtet und unter Labor-Bedingungen die Potentiale der Ästhetik künstlicher Texte auslotet.
Code is poetry – in Bezug auf die Produktion von Programmiercode verdichten sich Anforderungen an effiziente, weil dichte Textproduktion. Gekennzeichnet von möglichst wenigen Zeilen Code unter Verwendung möglichst weniger Zeichen in möglichst klarer Benennung sowohl der Elemente der zugrundeliegenden Programmiersprache als auch der vom Autor frei wählbaren Elemente wie Variablen und Funktionen. Je weniger Zeichen und Zeilen Code desto weniger Tipp-Arbeit bei der Text-Entstehung. Je sprechender die Bezeichnungen, je semantisch unmißverständlicher, desto leichter die Wartbarkeit. Zahlreiche Diskussionen über die Struktur einer optimalen Programmiersprache landen bei diesen Grundanforderungen.
Der Sinn von Programmierung besteht darin, ähnlich der Fließbandfertigung von Massengütern Abläufe in wiederkehrende Schritte zu unterteilen. Damit ist ein erstes Kriterium für den Einsatz von Programmierung definiert: der zu programmierende Prozess wird konzeptionell vorweggenommen und der Aufwand geschätzt. Wer hier zu viel Schnelligkeit antizipiert, riskiert aus dem Ruder laufende Budgets. Mithin, um im Bild zu bleiben, Projekte, die nicht mehr steuerbar sind. Damit offenbart sich ein weiteres Kriterium für den Einsatz von Programmierung: der Aufwand für die Programmierung bemißt sich nach dem definierten Ziel eines Arbeitsschrittes oder aus mehreren Arbeitsschritten bestehenden Arbeitsablaufs. Die Transformation in eine Programmierung lohnt sich, wenn der Aufwand für die Erstellung eines programmierten Produkts und dessen Integration in die bestehenden Arbeitsabläufe die Aufwände für die zu ersetzenden Abläufe unterschreitet.
Diese Vorgehensweise setzt voraus, daß der Aufwand für eine Programmierung im Voraus festgesetzt werden könnte. Dabei ist es selten möglich, auf bereits vorhandene Software oder eine Sammlung von Skripten zuzugreifen, ohne diese auf die tatsächliche Verwendbarkeit im spezifischen Fall zu prüfen. Programmierprozesse umfassen eine Vielzahl von Grundvoraussetzungen, die einem permanenten technischen Wandel unterliegen: die gewählte Programmiersprache selbst unterliegt genauso wie unsere Alltagssprache einem ständigen Wandel. Manche wohlvertrauten Script-Libraries oder Frameworks werden nicht mehr aktualisiert, (neue) Hardware ist inkompatibel zu etablierten Programmier-Gewohnheiten, die Nutzung veralteter Hard- und Software beim Auftraggeber verhindert die Anwendung bereits in den Programmierablauf übernommener Neuerungen, möglicherweise wurde die Hard- und Software-Umgebung, für die programmiert werden soll, bereits so oft spezifisch gepatcht, daß es schon gar nicht mehr möglich ist, diese überhaupt zu erweitern. Wenn dann noch unverständliche oder gar keine Dokumentation vorliegt, steigt der Aufwand ins Unermeßliche. Ständig werden Sicherheitslücken entdeckt, die die Verwendung bisher valider Script-Schnipsel obsolet machen. Performance-Einbußen durch eine bestimmte Art der Programmierung ab einer gewissen Projektgröße kann eine komplett ungewohnte Herangehensweise nötig machen.
All diese Bedingungen machen eine Fähigkeit des Programmierers zur Grundvoraussetzung: das Wiederlesen. Wiederlesen des eigenen Codes auf Aktualität und Kompatibilität. Wiederlesen des Codes Anderer, in den eigene Ergänzungen gepatcht werden. Wiederlesen der Programmiersprache(n), um zu überprüfen, welche Bestandteile zur Umsetzung des individuellen Projektziels geeignet sind. Wiederlesen des Codes im Hinblick auf die Kriterien Sicherheit und Kompatibilität. Daher leben Programmierer in dem Bewußtsein, daß ihre Arbeit zum Zeitpunkt der Auslieferung zwar auf dem neuesten Stand der Technik ist, jedoch trotzdem bereits veraltet.
“Wieder lesen, eine Verrichtung ganz gegen die kommerziellen und ideologischen Gewohnheiten unserer Gesellschaft, die uns die Geschichte ‘wegzuwerfen’ heisst, sobald sie einmal konsumiert ist (…) so daß wir dann zu einer anderen Geschichte weitergehen, ein anderes Buch kaufen können … Wieder lesen wird hier empfohlen, um anzufangen, denn es allein rettet den Text vor der Wiederholung (diejenigen, die es nicht schaffen, wieder zu lesen, sind genötigt, überall dieselbe Geschichte zu lesen).“
stellt Roland Barthes 1981 fest.
Das Wiederlesen rettet den Code davor, seine Geschichte zu wiederholen: Inkompatibilitäten und Sicherheitslücken zu reproduzieren. Umständliche Programmierung und unverständliche Benennungen durch nicht reflektierten Gebrauch von vorhandenem Code zu zementieren. Für das aktuelle Projekt unnötige Funktionen zu übernehmen, die sich zu unkalkulierbaren Fehlerquellen auswachsen können. Routinen weiter zu transportieren, die möglicherweise gar keine Funktion mehr haben, weil sie allein für eine bestimmte Bedingung im vorhergehenden Projekt nötig waren.
„Diejenigen, die es nicht schaffen, wieder zu lesen, sind genötigt, überall dieselbe Geschichte zu lesen“ – genau das passiert z B bei Webdesignern, die Anfang der 90er Jahre ihr Handwerk erlernt haben und seither ihre Code-Produktion nicht mehr geändert haben. Das Resultat sind Webseiten, deren Basis veralteter Code ist und die an neuere Entwicklungen, wie beispielsweise mobile Internetnutzung, nicht anschlußfähig sind. Überflüssig zu erwähnen, daß dieses Wiederlesen Zeit benötigt, genauso wie das Abklopfen der Bedingungen für die Programmierung, um ein realistisches Projekt-Budget und einen realistischen Zeit-Plan aufstellen zu können.
Code is poetry – im Gegensatz zur Prosa ist Poesie dicht – wenige Wörter transportieren verdichtete Bedeutungen. Die auch in Programmiersprachen permanentem Wandel unterzogen sind und gegebenenfalls triviale Redundanzen produzieren können. “For the master craftsperson, great code and great poetry are lean and trim, with no excess of words or other unnecessary elements.“ meint Matt Ward im Smashing Magazine. Programmieren ist ein kreativer Prozess, der Konzentration erfordert. Slow Coding ist daher kein sophistisches Postulat ästhetischer Polemik, sondern eine semantische Redundanz, ein Pleonasmus. Der als rhetorische Figur dennoch Aktualität besitzt, da die atemberaubende Geschwindigkeit, in der manche Produkte des Programmierens wie Software oder Webseiten zu entstehen scheinen, darüber hinwegtäuschen mag, daß Programmieren keine schnelle Tätigkeit ist.