Legacy ist kein Defekt, sondern ein Zustand (1/8)
„Legacy" ist ein soziales Urteil, kein technisches Kriterium — es beschreibt meist nur, dass ein System länger existiert, als die Leute im Raum darüber reden wollen. Alter und Veraltetsein werden routinemäßig verwechselt, obwohl sie nichts miteinander zu tun haben müssen. Die ehrliche Designfrage lautet nicht, wie man Legacy vermeidet, sondern wie man Systeme baut, die diesen Zustand würdig erreichen.
Einleitung
In Meetings fällt das Wort meistens im Nebensatz.
„Das läuft noch auf dem alten System.”
Dann nickt jemand, und das Thema ist entschieden.
„Alt” ist ein Urteil, das keinen Widerspruch erwartet.
Dabei sagt das Wort nichts über Funktion.
Es sagt nur, dass das System länger existiert, als die Leute im Raum darüber reden wollen.
Ein soziales Urteil, kein technisches
Ich habe über viele Jahre mit Systemen gearbeitet, die von Kolleg:innen als Legacy bezeichnet wurden.
Irgendwann hatte ich aufgehört, das für eine technische Kategorie zu halten.
Es ist eine soziale.
Legacy ist, was man nicht mehr verteidigen will,
weil es uncool geworden ist.
Alt ist nicht veraltet
Was „alt” wirklich heißt, ist nicht einheitlich.
- Ein TCP-Stack aus den achtziger Jahren ist alt und vollkommen funktional.
- Eine Angular-Version von 2018 ist alt und praktisch nicht mehr wartbar.
Die beiden haben auf der Kalenderseite gleich viel gemeinsam wie ein achtzigjähriger Baum mit einer acht Jahre alten Smartphone-App.
Und tragen trotzdem dasselbe Etikett.
Wir verwechseln zwei Dinge:
- Alter — eine Tatsache
- Veraltetsein — ein Befund
Ein System kann alt sein und weiterhin tun, wofür es gebaut wurde.
Es kann jung sein und bereits verfehlen, wofür es gedacht war.
Die Branche reagiert fast nur auf das Alter.
Selten auf den Befund.
Die Umkehrung
Was wäre, wenn wir das umdrehen?
Dann wäre Legacy kein Defekt.
Dann wäre es ein Zustand, den ein System erreicht,
weil es lange genug funktioniert hat, um überhaupt beurteilt zu werden.
Systeme, die nie Legacy werden, sind nicht unbedingt besser.
Sie sind oft nur früh genug kaputtgegangen, um diesem Urteil zu entkommen.
Die Designfrage verschiebt sich.
Nicht mehr: Wie vermeide ich Legacy?
Sondern: Wie baue ich etwas, das diesen Zustand würdig erreicht?
Was diese Serie vorhat
Diese Serie beschäftigt sich mit Systemen, die überlebt haben:
- COBOL, das in Banken arbeitet, während die vierte Rewrite-Welle an ihm vorbeizieht
- Modbus, das in Fabriken läuft, in denen die Web-Frameworks der letzten Jahre längst vergessen sind
- SAP, das so tief in Organisationen eingewachsen ist, dass „Ablösung” kein technisches Projekt mehr ist
Und mit dem, was wir daraus lernen können,
wenn wir ehrlich hinschauen.
Meine Position
Ich nehme einen klaren Standpunkt ein.
Nicht jeder Rewrite ist ein Fehler.
Aber die meisten sind Theater.
Nicht jedes alte System muss bleiben.
Aber die Vermutung sollte nicht „weg damit” sein,
sondern „warum läuft das noch?”.
Das ist keine Nostalgie.
Das ist Respekt vor der Tatsache, dass Funktionieren schwieriger ist,
als man es auf Folien aussehen lässt.
Zentrale Beobachtung
Legacy ist kein Defekt.
Legacy ist ein Zustand, den ein System erreicht,
weil es lange genug funktioniert hat,
um überhaupt beurteilt zu werden.
Abschlussgedanke
Vielleicht ist das die ehrlichste Messlatte.
Nicht, ob das System modern wirkt.
Sondern ob die Leute, die es nach uns bedienen,
damit arbeiten können, ohne uns zu hassen.
Legacy wäre dann kein Schimpfwort mehr.
Es wäre eine Auszeichnung.
