"Sollten wir das nicht einfach neu bauen?" – Diese Frage taucht in fast jedem Modernisierungsprojekt irgendwann auf, meistens nach dem dritten unerklärlichen Bug in der gleichen Woche. Oft kommt sie von Entwicklern, die den Code täglich anfassen und kurz vor der inneren Kündigung stehen. Manchmal von Führungskräften, die gehört haben, dass ein Neubau "sauberer" wird – und die das Wort "sauber" für eine konkrete technische Spezifikation halten.

Warum der Neubau so verlockend wirkt

Ein leeres Repository ist verführerisch. Keine alten Entscheidungen, keine verschlungenen Abhängigkeiten, kein Ballast. Das Team kann "es diesmal richtig machen". Dieses Gefühl ist menschlich – und fast immer eine Falle.

Joel Spolsky nannte es den schlimmsten strategischen Fehler, den ein Unternehmen machen kann: die funktionierende Software wegzuwerfen. Der bestehende Code, so unschön er auch ist, enthält Jahre von Domänenwissen, Bug-Fixes und Randfallbehandlungen, die nirgendwo dokumentiert sind. Dieser Wissen verschwindet beim Neubau – und taucht sechs Monate später als mysteriöser Bug im neuen System wieder auf.

Vier Kriterien, die ich zur Entscheidung heranziehe

1. Wie viel Domänenwissen steckt im Code?

Systeme, die komplexe Fachlogik abbilden – Versicherungsberechnungen, ERP-Prozesse, branchenspezifische Regeln – sollten selten neu gebaut werden. Das Wissen lässt sich nicht einfach in ein Pflichtenheft übersetzen. Es steckt in tausend kleinen Entscheidungen, die niemand mehr erklären kann, und die trotzdem alle einen Grund haben.

2. Gibt es ausreichend Testabdeckung?

Ohne Tests ist Refactoring riskant – aber ein Neubau ohne Tests ist es noch mehr. Wenn ein System gut getestet ist, lässt sich fast alles schrittweise umbauen. Wenn nicht, ist der erste Schritt Testabdeckung schaffen, nicht neu bauen.

3. Ist das Team in der Lage, parallel zu liefern?

Ein Neubau dauert. Während das neue System entsteht, muss das alte weiterleben, Bugs bekommen, Features liefern. Das bindet erhebliche Kapazität. Viele Teams unterschätzen diesen Parallelbetrieb – und laufen in den klassischen zweiten Systemeffekt: Das neue System wird nie fertig, das alte wird nie abgeschaltet, und irgendwann hat man zwei halbfertige Systeme statt einem schlechten.

4. Sind die Kernprobleme technischer oder fachlicher Natur?

Wenn das System langsam, schwer wartbar und unstrukturiert ist: Refactoring. Wenn das Datenmodell fundamental falsch ist, die Architektur das Geschäftsmodell nicht mehr trägt oder das System schlicht die falschen Dinge tut: dann kann ein Neubau die richtige Entscheidung sein.

Der Mittelweg: selektiver Neubau

Meistens ist die Antwort weder "alles neu" noch "alles behalten". Das Strangler Fig Pattern bietet einen Mittelweg: Neue Funktionalität wird im neuen System gebaut, das alte wird schrittweise abgelöst, Modul für Modul, ohne einen Big-Bang-Schnitt.

Die Frage ist nicht "Rebuild oder Refactor?" – die Frage ist, welche Teile des Systems es wert sind, bewahrt zu werden, und welche nicht.

Fazit

Es gibt keine universelle Antwort. Aber es gibt eine Methode: Erst verstehen, dann entscheiden. Wer vor der Entscheidung eine sorgfältige Analyse macht – Komplexität, Testabdeckung, Domänenwissen, Teamkapazität – trifft die richtige Wahl öfter als derjenige, der aus Frustration heraus neu baut. Frustration ist ein schlechter Architekt.