Wenn ich in ein Legacy-System einsteige, ist eine der ersten Reaktionen im Team oft eine Mischung aus Scham und Verteidigung. Entwickler entschuldigen sich für Code, den sie selbst geschrieben haben – oder distanzieren sich mit einem Schulterzucken von Code, den sie von anderen übernommen haben. Manchmal läuft beides gleichzeitig ab, je nachdem, wer gerade im Raum ist. Beides hilft nicht.

Wie Legacy-Code wirklich entsteht

Ich habe noch keinen Legacy-Code gesehen, der aus Fahrlässigkeit oder Unwissen entstanden ist. Was ich sehe, sind rationale Entscheidungen unter suboptimalen Bedingungen:

  • Deadlines, die keinen Spielraum für Abstraktion ließen.
  • Anforderungen, die sich nach der Implementierung geändert haben – natürlich ohne dass jemand den Code nochmal angefasst hat.
  • Fehlende Tests, weil damals niemand wusste, wie man sie schreibt, und das Internet dazu noch keine hilfreichen Artikel hatte.
  • Frameworks, die heute als problematisch gelten, damals aber State of the Art waren.
  • Fehlende Dokumentation, weil der Kontext im Kopf der Person steckte, die das Unternehmen verlassen hat – ohne Übergabe, versteht sich.

Legacy-Code ist das Ergebnis von Zeit, Druck und Kontext – nicht von Inkompetenz.

Warum diese Haltung für Modernisierungsprojekte entscheidend ist

Wenn ein Modernisierungsprojekt mit der impliziten Botschaft startet, dass der bisherige Code schlecht war und die bisherigen Entwickler versagt haben, entsteht Widerstand. Menschen verteidigen ihre Arbeit. Das ist menschlich – und in diesem Fall auch verständlich.

Was dagegen funktioniert: Neugier statt Urteil. Die Frage "Warum wurde das so gemacht?" führt fast immer zu einer Antwort, die Sinn ergibt – im damaligen Kontext. Diese Antworten sind Gold: Sie zeigen, welche Constraints damals galten, welche Randfälle berücksichtigt wurden und welches Wissen im Code steckt.

Das Team mitnehmen

Modernisierung gelingt nicht als externer Eingriff von oben. Sie gelingt, wenn das Team Teil der Lösung ist – wenn Entwickler, die den Code kennen, auch an seiner Verbesserung beteiligt sind. Das erfordert eine Kultur, in der es sicher ist, über schlechte Entscheidungen zu sprechen, ohne dass jemand dafür verurteilt wird.

Der Feind von gutem Code ist nicht der schlechte Entwickler. Der Feind ist der Kontext, in dem guter Code nicht entstehen kann.

Was ich in der Praxis tue

Ich beginne Modernisierungsprojekte fast immer mit Gesprächen – nicht mit Code. Wer hat dieses Modul gebaut? Was war der Hintergrund? Welche Probleme sollte es lösen? Diese Gespräche liefern mehr als jede statische Analyse. Und sie schaffen Vertrauen – das Fundament, auf dem jede technische Veränderung erst möglich wird.

Fazit

Legacy-Code entmenschlichen heißt, ihn nicht verstehen zu wollen. Wer die Menschen hinter dem Code versteht, versteht auch den Code besser – und kann ihn gezielter verbessern. Das ist keine weiche These. Es ist die effizienteste Form von Modernisierung, die ich kenne. Und sie kostet nur ein paar ehrliche Gespräche.