Cruft, keine Patina

Stewart Brand veröffentlichte vor zweiunddreißig Jahren ein Buch namens How Buildings Learn. Die Grundidee ist einfach und unbequem: ein gut entworfenes Gebäude ist nicht das, was sich selbst gleich bleibt, sondern jenes, das sich modifizieren, bewohnen, flicken, im Lauf der Zeit neu interpretieren lässt. Brand fotografiert dieselben Gebäude im Abstand von Jahrzehnten und zeigt die Veränderungen, die ihre Geschichte erzählen. Eine seitlich angefügte Treppe, eine niedergerissene Trennwand zur Vereinigung zweier Büros, ein nach dem Brand neu gemachtes Dach, eine dreimal gestrichene und dann abgeplatzt zurückgelassene Fassade. Architektonische Qualität, so Brand, misst sich nicht im Augenblick der Eröffnung, sondern darin, wie das Objekt geschichteten menschlichen Gebrauch aushält. Das Wort, das er für diese Bedingung verwendet, ist learning: Gebäude lernen — ihr physisches Gewebe sammelt über die Jahre Information an, und an einem gewissen Punkt wird die Menge der angesammelten Information selbst Teil des Werts des Objekts.

Software lernt in diesem Sinn nicht. Software sammelt Kommentare, die sich entschuldigen.

Die Archäologie alten Codes

Wer auf einer mehr als zehn Jahre alten Codebase gearbeitet hat, kennt einen bestimmten Kommentartyp. // HACK: entfernen, wenn wir auf API v2 migrieren. // TODO: verstehen, warum das funktioniert. // NICHT ANRÜHREN: hat dreimal die Produktion zerstört. Signaturen von Personen, die nicht mehr dort arbeiten, gerichtet an künftige Lesende, die nie wirklich kommen, um sie zu lösen. Patina? Eher Narbengewebe. Der Unterschied ist nicht nur lexikalisch. Ein Aalto-Stuhl von 1932, wenn wirklich genutzt, hat heute einen ästhetischen Wert, den der frisch aus der Fabrik kommende Stuhl 1932 nicht hatte. Das Holz ist an den Stellen, wo Hände sich auflegen, dunkler geworden. Die matte Lasur hat ungleichmäßig an Glanz verloren, hat den Körper gelernt, der darauf saß. Vielleicht eine Reparatur an der Verbindung Bein/Sitz, eine ausgetauschte Schraube, eine geschmackvoll von einem Zwischenbesitzer angebrachte Verstärkung. All das macht ihn nicht schlechter. Es macht ihn schöner, wertvoller, mehr er selbst. Eine ernsthafte Restauratorin weigert sich, die Patina zu entfernen — sie ist konstitutiver Teil des Objekts geworden. Restaurierung ist die Kunst, Schaden von Geschichte zu unterscheiden.

Eine PHP-Software von 1998, wirklich genutzt, hat heute keinerlei zusätzlichen ästhetischen Wert. Sie hat geschichtete Workarounds für Browser, die nicht mehr existieren. Validierungen, dreimal auf drei Ebenen ergänzt, weil bei jedem Wartungszyklus niemand den vorherigen vertraute. Vierhundert-Zeilen-Funktionen, die Sonderfälle für Kunden behandeln, die seit zehn Jahren keine Kunden mehr sind. Niemand schlägt vor, diesen Zustand als Wertbestandteil zu erhalten. Man redet von technischer Schuld — verräterischer Begriff: Schuld, nicht Geschichte. Etwas zu tilgen, nicht zu ehren. Der Wortschatz, mit dem die Branche ihr Verhältnis zur Zeit beschreibt, zeigt: kein verfügbarer Begriff erlaubt, ein altes System schön zu nennen. Höchstens „solide“, „battle-tested“, „proven“. Tugenden des Widerstands, nicht der Akkumulation.

Die Archäologie alten Codes ist eine informelle Disziplin, die jeder Senior ausübt, ohne sie studiert zu haben. Kompatibilitätsschichten zu ausgestorbenen Browsern: if (window.ActiveXObject) für alte IE-Versionen, CSS-Hacks für Firefox-Bugs vor den großen Rewrites, Bedingungen, die window.attachEvent prüfen, um IE vom Rest zu unterscheiden, als die Konkurrenz vielfältig und uneinheitlich war. Feature Flags für nie abgeschlossene Rollouts, halber Code hinter if (feature_active('new_checkout_flow')), andere Hälfte im else-Zweig, das Feature seit sieben Jahren zu 100 % live, aber keiner traut sich, den toten Zweig zu entfernen, weil keiner mehr genau weiß, was er tat. Schemamigrationen begonnen und nie beendet, zwei Spalten koexistieren — alte und neue —, beide „sicherheitshalber“ geschrieben, je nach Stelle selektiv gelesen. Funktionen wie processOrderLegacy, processOrderLegacyV2, processOrderFinal, processOrderActuallyFinal — Reihenfolge nie abgeschlossener Aufräumversuche. Nichts davon ist Patina. Es ist ein Sedimentregister nicht eingehaltener Versprechen, von Absichten, die das Geschäftsleben überholt hat, bevor sie verwirklicht wurden. Fände eine Möbelrestauratorin in einer Kommode des 18. Jh. zwanzig Lackschichten, jede ohne Entfernung der vorherigen aufgetragen, würde sie nicht sagen, das Objekt habe an Wert gewonnen — sondern es sei schlecht behandelt worden. Alter Code wird genauso behandelt, auch von den Fachleuten, die ihn legacy nennen, im Tonfall einer Mischung aus Sachlichkeit und verdecktem Verachten. Das Wort kommt vom lateinischen legare, vermachen — hat aber technisch fast die gegenteilige Bedeutung angenommen: etwas Erlittenes, das man loswerden will. Vermächtnis als Bürde, nicht Geschenk.

Warum Software nicht altert

Die Frage ist warum. Warum gewinnen materielle Objekte im Lauf der Zeit, während digitale Objekte nur verlieren. Bequeme Antwort: ontologischer Unterschied — Code ist reine Semantik, ohne materielles Substrat, in dem sich Gebrauchsspuren ablagern könnten. Holz atmet, nimmt Feuchtigkeit auf, oxidiert, schleißt an Reibungsstellen. Das Byte tut nichts davon. Eine Binärdatei ist heute bit-genau identisch mit ihrer Geburt — abgesehen von zufälliger Datenträger-Korruption, ohne semantischen Wert. Bequeme Antworten haben den Fehler, den Diskurs genau dort zu schließen, wo er beginnen sollte.

Tiefer. Ein Stuhl altert nicht gut, weil er aus Holz ist, sondern weil sein Umfeld substanziell stabil bleibt. Schwerkraft ändert sich nicht. Menschliche Physiologie nicht. Funktion „Körper im Sitzen tragen“ nicht. Modifikationen, die er erfährt, sind interne Modifikationen seines Gewebes, im Dialog mit einer Umgebung, die viel langsamer läuft als er. Stuhl und Welt um ihn altern zusammen, im selben Tempo — Resultat eine Art domestizierte Ko-Evolution. Software lebt in einer Umgebung, die viel schneller läuft als sie. Browser wechselt alle vier Wochen die Version. Sprache bricht alle zwei Jahre die Abwärtskompatibilität. Bibliotheken haben kürzere Lebenszyklen als ein Parlamentsmandat. Das Betriebssystem, unter dem sie kompiliert wurde, hört auf zu existieren in jener Form. Software altert nicht intern wie Holz. Sie löst sich progressiv von ihrer Umgebung, wie ein Raumschiff ohne Treibstoff, das die Station entgleiten sieht. Was wir „software aging“ nennen, ist nicht Altern wie beim Stuhl. Es ist Umgebungs-Drift. Das Maß des wachsenden Abstands zwischen einem fixen Artefakt und einem mobilen Kontext.

Dieser Unterschied ist ontologisch relevant. Ein Gebäude und sein Stadtkontext altern gemeinsam in fortlaufendem Dialog — diese Ko-Zugehörigkeit ist die Bedingung, dass „Altern“ im eigentlichen Sinn überhaupt möglich ist. Software hat keine Ko-Zugehörigkeit, sie hat Kompatibilität — eine viel ärmere Beziehung. Kompatibilität bedeutet: zwei Dinge, die sich nicht mehr verstehen, können noch einen Release-Zyklus lang vortäuschen, sich zu verstehen. Wenn Brand schreibt, Gebäude lernen, beschreibt er einen Prozess, in dem Gebäude und Bewohner sich gegenseitig verändern. Wenn ein Sysadmin einen Compatibility-Shim einfügt, um eine alte Binary auf einem neuen Kernel laufen zu lassen, schiebt er einen Keil zwischen zwei Welten, die sich nicht mehr unterhalten — er kauft Zeit. Der Shim ist das Gegenteil des Lernens — er gesteht ein, dass Lernen nicht möglich ist und nur Kommunikation simuliert werden kann.

Ruskin und die Wahrheit des Gebrauchs

Ein Passus bei Ruskin, in Die sieben Lampen der Architektur: ein neues Gebäude sei seiner Natur nach falsch und werde erst durch jahrelangen Umgang wahr. Ruskin ist viktorianisch, emphatisch, oft anstrengend — aber dieser Satz ist eines der präzisesten Dinge, die je über das gebaute Objekt gesagt wurden. Die Wahrheit eines Gebäudes liegt nicht im Entwurf, sondern in der Geschichte seines Gebrauchs. Wendet man dasselbe Kriterium auf Software an, muss man schließen: Software wird nie wahr. Sie bleibt im permanenten Zustand der Neuheit, auch wenn ihr Kompilierdatum fünfundzwanzig Jahre alt ist — denn die Geschichtsanhäufung, die sie ruskinisch real machen sollte, ist im Medium nicht möglich. Sie sammelt nur wachsende Inkompatibilität mit ihrem Umfeld, und das ist keine Geschichte, sondern Erosion.

Der Unix-Einwand

Man muss den starken Einwand stellen. Unix ist über fünfzig Jahre alt — und nicht nur funktioniert es noch, es ist mit der Zeit eleganter geworden, nicht weniger. POSIX, TCP/IP, SQL, das hierarchische Dateisystem, die Pipe. Ideen, die zwischen vierzig Jahren und einem reichen halben Jahrhundert auf den Schultern tragen. Noch immer im Zentrum der digitalen Infrastruktur des Planeten. Sie verhalten sich nicht wie das PHP von 1998. Sie verhalten sich wie der Aalto-Stuhl. Etwas im Vorigen stimmt nicht.

Der Einwand ist ernst und verdient ernste Antwort. Bequem wäre: Unix ist Ausnahme, Outlier, glücklicher Fall, der die Regel nicht kippt. Schwache Antwort. Interessante Antwort: Unix widerspricht nicht der Argumentation, es zeigt deren genauen Mechanismus und klärt eine bisher implizite Unterscheidung. Die zwischen Software-als-Code und Software-als-Spezifikation.

Spezifikation, nicht Code

Was man heute „Unix“ nennt, ist nicht buchstäblich die Software, die Thompson und Ritchie 1969–1971 in den Bell Labs schrieben. Dieser Code ist seit Jahrzehnten tot. Die kommerzielle AT&T-Linie wurde verkauft, zerlegt, reabsorbiert. BSD wurde mehrmals geforked, jeder Fork wieder neu geschrieben. Linux, heute die dominante Form von „Unix“ in der Weltinfrastruktur, teilt keine einzige Zeile mit dem ursprünglichen Unix — es ist eine unabhängige Reimplementierung, 1991 von Linus Torvalds begonnen, die dieselben System-Schnittstellen exponiert, aber von Grund auf neu geschrieben wurde. macOS leitet sich von NeXTSTEP ab, ruht auf dem Mach-Mikrokernel und auf BSD-Komponenten, und auch hier ist der Code so oft umgeschrieben und neu zusammengeführt worden, dass die materielle Kontinuität zum Ausgangspunkt rein rituell ist. Was überlebt hat, ist nicht Unix’ Körper, sondern seine Form. Seine Schnittstelle. Seine Grammatik. Dass Systemaufrufe open, read, write, close heißen und mehr oder weniger funktionieren wie 1973, heißt nicht, dass der Code, der sie implementiert, gut gealtert sei. Es heißt, die Spezifikation, die sie definiert, ist etwas anderes geworden als der Code: sie wurde Kultur, Konvention, gemeinsame Sprache, De-facto- und durch POSIX dann De-jure-Norm.

Dasselbe gilt für TCP/IP. Das Protokoll überlebt, die Implementierung nicht — jedenfalls nicht im Original. Jeder moderne TCP/IP-Stack — von Linux über Windows, iOS bis zum ESP32 in einer smarten Lampe — wurde im Laufe der Jahrzehnte mehrmals neu geschrieben oder neu ausgerichtet. Der einst maßgebliche 4.4BSD Networking Code wurde nach und nach absorbiert, verzweigt, neu implementiert — die heutigen Codes wahren mit ihm eher historische als materielle Verwandtschaft. Was unverändert besteht, ist die RFC: ein Textdokument, das in technischem Englisch beschreibt, wie zwei Maschinen miteinander reden sollen. Eine RFC ist keine Software. Sie ist näher an einem diplomatischen Vertrag. Deshalb altert sie gut: sie gehört zur selben Klasse von Objekten wie ein Vertrag, eine Verfassung, eine Grammatik. Eine geteilte Konvention, deren Stärke nicht in ihrer Implementierung liegt, sondern in der Zahl der Akteure, die sie als bindend anerkennen.

SQL ist der lehrreichste Fall. Die Syntax SELECT ... FROM ... WHERE wurde Mitte der 70er von Donald Chamberlin und Raymond Boyce bei IBM definiert. Heute nutzen sie alle. Aber keine Produktiv-Relationale läuft auf dem Originalcode von System R. Postgres ist eine Reimplementierung. MySQL auch. SQLite wurde in den 2000ern von null geschrieben und ist heute vermutlich die weltweit am häufigsten verwendete Datenbank. Der Code, der SQL implementiert, ist mehrfach gestorben und wieder geboren — eine materielle Kontinuität gibt es nicht. Was bleibt: das relationale Modell — ein mathematisches Objekt — und eine bestimmte Syntax — ein kulturelles Objekt. Beide haben sich vom anfänglich verkörpernden Code gelöst, und gerade deshalb konnten sie die Zeit durchqueren.

TeX, SQLite und die bestätigenden Ausnahmen

Es gibt jedoch wenige Fälle, in denen der Code selbst etwas geleistet hat, das echter Patina ähnelt — Fälle, die im Kontrast die allgemeine Bedingung beleuchten. TeX, das von Knuth ab 1978 geschriebene Schriftsatzsystem. Knuth entschied einmal, dass TeX im wörtlichen Sinn fertig sei: keine neuen Features, nur Bugfixes; die Versionsnummer konvergiert asymptotisch gegen π in jedem Release, mit der ausdrücklichen Absicht, dass die letzte Version bei Knuths Tod den exakten Wert π annimmt und die Software für immer nicht mehr verändert werde. Knuth bietet eine kleine Geldbelohnung, die jährlich verdoppelt, an jeden, der einen TeX-Bug findet — niemand reklamiert sie seit Jahren. Nicht weil keine da wären, sondern weil die Software so massiv und so lange genutzt wurde, dass die übrigen Bugs in Ecken leben, die nie besucht werden. TeX funktioniert heute wie Ende der 80er, kompiliert dieselben Quelldateien, erzeugt denselben typografischen Output. Sein Code, in WEB geschrieben (Knuth-eigene Literate-Programming-Erfindung, Pascal für Logik, TeX für Doku), wurde 1986 als TeX: The Program, Band B von Computers and Typesetting, wie ein literarisches Werk veröffentlicht. Gelesen, kommentiert, studiert. Eines der wenigen Male, in denen Code die Schwelle reiner Implementierung überschritt und etwas Spezifikationsähnliches in der konkreten Form des Programms wurde — nicht als abstraktes RFC. Knuth erreichte das, indem er seinem Werk eine extreme Bedingung auferlegte: jede Evolution zu verweigern. TeX altert nicht, weil es sich entschieden hat, in gewisser Weise nicht zu leben. Es hat die Mumifizierung als Preis der Permanenz akzeptiert.

SQLite ist der andere interessante, jüngere und weniger mystische Fall. Die Entwicklerinnen haben in der Doku öffentlich erklärt, die Lib mindestens bis 2050 zu pflegen, mit voller Rückwärtskompatibilität der C-API und des On-Disk-Formats. Verpflichtung kein Stilmittel, sondern konkrete Bindung — SQLite ist in Avionik-Systemen integriert (u. a. Airbus A350), in Medizingeräten, militärischen Geräten — Objekte mit Lebenszyklen über vierzig Jahren. Um diesen Horizont zu tragen, hat SQLite einen Test-Apparat aufgebaut, der laut Eigenangaben bei rund 92 Millionen Zeilen Testcode gegen 150.000 Zeilen Bibliothekscode liegt — ein Verhältnis von fast 600 zu 1. Jeder bedingte Zweig ist mit MC/DC-Tests abgedeckt, dem Standard für DO-178B-Avionik-Zertifizierungen. Der Code selbst ist mit ausdrücklicher Aufmerksamkeit darauf geschrieben, von noch nicht geborenen Personen gelesen und gepflegt zu werden. SQLite hat das Problem der Dauer von Anfang an als Designproblem behandelt und die Schnittstellenstabilität als ethische, nicht nur technische Frage. Resultat: Software seit über fünfundzwanzig Jahren in Betrieb, auf Milliarden Geräten, von der niemand das Bedürfnis hatte, sie neu zu schreiben. Der Code selbst, nicht nur die Spec, scheint gut gealtert. Doch näher betrachtet wurde dieses Resultat nur durch radikale Akzeptanz von Zwängen erreicht, die der Rest der Branche nicht akzeptieren würde. SQLite ändert sich fast nie — auch um den Preis, auf moderne Features zu verzichten. SQLite hat keine externen Abhängigkeiten, fast ein Protest gegen den Software-Bau heute. SQLite hat eine fast monastische interne Disziplinkultur. Mit anderen Worten: SQLite altert gut, weil es sich eine ökologische Nische gebaut hat, in der die Umgebung um den Code künstlich stabilisiert wurde. Es hat in einem kleinen Perimeter die Bedingungen rekonstruiert, die einen Aalto-Stuhl mit den Jahren schöner werden lassen: eine langsame Umgebung, eine aufmerksame Nutzerin, eine Kultur, die den Wert der Dauer anerkennt. Kein Zufall, dass diese Beispiele statistisch Anomalien sind. Sie sind die Ausnahmen, die enthüllen, welche Bedingungen für Software-Altern nötig sind — und bestätigen, dass diese Bedingungen im Hauptteil der Branche nicht existieren.

Der Körper stirbt, die Spezifikation aufersteht

Aus diesem Blickwinkel altert Unix nicht gut. Unix ist fortwährend auferstanden. Der Körper stirbt und wird von Grund auf neu gemacht aus einer Spezifikation, die inzwischen so heilig wurde, dass sie alle zwanzig oder dreißig Jahre die integrale Neuschreibung des Körpers verdient. Religionsstruktur eher als materielle Objektstruktur. Der Aalto-Stuhl wurde nie von null neu gemacht: der Stuhl von 1932 ist physisch da, mit seinen Beulen. Wendete man Unix-Logik aufs Holz an, müsste man sagen, das Konzept „Paimio Stuhl Modell 41“ habe überlebt, weil Artek seit Gründung 1935 die Produktion über neunzig Jahre lang fortgesetzt habe und die Stühle von 2026 von denen von 1932 abstammen, aber nicht dieselben sind. Stimmt — verschoben: was uns am Stuhl von 1932 interessiert, ist genau seine materielle Dauer, nicht die Persistenz seines Modells. In Software passiert das Umgekehrte. Der Originalcode interessiert uns nicht, niemand bewahrt ihn als Reliquie. Uns interessiert die Persistenz des Modells, und diese Persistenz verlangt periodische Zerstörung und Neuschreibung des Codes.

Der Unix-Einwand widerlegt die Argumentation also nicht, er definiert sie neu. Was im Digitalen gut altert, ist nicht Code. Es sind Spezifikationen, die das Glück und das kulturelle Kapital hatten, sich über ihr Implementierungs-Substrat zu erheben und etwas anderes zu werden. Normen. Stabile Schnittstellen. Lingua francae. Der Großteil des Codes erreicht diese Ebene nie und kann sie nicht erreichen. 99 % der heute weltweit laufenden Software werden nicht POSIX. Das maßgeschneiderte CRM einer Vierhundert-Personen-Firma wird nicht SQL. Die E-Commerce-Site einer Ladenkette wird nicht TCP/IP. Nicht weil schlecht geschrieben, sondern weil sie diese Art Objekt nicht ist. Sie ist strukturell Implementierung. Und Implementierung, im Digitalen, kann nicht gut altern — sie hat keine der Voraussetzungen: kein materielles Substrat, das den Gebrauch registriert, keine stabile Umgebung zum Bleiben, kein kulturelles Gewicht für periodische Reinkarnation.

Umschreiben ist keine Sünde

Die Unterscheidung beleuchtet auch eine seit jeher schief gestellte Branchendebatte. Joel Spolsky schrieb 2000 einen vielzitierten Artikel, Things You Should Never Do, Part I, der das vollständige Neuschreiben einer funktionierenden Software als den schlimmsten strategischen Fehler einer Software-Firma bezeichnete. Argument gut und konkret: Netscape hatte den Markt verloren, weil es den Browser von null neu schrieb und dem IE drei Jahre Tür ließ. Das Problem: Spolsky generalisiert von einem Einzelfall, ohne zu erkennen, dass die Mehrheit der Software früher oder später neu geschrieben werden muss, weil sie in der konzipierten Form nicht unbegrenzt gewartet werden kann. Unix wurde mehrmals neu geschrieben. Linux selbst wird auf Subsystemebene laufend umgeschrieben: Scheduler ersetzt, Networking-Stack neu gemacht, Filesystem überdacht. Was Spolsky „nie umschreiben“ nannte, ist tatsächlich „die Spezifikations-Kontinuität bei der Neuschreibung nicht verlieren“ — sehr verschieden, sehr viel schwerer. Die Neuschreibung scheitert, wenn sie den Kontakt verliert zu dem, was der Code für seine echten Nutzer tun sollte. Sie gelingt, wenn sie die Spec bewahrt und die Implementierung wegwirft — wie der Leib eines Katholiken bestattet wird, während die Seele anderswohin wandert.

Eine versperrte Würde

Wenn diese Lesart stimmt, hat die Traurigkeit, die einen großen Teil der täglichen technischen Arbeit grundiert, eine strukturelle, nicht psychologische Erklärung. Wir schreiben nicht schlecht. Wir schreiben Objekte, die nicht altern können, weil wir nicht zur engen Klasse der Artefakte gehören, die zur kulturellen Spezifikation aufsteigen können. 99 % dessen, was wir schreiben, ist dazu bestimmt, ohne Spuren zu sterben — nicht aus Fertigungsmangel, sondern aus einer Eigenschaft des Mediums. Ein Maurer des 13. Jh. wusste: war seine Mauer gut gemacht, würde sie im 16. Jh. noch da stehen, wahrscheinlich darüber hinaus. Ein Klempner des 20. Jh. wusste, dass seine Rohre mit etwas Wartung drei Generationen dienen würden. Eine Entwicklerin von 2026 weiß, dass ihr heute geschriebener Code mit guter Wahrscheinlichkeit binnen fünf bis sieben Jahren ausgemustert wird. Nicht weil schlechter geschrieben als die Rohre. Sondern weil Rohr und Mauer einem Regime angehören, in dem Altern möglich ist, und Code nicht.

Das ändert die ethische Natur des Berufs in noch nicht metabolisierter Weise. Etwas Dauerhaftes zu bauen war über Jahrtausende eine der höchsten Würden menschlicher Arbeit. Die Kathedrale, die Brücke, das gedruckte Buch, die Geige. Objekte, gemacht im Bewusstsein, das Leben des Erbauers zu überdauern. Softwareentwicklung ist einer der wenigen hochqualifizierten Berufe, in denen diese Würde strukturell versperrt ist. Nicht weil niemand gut arbeitete — sondern weil das Medium diese Art Dauer nicht zulässt. Die anfangs erwähnte technische Schuld, aus dieser Perspektive, ist kein durch bessere Praktiken, mehr Disziplin, strengere Tests, sorgfältigere Reviews handhabbarer Defekt. Es ist die spezifische Form, in der die unvermeidliche Verschlechterung eines Artefakts, das keine andere Verschlechterungsart kennt, sich manifestiert. Software altert schlecht, weil sie nicht anders altern kann.

Die Lampe der Erinnerung

Eine breitere Lesart, die das streng Technische verlässt. Ruskin nannte sieben Architekturtugenden „Lampen“. Opfer, Wahrheit, Macht, Schönheit, Leben, Erinnerung, Gehorsam. Die Lampe der Erinnerung war für ihn die Tugend jener Bauten, die sich von der Zeit durchdringen lassen, ohne ihr zu widerstehen — die Spuren der Bewohnerinnen bewahren, zu biographischen Archiven menschlichen Durchgangs werden. Eine Zivilisation, die solche erinnerungsfähigen Objekte nicht zu bauen weiß, sagte Ruskin, hat eine ihrer fundamentalen Funktionen aufgegeben: sich durch ihre Dinge zu überliefern.

Das Digitale ist, von hier aus gesehen, das genaue Gegenteil ruskinischer Architektur. Eine materielle Kultur, wenn man sie noch so nennen darf, in der Erinnerung sich nicht in den Dingen ansammelt, sondern sie verlässt. Software von vor fünf Jahren ist schon Antiquität. Die Website von vor zehn Jahren ist nicht mehr erreichbar, ihre Domain abgelaufen, ihre Links kaputt, ihre Bilder zeigen auf abgeschaltete Server. Digitale Archive existieren nur durch heroische, marginale Anstrengungen: Internet Archive ist Single Point of Failure für drei Jahrzehnte Online-Kultur — niemand hat verstanden, wie es zu ersetzen wäre. Unsere Fotos liegen auf Servern, die uns nicht gehören, in Formaten, die in zwanzig Jahren vielleicht nicht mehr lesbar sind, geschützt durch einseitig änderbare AGB. Unsere Korrespondenz steckt in Postfächern, die verschwinden werden, wenn der Anbieter sein Geschäftsmodell ändert. Die materielle Kontinuität menschlichen Erbes — Jahrtausende lang, wenn auch unvollkommen, durch die physische Dauer der Dinge garantiert — ist auf eine Art prekär geworden, wie keine vorherige Zivilisation sie kannte.

Diese Prekarität ist kein Nebeneffekt, sondern strukturelle Mediumseigenschaft. Und Software, das Herz dieser neuen Bedingung, erbt und verstärkt sie. Sie altert nicht, weil sie keine Erinnerung in ihren Fasern ansammeln kann. Sie hat keine Fasern. Ihre einzige Form von Kontinuität ist Neuschreibung — das genaue Gegenteil von Erinnerung: die periodische Produktion eines neuen Objekts, das vorgibt, dasselbe zu sein.

Jemand wird einwenden, ich dramatisiere — jede Epoche hatte ihre Prekarität, Papyrus zerfiel, Pergament wurde abgekratzt und wiederverwendet, gedruckte Bücher brennen. Wahr, doch der quantitative Unterschied wird qualitativ. Die durchschnittliche Lebensdauer eines gut konservierten Druckbuchs misst sich in Jahrhunderten. Die einer digitalen Datei in Jahren, glücklichenfalls Jahrzehnten. Delta von ein bis zwei Größenordnungen. Eine Zivilisation, in der Kulturobjekte hundertmal kürzer halten, ist strukturell anders, nicht nur quantitativ. Sie hat ein anderes Zeitverhältnis. Sie produziert eine andere Subjektivität ihrer Bewohner. Eine Entwicklerin weiß, was eine Drucker:in des 16. Jh. nicht wusste: dass ihre Arbeit sie nicht überleben wird.

Der Einwand des Vergänglichen

Es gibt eine weniger tragische Lesart, die einen Durchgang lohnt. Möglicher Einwand: Permanenz ist nicht zwingend Tugend, und Software könnte eine Form bewusst vergänglicher Kulturproduktion sein — wie eine Theateraufführung oder ein Jazzkonzert vergänglich sind, und ihre Vergänglichkeit kein Defekt, sondern konstitutives Merkmal ist. Eine Lambda-Funktion, die 37 Millisekunden läuft und verschwindet, ist kein gescheitertes Objekt, weil sie nicht dauert — sie ist voll realisiert, weil sie genau das tat, was sie zur richtigen Zeit tun sollte. Die Monument-Metapher aus der Architektur könnte schlicht ungeeignet sein, und auf dem „nicht gut altern“ zu beharren wäre wie sich zu beklagen, ein Gewitter altere nicht gut: eine nicht zutreffende Kategorie.

Der Einwand ist interessant, bricht aber, wenn man ihn ernst nimmt. Das Problem ist nicht der 37-ms-Code. Das ist wirklich Ereignis, kein Objekt. Das Problem: die fast gesamte Software, von der unser Alltag abhängt, ist kein Ereignis in diesem Sinn — es ist Infrastruktur. Das System, mit dem unsere Bank Konten führt, ist keine Jazz-Performance. Die medizinische Software des Beatmungsgeräts auf der Intensivstation ist kein Gewitter. Die Melderegister-Datenbank der Gemeinde ist keine vergängliche Funktion. Sie sind Objekte, die Infrastruktur sein wollen, die wir wie Infrastruktur behandeln, die Institutionen in ihre Prozesse einschreiben, als wären sie es — die aber die Dauer- und Erinnerungseigenschaften einer Wolke haben. Diese Diskrepanz zwischen sozialer Funktion und materiellen Dauer-Eigenschaften ist der Punkt, an dem die Frage nicht mehr philosophisch, sondern zivil wird. Eine Gesellschaft, die ihre Vitalfunktionen Objekten anvertraut, die nicht altern können, lagert leise die Kosten der Aufrechterhaltung ihrer eigenen Kontinuität auf eine technische Schicht aus, die diese nicht zu tragen weiß.

Prekäre Infrastruktur, nachhinkendes Recht

Der EU-Cyber-Resilience-Act, beschlossen als Verordnung (EU) 2024/2847, voll anwendbar ab Dezember 2027, die neue PLD (EU) 2024/2853, die NIS2-Pflichten — sind aus diesem Blickwinkel ungeschickte, aber sprechende Versuche, Software dazu zu zwingen, sich wie ernsthafte Infrastruktur zu verhalten. Sie zwingen Hersteller, eine Supportzeit zu definieren, die den erwarteten Lebenszyklus widerspiegelt — meist mindestens fünf Jahre —, aktuelle SBOMs zu führen, auch nach Verkauf in das Produkt eingeführte Schwachstellen zu beheben. In gewissem Sinn der gesetzgeberische Versuch, Software jene Dauer-Eigenschaften aufzuerlegen, die sie naturgemäß nicht hat. Dass diese Regeln existieren und von der Branche eher als zusätzliche Kosten denn als Anerkennung zivilrechtlicher Verantwortung empfunden werden, sagt etwas darüber, dass die Software-Produzentinnen Vergänglichkeit als Privileg internalisiert haben. Der Maurer weiß, dass er für seine Mauer viele Jahre einstehen muss. Die Entwicklerin ist daran gewöhnt, für ihren Code bis zum Ablauf der vertraglichen Garantie einzustehen — typischerweise 12 bis 24 Monate. Die zwei Berufsfiguren haben Verantwortungs-Horizonte, die sich um eine Größenordnung unterscheiden — und dieser Unterschied ist in der Sprache, mit der wir sie beschreiben, unsichtbar.

Eine Ethik der Dauer

Zurück zur Ausgangsfrage, warum Software nicht altern kann, nun mit weniger lapidarer Antwort. Sie altert nicht, weil sie aus einem Material gemacht ist, das keine Maserung hat, in einer Umgebung, die schneller läuft als sie, in einer Produktionskultur, die darauf verzichtet hat, Dauer als Wertdimension zu betrachten. Jeder dieser drei Faktoren ist hinreichend, alle drei zusammen machen das Resultat fast unvermeidlich. Der erste ist ontologisch und vermutlich unlösbar: Code wird nie zu Holz. Der zweite ist systemisch und ließe sich abschwächen, wenn die technische Kultur lernte, Stabilität als Qualität statt als Rückständigkeitszeichen zu behandeln. Der dritte ist rein kulturell und das einzige, worauf wir wirklich einwirken können.

Wie? Wahrscheinlich in Richtungen, die die Branche heute regressiv findet. Release-Zyklen verlangsamen. Rückwärtskompatibilität der Eleganz vorziehen. Weniger Code, mehr Spec schreiben. Stabile Schnittstellen wie Monumente behandeln — Objekte, deren Wert in ihrem Widerstand gegen Veränderung liegt. Akzeptieren, dass die Mehrheit des Codes nicht Unix wird, und ihn gerade deshalb mit einem gewissen Bewusstsein seiner Vergänglichkeit schreiben — ohne falschen Dauer-Anspruch und ohne nihilistische Verzweiflung über deren Fehlen. Ein Beruf, der weiß, dass er keine Kathedralen baut, aber sich weigert, Baracken zu errichten. Eine Zwischenwürde, für die wir noch kein gutes Wort haben — und die zu formulieren vielleicht eine der Aufgaben dieser Generation von Technikerinnen ist.

Der Trost, dass Software nicht gut altert, ist, dass diese Eigenschaft uns zwingt, kontrastiv zu schärfen, was Gut-Altern überhaupt heißt. Sie zwingt uns anzuerkennen: die Patina des Aalto-Stuhls ist keine automatische Holz-Eigenschaft, sondern Resultat einer langen Beziehung zwischen einem gut gemachten Objekt, einer stabilen Umgebung, einer aufmerksamen Nutzerin und einer Kultur, die den Wert dieser Triangulation erkennt. Fällt eines weg, bildet sich keine Patina. Im Regen liegen gelassenes Holz bekommt keine Patina, es vermodert. In einem Lager eingesperrtes Holz bekommt keine Patina, es trocknet aus. Patina ist ein kollektives Werk — verlangt Zeit, Pflege, Kontext. Software hat derzeit keines davon, und die Idee, sie könnte sie haben, klingt wie nostalgische Träumerei.

Sie ist keine Träumerei. Sie ist eine Designfrage. Was hieße es, Code zu schreiben in dem Wissen, dass er wie eine Mauer halten soll? Wir wissen es noch nicht wirklich, weil wir es kaum je ernsthaft versucht haben — und wenn, fast immer in Bereichen, die im Vergleich zum Mainstream marginal sind: Avionik, Industriesteuerung, Banken-Legacy — wo Dauer als externe normative Schranke auferlegt ist, nicht als kulturelle Wahl. Zivile Software — die das öffentliche und private Leben der meisten Menschen baut — wurde unter der impliziten Annahme errichtet, Dauer sei nicht ihr Problem. Diese Annahme wird unhaltbar, gerade während die Gesellschaft Software immer vitalere Funktionen überträgt. Unter den Verantwortlichkeiten dieser Generation von Technikerinnen ist das Beginnen, eine Ethik der Dauer für den Beruf zu formulieren, eine der ernsthaftesten und am wenigsten verschiebbaren.

Bleibt am Ende die Grundfrage. Software altert nicht gut. Dieser Satz schien zu Beginn eine technische Klage. Hier angekommen, versteht man: er ist etwas anderes. Eine genaue Beschreibung des Typs Artefakte, den wir kollektiv ins Zentrum unseres gemeinsamen Lebens gestellt haben — und eine implizite Aufforderung, mit dieser Entscheidung Konsequenzen zu ziehen. Die Objekte, die wir ins Zentrum einer Zivilisation stellen, sollten, soweit möglich, sie durch die Zeit begleiten können. Können sie das nicht, müssen wir sie ändern oder den Platz ändern, den sie einnehmen. Bisher haben wir weder das eine noch das andere getan. Wir haben sie das Zentrum besetzen lassen, während sie sich verhalten, als wären sie an der Peripherie, und diesen Zustand „Fortschritt“ genannt. Es lohnt sich, ihn präziser zu nennen.

Der Autor

Andrea MargiovanniHandwerk

Ich schreibe lange genug Software, um sie als Handwerk zu betrachten, nicht als Pipeline. Mich interessiert der Unterschied zwischen einer technischen Wahl und einem geerbten Default, dessen Kosten nie gemessen wurden.

Zum Weg →