Wann ein Rewrite die falsche Entscheidung ist

Es gibt einen Moment in fast jedem gewachsenen System, in dem der Gedanke unwiderstehlich wird: Werfen wir das alte weg und bauen es richtig neu. Der Code ist unübersichtlich, die Entscheidungen von damals wirken falsch, jede Änderung fühlt sich mühsam an — und der Neubau verspricht einen sauberen Anfang, ohne die Altlast, mit den heutigen Werkzeugen. Kaum ein Vorschlag ist so verlockend, und kaum einer scheitert so zuverlässig. Dieses Dokument handelt davon, warum das so ist — und wann der Neubau trotz allem die richtige Entscheidung ist.

Es ist ein Dokument über Zurückhaltung. Ein Softwarehaus, das an einem Neubau verdient, rät hier oft davon ab, und genau das macht den Rat glaubwürdig: Die ehrliche Antwort auf „sollen wir neu bauen?" ist meistens nein, und wer das nur sagt, wenn es dem eigenen Geschäft nützt, ist kein verlässlicher Ratgeber. Der Text nennt kein Werkzeug und keine Zahl; er beschreibt, was ein Rewrite wirklich kostet, was er wegwirft, und die wenigen Fälle, in denen er dennoch der richtige Weg ist.

1. Warum der Rewrite so verlockend ist

Der Reiz des Neubaus speist sich aus einer echten Erfahrung: Das bestehende System ist unangenehm. Man liest fremden oder eigenen alten Code, versteht die Entscheidungen nicht mehr, stößt auf Verwicklungen, die niemand mehr erklären kann, und jede Änderung fühlt sich an wie ein Eingriff in ein Uhrwerk, dessen Federn man nicht kennt. Dagegen steht das Bild des Neubaus: ein leeres Blatt, die heutigen Werkzeuge, die Freiheit, es diesmal richtig zu machen. Die Rechnung scheint einfach — das Alte ist schwer, das Neue wäre leicht.

Diese Rechnung ist verführerisch, weil sie einen realen Schmerz gegen eine imaginierte Leichtigkeit stellt. Der Schmerz des Alten ist konkret und täglich spürbar; die Leichtigkeit des Neuen ist eine Vorstellung, die noch keine Berührung mit der Wirklichkeit hatte. Man vergleicht ein System, das alle Kompromisse der Realität trägt, mit einem, das noch keinen einzigen gemacht hat — und übersieht, dass das neue System dieselben Kompromisse machen wird, sobald es der Wirklichkeit begegnet. Der Reiz des Rewrites ist der Reiz des Unbelasteten, und das Unbelastete bleibt es nur, solange es nicht existiert.

Trade-off. Dem Reiz zu widerstehen bedeutet, den täglichen Schmerz des Alten weiter zu tragen, statt der Verheißung des Neuen zu folgen — das ist unbequem und fühlt sich nach Stillstand an.

Kosten. Zurückhaltung verlangt, das unangenehme System zu verbessern, statt es zu ersetzen — mühsamere, weniger befriedigende Arbeit als der Neuanfang.

Wann wir anders entscheiden. Wo das Alte nicht nur unangenehm, sondern grundlegend falsch gebaut ist (siehe Kapitel 5), ist der Reiz kein Trugbild, sondern ein Signal — dann folgt man ihm mit Bedacht.

2. Was ein Rewrite wirklich wegwirft

Ein bestehendes System ist mehr als sein Code — es ist verdichtetes Wissen. Jede seltsame Verzweigung, jede Sonderbehandlung, jeder Kommentar, der nach einem vergessenen Vorfall klingt, ist die Spur einer Erfahrung: eines Fehlers, der einmal auftrat und behoben wurde, eines Grenzfalls, den die Wirklichkeit einforderte, einer Anforderung, die niemand mehr dokumentiert hat, die aber jemand braucht. Dieses Wissen ist unsichtbar, solange das System läuft — und es ist genau das, was ein Rewrite wegwirft.

Der Neubau beginnt mit einem sauberen Modell der Anforderungen, wie man sie heute versteht — und dieses Verständnis ist immer unvollständig, weil das alte System Jahre gebraucht hat, um die Ausnahmen zu sammeln, die es heute korrekt behandelt. Das neue System wird diese Ausnahmen nicht kennen, bis es dieselben Fehler noch einmal macht, dieselben Vorfälle noch einmal erlebt, dieselben Grenzfälle noch einmal schmerzhaft lernt. Was aussah wie unordentlicher Code, war oft hart erarbeitete Korrektheit. Ein Rewrite tauscht ein System, das die Ausnahmen kennt, gegen eines, das sie erst wieder lernen muss — und diesen Preis zahlt man nicht im Code, sondern in Ausfällen.

Trade-off. Auf das eingebettete Wissen zu verzichten kauft einen sauberen Anfang mit dem Verlust dessen, was das alte System über Jahre gelernt hat.

Kosten. Das verlorene Wissen kehrt als Reihe von Vorfällen zurück — das neue System lernt die Ausnahmen noch einmal, diesmal in Produktion und vor den Augen der Nutzer.

Wann wir anders entscheiden. Wo das eingebettete Wissen des alten Systems gering oder ohnehin falsch ist — ein junges System, ein grundlegend fehlerhaftes —, wiegt sein Verlust wenig, und der Neubau verliert seinen Schrecken.

3. Der zweite System-Effekt

Es gibt eine wiederkehrende Ironie beim Neubau: Das zweite System, das ein Team baut, ist oft schlechter als das erste, nicht besser. Befreit von den Zwängen des Alten und getrieben von dem Wunsch, es diesmal richtig zu machen, neigt der Neubau dazu, zu viel zu wollen — jede Idee einzubauen, die im alten System fehlte, jede Flexibilität vorzusehen, die man sich einmal gewünscht hatte, jede Abstraktion zu ziehen, die eleganter wirkt. So entsteht nicht das schlanke, saubere System, das man sich vorgestellt hatte, sondern ein neues, das an seiner eigenen Ambition schwer wird.

Der Grund ist psychologisch so vorhersehbar wie technisch. Das alte System war unter Druck und mit begrenztem Wissen entstanden und trägt deshalb eine gewisse Schlichtheit — es tut, was nötig war. Der Neubau entsteht aus Frust über das Alte und aus dem Glauben, es besser zu wissen, und diese Haltung verführt zur Übererfüllung. Man baut nicht das Nötige neu, sondern das Gewünschte — und das Gewünschte ist immer mehr, als man braucht. Die vorzeitige Abstraktion, die überkonstruierte Flexibilität, die Komplexität ohne Anlass: Der Neubau ist ihr natürlicher Nährboden. Was als schlankeres System gedacht war, wird so oft ein komplexeres — nur mit neuerem Code und ohne die stille Reife des alten, das seine Komplexität wenigstens teuer verdient hatte.

Trade-off. Den zweiten System-Effekt zu vermeiden verlangt eine Disziplin im Neubau, die dem befreienden Gefühl des leeren Blatts zuwiderläuft.

Kosten. Diese Disziplin nimmt dem Neubau gerade den Reiz, der ihn attraktiv machte — das Recht, endlich alles einzubauen, was man sich gewünscht hat.

Wann wir anders entscheiden. Ein erfahrenes Team, das den Effekt kennt und sich bewusst zur Schlichtheit zwingt, kann ihn eindämmen; wo diese Reife fehlt, ist der Effekt fast unausweichlich und der Neubau umso riskanter.

4. Das laufende System ist ein bewegliches Ziel

Der praktische Grund, warum Rewrites so oft scheitern, ist einfach: Das alte System steht nicht still, während man das neue baut. Es läuft weiter, es trägt das Geschäft, und es muss weiter gepflegt und erweitert werden — jede dringende Anforderung, jeder neue Grenzfall, jede Korrektur, die in dieser Zeit anfällt, wird in das alte System eingebaut. Das neue System, das man auf den Stand des alten bringen will, jagt damit einem Ziel hinterher, das sich bewegt. Kaum hat es aufgeholt, ist das alte schon weiter.

Schema: Während der Neubau aufholt, entwickelt sich das alte System weiter. Man jagt ein bewegliches Ziel — und in der langen Zwischenzeit betreibt man zwei Systeme statt einem.

Besonders tückisch ist, dass der Neubau sich fast fertig anfühlt, lange bevor er es ist. Die sichtbaren, häufigen Fälle sind schnell nachgebaut und erwecken den Eindruck, das Meiste sei geschafft. Was fehlt, sind gerade die seltenen Ausnahmen und Grenzfälle — jene, die das alte System über Jahre gesammelt hat und die den größten Teil seiner wahren Komplexität ausmachen. So steht der Neubau oft lange bei scheinbar fast fertig, während der mühsamste Rest noch aussteht. Diese Kluft zwischen gefühltem und tatsächlichem Fortschritt ist einer der Hauptgründe, warum Rewrites ihre Frist und ihr Budget so verlässlich überschreiten — und warum die Zwischenzeit länger dauert, als jeder Plan vorsah.

Diese lange Zwischenzeit ist der eigentliche Preis. Solange der Neubau nicht fertig ist — und er dauert fast immer länger als geplant —, betreibt und pflegt man zwei Systeme: das alte, das läuft, und das neue, das noch nicht kann. Die Kräfte, die man für die eigentliche Weiterentwicklung bräuchte, sind gebunden, und das Geschäft steht still, obwohl viel gearbeitet wird. Genau in dieser Phase verlieren die meisten Rewrites das Vertrauen, das sie zum Abschluss bräuchten.

Trade-off. Die schrittweise Alternative vermeidet das bewegliche Ziel, kauft das aber mit einem langsameren, weniger sichtbaren Fortschritt statt eines großen Neubeginns.

Kosten. Ein Rewrite bindet über seine gesamte, meist unterschätzte Dauer die Kräfte für zwei Systeme und legt die eigentliche Weiterentwicklung lahm.

Wann wir anders entscheiden. Wo das alte System eingefroren werden kann — keine neuen Anforderungen mehr, nur noch Erhalt —, entfällt das bewegliche Ziel, und ein Neubau wird beherrschbarer.

5. Wann ein Rewrite doch richtig ist

Dieses Dokument ist keine Absage an jeden Neubau, sondern an den Neubau aus Frust. Es gibt Fälle, in denen der Rewrite die richtige Entscheidung ist — und sie haben ein gemeinsames Merkmal: Das Fundament des alten Systems ist grundlegend falsch, nicht nur unangenehm. Wenn die tragende Struktur eine Anforderung, die heute zentral ist, prinzipiell nicht erfüllen kann; wenn die zugrunde liegende Technik am Ende ihres Weges steht und keine Zukunft mehr hat; wenn die Kosten, das Alte weiterzuentwickeln, die eines Neubaus über die absehbare Lebensdauer übersteigen — dann ist der Neubau nicht Flucht, sondern die nüchterne Antwort.

Der Unterschied liegt zwischen „das Alte ist schwer zu ändern" und „das Alte kann nicht werden, was es sein muss". Das Erste ist ein Grund zu modernisieren; das Zweite ist ein Grund, neu zu bauen. Die ehrliche Prüfung fragt deshalb nicht, ob das alte System unangenehm ist — das sind fast alle gewachsenen Systeme —, sondern ob sein Kern das tragen kann, was künftig verlangt wird. Lautet die Antwort ja, ist der Rewrite fast immer der teurere Weg zum selben Ziel. Lautet sie nein, ist er der einzige Weg, und dann geht man ihn bewusst und mit offenen Augen für seinen Preis.

Trade-off. Den Neubau nur beim grundlegend falschen Fundament zu wählen bedeutet, viele unangenehme Systeme weiter zu ertragen — gegen den Gewinn, die seltene richtige Neubauentscheidung von der häufigen falschen zu trennen.

Kosten. Die ehrliche Prüfung verlangt, den eigenen Frust vom sachlichen Befund zu trennen — eine Selbstdisziplin, die im Ärger über das Alte schwerfällt.

Wann wir anders entscheiden. Ist der Befund eindeutig — totes Fundament, unerfüllbare Kernanforderung —, zögert man nicht aus Prinzip; die Zurückhaltung gilt dem Neubau aus Unbehagen, nicht dem aus sachlicher Notwendigkeit.

6. Die Alternative: schrittweise ersetzen

Fast immer gibt es einen dritten Weg zwischen „so weitermachen" und „alles neu bauen": das Alte schrittweise ersetzen, Stück für Stück, während es läuft. Man löst einen Teil heraus, baut ihn neu, schaltet um, und das System bleibt die ganze Zeit funktionsfähig. So bekommt man die Erneuerung ohne die lange, riskante Zwischenzeit des großen Neubaus, ohne das bewegliche Ziel und ohne den Totalverlust des eingebetteten Wissens — denn man ersetzt nur, was man verstanden hat, und behält den Rest, bis er an der Reihe ist.

Schema: Der große Neubau trägt sein Risiko gebündelt am Ende; die schrittweise Ablösung verteilt es auf viele kleine Umschaltungen, von denen keine das ganze System gefährdet.

Dieser Weg ist weniger befriedigend als der große Neubeginn, weil er keinen sauberen Bruch bietet und keinen Tag, an dem alles neu ist. Genau das ist seine Stärke: Er hat zu keinem Zeitpunkt das Risiko, das ganze System zu verlieren, weil er es zu keinem Zeitpunkt ganz ersetzt. Wer die Verlockung des Rewrites spürt, aber seinen Preis kennt, findet in der schrittweisen Ablösung meist das, was er wirklich wollte — ein besseres System — ohne das, was er nicht wollte — das Risiko, es dabei zu verlieren. Wie dieser Weg konkret aussieht, behandelt die Modernisierung ohne Big Bang.

Trade-off. Die schrittweise Ablösung kauft Sicherheit und Weiterbetrieb mit einem langsameren, weniger sichtbaren Fortschritt und dem Verzicht auf den sauberen Bruch.

Kosten. Man muss eine Zeit lang mit einem System leben, das halb alt und halb neu ist, und die Grenze zwischen beidem sorgfältig pflegen.

Wann wir anders entscheiden. Wo sich ein System nicht sinnvoll in ersetzbare Teile zerlegen lässt und sein Kern ohnehin neu muss, ist der schrittweise Weg künstlich; dann ist der bewusste Neubau ehrlicher.

7. Typische Fehler

Die wiederkehrenden Muster, an denen die Rewrite-Entscheidung scheitert — fast alle sind Varianten davon, Frust für einen Grund zu halten:

• Neu bauen, weil das Alte unangenehm ist, ohne zu prüfen, ob sein Kern das Künftige tragen kann.
• Das eingebettete Wissen des alten Systems übersehen und die hart erarbeiteten Ausnahmen als unordentlichen Code abtun.
• Das saubere, unbelastete neue System mit dem kompromissbeladenen alten vergleichen — und vergessen, dass das neue dieselben Kompromisse noch machen wird.
• Dem zweiten System-Effekt erliegen und in den Neubau alles einbauen, was im Alten fehlte, bis er an seiner Ambition schwer wird.
• Das bewegliche Ziel unterschätzen und übersehen, dass das alte System weiterläuft und sich ändert, während man das neue baut.
• Die Dauer des Neubaus unterschätzen und über die lange Zwischenzeit die Kräfte für zwei Systeme binden.
• Die schrittweise Alternative übersehen und die Wahl auf „so weiter" oder „alles neu" verengen.
• Aus dem seltenen richtigen Neubau eine Regel machen — oder aus der häufigen falschen ein Dogma gegen jeden Neubau.

8. Entscheidungs-Checkliste

Vor der Entscheidung für einen Rewrite der Reihe nach zu klären:

• Unangenehm oder unmöglich? Ist das alte System nur schwer zu ändern — oder kann sein Kern prinzipiell nicht werden, was er sein muss?
• Technik zukunftsfähig? Steht die zugrunde liegende Technik am Ende ihres Wegs, oder trägt sie noch?
• Eingebettetes Wissen bedacht? Ist klar, welche über Jahre gesammelten Ausnahmen ein Neubau erst wieder lernen müsste?
• Zweiter System-Effekt? Hat das Team die Disziplin, das Nötige neu zu bauen statt des Gewünschten?
• Bewegliches Ziel? Kann das alte System eingefroren werden — oder läuft es weiter und ändert sich, während man baut?
• Dauer und Doppelbetrieb? Sind die meist unterschätzte Dauer und die Last, zwei Systeme zu betreiben, ehrlich eingerechnet?
• Schrittweise geprüft? Lässt sich das System Stück für Stück ersetzen, statt alles auf einmal?
• Frust oder Befund? Beruht die Entscheidung auf einem sachlichen Befund über den Kern — oder auf dem Ärger über das Alte?

Wer diese Fragen beantworten kann, hat die seltene richtige Neubauentscheidung von der häufigen falschen getrennt — und weiß, ob er baut oder besser modernisiert.

FAQ

Warum raten Sie von etwas ab, an dem Sie verdienen würden? Weil ein Rat nur so viel wert ist wie die Bereitschaft, ihn gegen das eigene Interesse zu geben. Ein Rewrite ist teuer und für ein Softwarehaus einträglich — und meistens die falsche Wahl. Wer das nur sagt, wenn es ihm nützt, ist kein verlässlicher Ratgeber. Die ehrliche Antwort auf „sollen wir neu bauen?" ist meistens nein, und die sagen wir auch dann, wenn ja mehr Umsatz brächte.

Ist unordentlicher Code nicht ein guter Grund, neu zu bauen? Selten. Was wie unordentlicher Code aussieht, ist in einem gewachsenen System oft hart erarbeitete Korrektheit — die Spur von Fehlern, die schon behoben, und Grenzfällen, die schon gelernt wurden. Ein Neubau wirft dieses Wissen weg und muss es in Produktion neu lernen. Unordnung ist ein Grund aufzuräumen, selten ein Grund neu zu bauen.

Wann ist ein Rewrite tatsächlich richtig? Wenn das Fundament grundlegend falsch ist, nicht nur unangenehm: wenn der Kern eine heute zentrale Anforderung prinzipiell nicht erfüllen kann, die Technik am Ende ihres Wegs steht, oder die Kosten des Erhalts die des Neubaus über die Lebensdauer übersteigen. Der Unterschied ist „schwer zu ändern" gegen „kann nicht werden, was es sein muss".

Was ist der zweite System-Effekt? Die Neigung, das zweite System schlechter zu machen als das erste — überladen mit jeder Idee, die im alten fehlte, jeder Flexibilität, die man sich gewünscht hatte. Befreit vom Zwang und getrieben vom Wunsch, es richtig zu machen, baut der Neubau oft nicht das Nötige, sondern das Gewünschte, und wird an seiner Ambition schwer.

Warum scheitern Rewrites so oft mitten im Projekt? Weil das alte System weiterläuft und sich ändert, während man das neue baut — ein bewegliches Ziel, das der Neubau nie ganz einholt. In der langen, meist unterschätzten Zwischenzeit betreibt man zwei Systeme und legt die eigentliche Weiterentwicklung lahm. Genau dort verlieren die meisten Rewrites das Vertrauen, das sie zum Abschluss bräuchten.

Was ist die Alternative? Das Alte schrittweise ersetzen, Stück für Stück, während es läuft — die Modernisierung ohne Big Bang. Man bekommt die Erneuerung ohne die riskante Zwischenzeit, ohne das bewegliche Ziel und ohne den Totalverlust des eingebetteten Wissens, weil man nur ersetzt, was man verstanden hat. Meist ist das genau das, was man wollte, ohne das Risiko, das man nicht wollte.

Weiterführend

• Legacy-Modernisierung ohne Big Bang — die Alternative zum Rewrite: schrittweise ersetzen, während das System läuft.
• Ein Legacy-System übernehmen — die ersten 90 Tage — erst verstehen, was man zu ersetzen erwägt.
• Warum Softwareprojekte wirklich scheitern — warum der große Neubau eine besonders unumkehrbare Wette ist.
• Realtime ohne Neubau — eine moderne Anforderung ohne Rewrite integriert.

Grundlage ist die Batunet Engineering Method: das Bestehende verstehen, in kleinen umkehrbaren Schritten erneuern, den Neubau nur beim grundlegend falschen Fundament wählen.

Abschließendes Engineering-Prinzip

Der Wunsch, neu zu bauen, ist fast immer der Wunsch, den Schmerz des Verstehens zu vermeiden — und genau deshalb führt er in die Irre. Ein bestehendes System zu verstehen ist mühsam; es wegzuwerfen und neu zu beginnen fühlt sich wie Befreiung an. Aber die Befreiung ist eine Illusion: Das neue System erbt dieselbe Wirklichkeit, macht dieselben Kompromisse und lernt dieselben Ausnahmen — nur ohne das Wissen, das das alte sich teuer erworben hatte. Die reifste Entscheidung ist deshalb meistens, das Unangenehme zu verbessern statt es zu ersetzen, und den Neubau der seltenen Lage vorzubehalten, in der der Kern wirklich nicht tragen kann. Wer neu baut, weil das Alte schwer ist, tauscht ein bekanntes Problem gegen ein unbekanntes — und zahlt für den Tausch mit dem, was er schon wusste.

Ein Rewrite verspricht, den Schmerz des Alten hinter sich zu lassen. Er lässt nur das Wissen zurück — und nimmt den Schmerz noch einmal mit, diesmal ohne die Lektionen, die ihn erträglich gemacht hatten.