Legacy Code

Was ist Legacy Code?

Legacy Code ist der Begriff des Sovereign Systems Design für alte, unpatchte Glaubenssätze und Verhaltensmuster, die auf Basis veralteter Anforderungen geschrieben wurden und trotz veränderter Lebensumstände weiter aktiv sind. Der Begriff stammt aus der Softwareentwicklung, wo Legacy Code Codeteile bezeichnet, die noch funktionieren, aber auf Annahmen basieren, die heute nicht mehr gelten.

Legacy Code ist nicht per se schlecht. Er hat irgendwann funktioniert und war rational. Das Problem entsteht, wenn die Anforderungen sich ändern und der Code nicht mitgewandelt wird — dann produziert er Bugs, die scheinbar aus dem Nichts kommen.

Wie äußert sich das?

Typische Legacy-Code-Muster bei Tech-Leadern:

• Der Gründer, der bei jedem technischen Detail eingreifen muss, weil er in der Startup-Phase alles selbst gemacht hat — das Muster stabilisierte das frühe Unternehmen, killt heute das gewachsene Team.
• Der Manager, der auf jede E-Mail innerhalb von zwei Stunden antwortet, weil er als Junior so seine Sichtbarkeit aufbaute — heute im Senior-Level produziert das permanente Unterbrechung.
• Der Consultant, der jede Anfrage annimmt, weil er in der frühen Karriere Auslastung beweisen musste — heute produziert dieselbe Regel Überlastung und schlechte Kundenauswahl.

Jedes dieser Muster hat in der Kontext-Phase, in der es geschrieben wurde, Sinn gemacht. Die Bugs entstehen durch die Diskrepanz zwischen dem Code und den aktuellen Anforderungen.

Technisches Konzept und Lebens-Architektur

Im Software-Engineering ist die Arbeit mit Legacy Code ein eigenes Fachgebiet. Die Grundregel: Legacy Code wird nicht blind gelöscht und ersetzt — das produziert in der Regel schlimmere Probleme als der bestehende Code. Stattdessen wird er erst verstanden (Was tut er? Warum wurde er so geschrieben? Welche Annahmen stecken dahinter?), dann gezielt refactored, Stück für Stück.

Dasselbe gilt für Legacy Code in der Lebens-Architektur. Das alte Muster hat einen Zweck erfüllt. Es radikal abzuschaffen, ohne zu verstehen, was es getan hat, führt oft zu emotionalen Instabilitäten und Rückfällen. Besser: In der Root Cause Analysis verstehen, wofür das Muster einmal gut war, dann in System Design eine neue Regel formulieren, die den ursprünglichen Zweck in der aktuellen Realität erfüllt, und schließlich in Continuous Deployment iterativ patchen.

In der Praxis

Ein typisches Refactoring eines Legacy-Musters läuft in Stufen: Zuerst wird das Muster identifiziert („Ich antworte immer sofort auf E-Mails"). Dann der ursprüngliche Zweck ermittelt („Sichtbarkeit in einer politischen Konzern-Umgebung"). Dann die aktuelle Anforderung formuliert („Im heutigen Senior-Level brauche ich Deep Work, nicht Sichtbarkeit"). Dann die neue Regel geschrieben („E-Mail-Checks auf zweimal täglich, Antworten innerhalb von 24 Stunden"). Dann iterativ deployed und gepatcht.

Was nicht funktioniert: Das alte Muster zu verurteilen oder sich dafür zu schämen. Legacy Code ist Teil der Lebens-Architektur-Geschichte. Er ist das Zeugnis, dass Anpassungsfähigkeit existierte. Die Frage ist nicht, ob er dumm war, sondern ob er heute noch passt.

Häufige Fragen

Ist Legacy Code dasselbe wie „schlechte Gewohnheiten"? Nein. Schlechte Gewohnheiten sind wertend und suggerieren, das Muster sei immer problematisch gewesen. Legacy Code ist neutral und historisch: Das Muster war einmal rational. Das Framing entscheidet über den Umgang. Wer sich für sein Muster schämt, kämpft dagegen. Wer es als Legacy Code versteht, refactored es.

Kann man Legacy Code einfach löschen? Selten ohne Nebenwirkungen. Ein Muster, das Jahre lang lief, hat sich tief ins System eingeschrieben. Radikales Löschen führt oft zu Vakuum-Effekten (das alte Muster kehrt in veränderter Form zurück, weil kein Ersatz da ist). Refactoring — gezieltes, iteratives Ersetzen durch eine neue Regel — ist robuster.

Wie erkennt man Legacy Code in sich selbst? Über systematische Fragen: Welche Regeln aktiviere ich automatisch, ohne bewusst zu entscheiden? Seit wann habe ich diese Regeln? Was war der Kontext, in dem sie entstanden sind? Gibt es diesen Kontext heute noch? Die Lücke zwischen „damals sinnvoll" und „heute sinnvoll" ist der Legacy-Bereich.