Systeme für das Altern entwerfen (8/8)
Systeme, die altern sollen, müssen ohne ihre Autoren funktionieren — das verlangt langlebige Schnittstellen, vorsichtige Versionierung, ehrliche Dokumentation und das bewusste Vermeiden ephemerer Abhängigkeiten. Legacy ist kein Scheitern, sondern Erfolg, der lange genug angehalten hat, um außer Mode zu kommen. Die Frage beim nächsten Projekt lautet nicht „wird das modern sein?", sondern „kann ich mir vorstellen, dass das in zwanzig Jahren noch läuft, ohne dass mich jemand dafür verflucht?".
Einleitung
Die Serie bis hierher in einem Absatz:
- Legacy ist ein Zustand, den ein System erreicht, weil es lange genug funktioniert hat, um beurteilt zu werden.
- Systeme wie COBOL, Modbus und SAP überleben nicht aus Trägheit, sondern weil ihr Umfeld Austausch bestraft.
- Ablöseprojekte scheitern nicht an der Technik, sondern an der Unterschätzung dessen, was diese Systeme tun.
- Ehrliche Strategien existieren — Strangler Fig, Anti-Corruption Layer, Parallel Run. Sie sind langsam und unspektakulär.
- Langlebige Systeme sind textlich, klar begrenzt, rückwärtskompatibel, semantisch bescheiden, institutionell eingebettet.
Bleibt die Frage, die am Anfang stand:
Wie baue ich etwas, das überleben darf?
Ohne die Autoren funktionieren
Die ehrliche Antwort beginnt damit, eine Erwartung loszulassen.
Die Erwartung, dass ein System auf seine Schöpfer zurückverweist.
Systeme, die lange bleiben, lassen sich von Leuten bedienen,
die nie etwas von denen gehört haben, die sie gebaut haben.
Das klingt offensichtlich.
Es ist es trotzdem nicht.
Viel Software ist so geschrieben, dass sie ohne die Konventionen, Running Jokes und stillschweigenden Annahmen des ursprünglichen Teams kaum zu lesen ist.
Ein System, das altern soll, muss ohne seine Autoren funktionieren.
Langlebige Schnittstelle, flexible Implementierung
Was nach außen gesehen wird, darf sich fast nicht ändern.
Was innen passiert, kann sich beliebig entwickeln.
HTTP/1.1 ist im Kern seit 1997 dieselbe Schnittstelle.
Die Server, die sie bedienen, haben mit dem damaligen Stand wenig gemein.
Das war das Beispiel, an dem ich meine eigene Arbeit zu messen versucht habe.
Versionen sichtbar, nicht zur Last
Eine Schnittstelle ohne Versionsangabe bricht irgendwann lautlos.
Eine Schnittstelle mit einer Major-Version pro Änderung wird zum Flickenteppich.
Die Disziplin liegt dazwischen:
- wenige Brüche
- ernsthaft begründet
- dokumentiert
- mit klaren Übergängen
Dokumentation, die man gesucht hätte
Der ehrlichste Test ist nicht die technische Referenz.
Die Frage lautet:
Was hätte mir beim Einstieg geholfen, diesen Code in einer Stunde zu verstehen?
Dieses Dokument schreiben.
Dann feststellen, dass es die Hälfte der Codekommentare überflüssig macht.
Das Ephemere vermeiden
Jede Abhängigkeit, die nicht Teil eines Ökosystems mit Langzeitgarantie ist,
ist eine Wette auf ihren Betreiber.
Manchmal muss man diese Wette eingehen.
Man sollte sie bewusst eingehen.
Ein Framework, das 2020 populär war und 2025 aufgegeben wurde,
hat nicht nur fünf Jahre Funktionen geliefert.
Es hat auch eine Rechnung hinterlassen, die später bezahlt wird.
Mit der eigenen Abwesenheit rechnen
Irgendwann wird niemand dieses System mehr warten:
- Weil man das Unternehmen verlassen hat.
- Weil das Projekt Teams gewechselt hat.
- Weil man in Rente gegangen ist.
- Weil man nicht mehr lebt.
Systeme, die das einplanen, sehen anders aus als Systeme, die es verdrängen.
Sie sind erklärender.
Zugänglicher.
Weniger abhängig von Anekdoten, die nur im Kaffeeküchengespräch zu haben sind.
Zentrale Beobachtung
Die Systeme, die in dieser Serie betrachtet wurden, sind nicht durch spektakuläre Entscheidungen langlebig geworden.
Sie sind langlebig, weil ihre Erbauer an den richtigen Stellen nicht interessant sein wollten.
Sie haben auf Komplexität verzichtet, wo sie keinen proportionalen Nutzen brachte.
Sie haben Schnittstellen so langweilig wie möglich gehalten.
Sie haben dokumentiert, was sonst verloren gegangen wäre.
Abschlussgedanke
Ich habe in einem früheren Text geschrieben:
Technology that assumes change will outlive technology that doesn’t.
Das stimmt, und es ist nur eine Seite.
Die andere Seite lautet:
Technologie, die davon ausgeht, irgendwann alleine gelassen zu werden,
überlebt die, die das nicht tut.
Legacy ist kein Scheitern.
Legacy ist Erfolg, der lange genug angehalten hat, um außer Mode zu kommen.
Das sollte keine Beleidigung sein.
Das sollte die Auszeichnung sein, die wir unseren besten Systemen geben.
Am Ende war die Frage, die ich mir bei jedem neuen Projekt gestellt habe, nicht mehr:
„Wird das modern sein?”
Sie war geworden:
„Kann ich mir vorstellen, dass das in zwanzig Jahren noch läuft, von Leuten bedient, die mich nie getroffen haben, und dass die mit mir nicht schimpfen?”
Wenn ich das ehrlich mit Ja beantworten konnte,
war das ein Anfang.
