Warum Legacy nicht das Problem ist

Narben

Als Student habe ich einmal ein paar Tage bei einem Stuckateur gearbeitet. Schmutzige Arbeit. Staub ueberall.

Der Meister hatte Haende voller Hornhaut und Narben. Spuren vieler kleiner Unfaelle und Fehler, die im Laufe eines Arbeitslebens passieren.

Aber was er mit diesen Haenden schuf, war beeindruckend.

Mit einfachen Schablonen – manchmal auch freihaendig – formte er Stuck, der nahezu perfekt aussah.

Damals dachte ich: Diese Haende sind kaputt.

Heute denke ich anders darueber.

Diese Haende waren nicht kaputt. Sie waren erfahren.

Jede Narbe erzaehlte von einem Problem, das einmal geloest werden musste.

Wer ein Legacy-System liest, stoesst schnell auf Stellen, die Fragen aufwerfen.

Workarounds. Seltsame Datenstrukturen. Entscheidungen, die auf den ersten Blick keinen Sinn ergeben.

Viele nennen das technische Schulden.

Aber oft sind es einfach Narben.

Spuren realer Probleme, die irgendwann geloest werden mussten.

Software entsteht nicht im Lehrbuch.

Sie entsteht in der Realitaet von Unternehmen:

Ein Legacy-System ist deshalb mehr als alter Code.

Es ist ein Archiv von Entscheidungen.

Es enthaelt Wissen ueber Prozesse und Ablaeufe, das sich ueber Jahre aufgebaut hat.

Viele Projekte beginnen mit der falschen Frage:

„Wie ersetzen wir dieses System?”

Die wichtigere Frage waere:

„Warum ist dieses System so geworden, wie es ist?”

Wenn dieses Verstaendnis fehlt, wird beim Neubau nicht nur Technologie ersetzt.

Oft geht auch Wissen verloren.

Modernisierung bedeutet deshalb nicht, Legacy zu zerstoeren.

Modernisierung bedeutet zuerst:

Welche Prozesse traegt das System? Welche Entscheidungen sind darin verborgen?

Erst danach kann man sinnvoll modernisieren.

Schritt fuer Schritt.

Legacy ist kein Zeichen von Rueckstand.

Legacy ist ein Zeichen dafuer, dass ein System lange genug ueberlebt hat, um wichtig zu werden.

Die Aufgabe guter Architektur ist deshalb nicht, Legacy loszuwerden.

Die Aufgabe guter Architektur ist es, Legacy zu verstehen.