Devtide Ltd. Devtide Ltd.

Was ich CTOs sage, die neu schreiben wollen

Vier Fragen, die CTOs stellen sollten, bevor sie einen Rewrite absegnen, plus die günstigeren Alternativen, die das eigentliche Problem meistens lösen.

14 Min. Lesezeit
Ein großer, verwitterter roter Notfall-Knopf auf einer Metallplatte mit gelb-schwarzen Gefahrenstreifen, stellvertretend für die Nicht-drücken-Nuklearoption, die ein vollständiger Rewrite meistens ist

Jeden Monat, manchmal zweimal im Monat, ruft mich ein CTO oder VP of Engineering an, und das Gespräch läuft immer gleich ab. Das Produkt funktioniert. Die Kunden zahlen. Der Code ist ein Chaos. Das Team ist unzufrieden. Die Führung ist widerwillig, aber fest zu dem Schluss gekommen, dass ein Rewrite der einzige Weg nach vorn ist. Sie wollen, dass ich den Plan validiere, ihnen beim Scoping helfe und vielleicht die erste Phase übernehme.

Am Ende des Gesprächs habe ich ihnen fast immer davon abgeraten. Nicht weil Rewrites immer falsch sind (manchmal gelingen sie spektakulär), sondern weil die Gründe, aus denen dieses konkrete Team neu schreiben will, fast nie die Gründe sind, die ein Rewrite tatsächlich lösen würde. Der Rewrite ist ein Symptom, keine Lösung. Das ist kein neuer Standpunkt, das ist alter Rat: Joel Spolsky nannte den Neubau von Grund auf schon im Jahr 2000 den schlimmsten strategischen Fehler, den eine Softwarefirma machen kann, und die Arithmetik hat sich seither kaum geändert. Was Teams tatsächlich brauchen, ist etwas Günstigeres, Schnelleres und weniger Riskantes, was sie meist gar nicht erwogen haben, weil es weniger aufregend ist.

In diesem Essay stehen die vier Fragen, die ich in solchen Gesprächen stelle. Keine Abhandlung gegen Rewrites. Eine Diagnose, um herauszufinden, ob der Rewrite tatsächlich die Antwort ist oder eine prestigeträchtige Ablenkung von der Antwort.

Warum dieses Gespräch immer wieder stattfindet

Vor den Fragen das Muster. Rewrites werden in Gesprächen vorgeschlagen, die so klingen:

“Die Codebasis ist zehn Jahre alt. Das ursprüngliche Team ist weg. Jedes neue Feature dauert dreimal so lange, wie es sollte. Unsere Senior-Engineers weigern sich, am Legacy-Modul zu arbeiten. Letztes Jahr haben wir ein Refactoring versucht, es hat nicht gegriffen. Wir glauben, wir müssen in den sauren Apfel beißen und auf [neuem Framework / neuer Sprache / neuer Architektur] neu bauen.”

Jeder Satz dieses Absatzes ist wahr, in dem Sinne, dass jeder ein reales Problem beschreibt, das der CTO sieht. Der Absatz als Ganzes ist auch eine Falle, weil er ein halbes Dutzend unterschiedlicher Probleme in eine einzige Schlussfolgerung (“Rewrite”) zusammenpresst, ohne zu prüfen, ob eines dieser Einzelprobleme tatsächlich einen Rewrite zum Beheben braucht.

Der CTO will meistens gar keinen Rewrite. Er will, dass die Symptome verschwinden. Der Rewrite ist die Erzählung, auf die sich das Team geeinigt hat, weil sie konkret und handlungsleitend und emotional befriedigend ist, auf eine Weise, wie “die schmerzhafte Arbeit der inkrementellen Verbesserung fortsetzen” es nicht ist. Wenn ich frage, was konkret kaputt ist, sind die Symptome meistens Dinge, die eine Strangler-Fig-Migration, ein gezieltes Refactoring, eine Personalentscheidung oder eine Prozessänderung zu einem Zehntel der Kosten beheben würden.

Also stelle ich die vier Fragen. Und fast immer stelle ich fest, dass die Symptome gar nicht auf den Rewrite als richtige Intervention hindeuten.

Frage 1: Was genau ist kaputt, in Worten, die das Board versteht?

Ich suche kein Engineering-Vokabular. Ich suche den Satz, den der CTO dem CEO oder dem Board sagen würde, wenn er gefragt würde: “Was ist das Problem genau, und was ermöglicht uns die Behebung, das wir heute nicht können?”

Die Antworten, die zurückkommen, fallen in grobe Kategorien. Jede Kategorie hat eine andere richtige Antwort, und die richtige Antwort ist fast nie ein kompletter Rewrite.

“Feature-Velocity ist zu langsam.” Das ist die häufigste Antwort. Was sie meistens bedeutet: Die Teile der Codebasis, an denen das Team gerade arbeitet, sind verstrickt, aber die Teile, die sie nicht anfassen, sind in Ordnung. Die Lösung ist, die konkreten Module zu identifizieren, die die Velocity blockieren, und genau die herauszulösen. Der Rest des Systems macht weiter seinen Job. Dafür ist das Strangler Fig Pattern da. Ein Rewrite des gesamten Systems verschwendet 80% seines Budgets auf Code, der gar nicht das Problem war.

“Wir finden keine Engineers, die auf diesem Stack arbeiten wollen.” Das ist ein Hiring-Problem im Architektur-Kostüm. Manchmal ist der Stack wirklich ein Hindernis (PHP 5 im Jahr 2026; ein hauseigenes Custom-Framework). Manchmal ist der Stack in Ordnung und das eigentliche Problem sind die Onboarding-Dokumente, das Tooling, der Deployment-Prozess oder fehlende Tests in der Codebasis. Wenn Ihre Symfony-5-Codebasis PHPStan-Level 0 und keine Tests hat, ist das Hiring-Problem nicht die Framework-Version. Upgrades (siehe Symfony Major Version Upgrades) und Investition in die Qualitätslatte beheben davon mehr als ein Rewrite.

“Die Architektur skaliert nicht.” Oft behauptet, selten wahr. “Skaliert nicht” heißt fast immer “der aktuelle konkrete Flaschenhals ist schwer zu beheben”. Der konkrete Flaschenhals mag eine einzige Hot Table sein, ein synchroner Service-Call, der async sein sollte, eine fehlende Cache-Schicht, ein N+1-Query, der in einem Listener versteckt ist. All das lässt sich ohne Rewrite beheben. Wegen eines einzigen Flaschenhalses alles neu zu schreiben, ist, als risse man ein Haus ab, weil ein Fenster undicht ist.

“Wir sind auf der falschen Datenbank.” Manchmal wahr, meistens übertrieben. Wenn Sie auf MongoDB sitzen und Ihre Zugriffsmuster relational sind, ist die Migration auf PostgreSQL teuer, aber endlich; der Rest der Anwendung ist unberührt. Die Anwendung neu zu schreiben, um die Datenbank zu wechseln, ist ein Kategorienfehler.

“Das ursprüngliche Team ist weg.” Das ist eine echte Sorge, aber ein Rewrite löst sie nicht. Auch das neue Team wird irgendwann gehen, und es wird Code hinterlassen, der neuer ist, aber für das erbende Team genauso undurchsichtig. Was das behebt: Dokumentation, Tests und die Reduktion des impliziten Wissens, das eine einzelne Person hält. Ein Rewrite, geführt von Leuten, die in 18 Monaten gehen werden, erzeugt dasselbe Problem in 18 Monaten plus einem Rewrite.

Wenn der CTO keinen einzigen klaren, geschäftstauglichen Satz produzieren kann, ist der Rewrite nicht gescoped, sondern gevibed. Der Rewrite-Vorschlag ist noch nichts, was man finanzieren oder bewerten könnte, und keine Menge an Engineering-Arbeit rettet ihn, solange niemand den Satz aufgeschrieben hat.

Frage 2: Was haben Sie konkret versucht, und was haben Sie gelernt?

Ein Team, das einen Rewrite vorschlägt, hat meist zwei oder drei Interventionen versucht, die gescheitert sind. Die Details dieser Fehlschläge sind enorm aufschlussreich.

“Wir haben versucht, Modul X zu refaktorieren, und es hat nicht gegriffen.” Die interessante Frage ist warum. War der Scope zu groß? Wurde das Refactoring mittendrin abgebrochen, weil ein Kundenvorfall das Team abgezogen hat? Wurde das Refactoring ausgeliefert, aber durch spätere Änderungen stillschweigend wieder zurückgedreht, weil niemand die neuen Muster durchgesetzt hat? Jeder dieser Fälle hat ein anderes Heilmittel, und keines davon ist ein Rewrite. Ein Rewrite wird denselben Kräften begegnen, die das Refactoring getötet haben, in der zehnfachen Größenordnung.

“Wir haben versucht, Tests hinzuzufügen, und es war zu schmerzhaft.” Meistens bedeutet das, der Code ist eng gekoppelt und in seiner aktuellen Form nicht testbar. Die Lösung: Seams einziehen, dann Tests. Ein Rewrite von Grund auf ist nicht magisch testbar; ein Rewrite, den dasselbe Team schreibt, das den nicht testbaren Code geschrieben hat, produziert typischerweise wieder eine nicht testbare Codebasis. Ich habe das mehrfach erlebt.

“Wir haben versucht, Senior-Engineers einzustellen, und keiner ist geblieben.” Meistens bedeutet das, die Onboarding-Erfahrung ist schlecht, oder die Teamkultur hat Probleme, oder der Stack ist tatsächlich ein Außenseiter. Ein Rewrite verbessert nichts davon, es sei denn, Sie fixen diese Punkte ausdrücklich, und dann hätten Sie sie auch gleich ausdrücklich fixen können.

“Wir haben nichts Ernsthaftes versucht, aber wir sind sicher, der Rewrite ist die Antwort.” Das ist die gefährlichste Variante. Wenn niemand ernsthaft, sauber gescoped und finanziert ein Refactoring in der aktuellen Codebasis versucht hat, können Sie noch nicht wissen, ob Refactoring nicht reicht. In diesen Fällen empfehle ich zuerst ein neunzigtägiges, gezieltes Refactoring des schmerzhaftesten einzelnen Moduls. Wenn es gut läuft, haben Sie Evidenz, dass Refactoring funktioniert, und ein Muster zum Skalieren. Wenn es schlecht läuft, haben Sie Evidenz für den Rewrite-Case, zu einem Bruchteil der Kosten, als das durch den Rewrite selbst zu lernen.

Diese Frage ist die wichtigste der vier. Rewrites, die gelingen, folgen fast immer auf mehrere ehrliche Versuche kleinerer Interventionen. Rewrites, die scheitern, kommen fast immer von Teams, die nichts anderes ernsthaft versucht haben.

Frage 3: Was bleibt gleich, und was ändert sich?

Wenn der Rewrite stattfindet, welche Teile des Geschäfts sind am Ende tatsächlich anders? Diese Frage ist meist unangenehm, weil die Antwort häufig “nicht viel” lautet.

Die Szenarien, die ich sehe:

Das Produkt ist dasselbe, die Architektur ist neu. Der Rewrite reimplementiert den bestehenden Feature-Umfang auf einem neuen Stack. Endzustand: gleiches Produkt, gleiche Kunden, gleicher Umsatz, neuer Code. Das Geschäft hat sich nicht verändert. Achtzehn Monate Engineering-Zeit haben Ihnen sauberere Internals gekauft. Manchmal ist das den Preis wert, meist wegen eines konkreten Pfades, den der alte Code blockiert hat. Oft ist es das nicht. Fragen Sie: Was können wir mit dem neuen System tun, was wir mit dem alten nicht konnten, in konkreten kundensichtbaren Begriffen? Wenn die Antwort unscharf ist, stimmt die Ökonomie wahrscheinlich nicht.

Das Produkt ist dasselbe, das Datenmodell ist neu. Ein Rewrite, motiviert durch Aufräumen des Datenmodells. Endzustand: dieselben Features funktionieren, aber die darunterliegenden Tabellen sind jetzt sinnvoll. Intern wertvoll, extern unsichtbar. Die Frage ist, ob das Aufräumen des Datenmodells einen vollständigen Rewrite rechtfertigt, wenn es auch als eigenständige Migration hätte erfolgen können (siehe Zero-Downtime Doctrine Migrations). Meistens nein.

Das Produkt ändert sich. Das Team überdenkt auch, was das Produkt tut, nicht nur, wie es gebaut ist. Das ist der Fall, in dem ein Rewrite am ehesten zu rechtfertigen ist, weil der bestehende Code von Annahmen geformt wurde, die nicht mehr gelten. Auch hier ist der bessere Weg oft, das bestehende Produkt einzufrieren (nur Wartung, minimale Investition) und das neue Produkt als tatsächlich neues System zu bauen, nicht als Rewrite des alten. Eine Sache neu zu schreiben, die Sie gleichzeitig substanziell verändern wollen, sind zwei Risiken in einem Projekt.

Das Team ändert sich. Manchmal ist der “Rewrite” zur Hälfte Code und zur Hälfte ein Abbau impliziter Hierarchien. Der Engineer, der das ursprüngliche System geschrieben hat und ein Vetorecht darüber hat, geht während der Rewrite-Planung. Der Rewrite ist, teilweise, ein Weg, die Teamdynamik zurückzusetzen. Dafür habe ich eine gewisse Sympathie; Rewrites können als organisatorisches Reset funktionieren. Aber sie sind extrem teure organisatorische Resets, und es gibt günstigere (neuer Tech Lead, Team-Umbau, explizites Modernisierungsmandat).

Die gesündesten Rewrite-Gespräche beantworten “Das Produkt ändert sich auf konkrete Weise, die das aktuelle System nicht abbilden kann” mit einer Liste dieser konkreten Wege. Alles andere ist Rewrite als ästhetische Präferenz, und ästhetische Präferenz rechtfertigt die Kosten selten.

Frage 4: Was sind die tatsächlichen Kosten, ehrlich bepreist?

Hier wird die Rechnung unbequem. Ich bitte das Team, drei Dinge zu bepreisen:

Vergangene Zeit bis zur Feature-Parität. Nicht “erster Deploy” oder “MVP des neuen Systems”. Tatsächliche Feature-Parität mit dem aktuellen Produktionssystem. Die meisten Teams unterschätzen das um den Faktor 2 bis 3, weil das aktuelle System drei Jahre undokumentierte Edge Cases, Hotfixes und Verhalten-die-eigentlich-Features-sind-auf-die-sich-Kunden-verlassen enthält. Die vergangene Zeit, all das nachzuziehen, ist länger als der ursprüngliche Aufbau, nicht kürzer.

Opportunitätskosten. Was auch immer Ihr Team während des Rewrites tut, es tut nichts anderes. Wenn das Team sonst sechs neue Features pro Jahr ausliefert, kostet der Rewrite sechs Features pro Jahr Laufzeit. Bei achtzehn Monaten sind das neun Features, die Sie nicht geliefert haben. Wie sieht Ihre Wettbewerbslandschaft nach neun übersprungenen Features aus?

Risikokosten. Rewrites haben eine nicht triviale Wahrscheinlichkeit, nie fertig zu werden. Branchenzahlen zu großen Softwareprojekten sind wenig schmeichelhaft: Die langjährige Standish CHAOS-Forschung zeigt durchgehend, dass eine signifikante Minderheit der Projekte schlicht gecancelt wird und die Mehrheit zu spät, über Budget oder mit reduziertem Scope liefert. Ein vollständiger Rewrite ist per Definition ein großes Projekt und erbt diese Quoten. Selbst erfolgreiche Rewrites liefern oft mit reduzierter Funktionalität gegenüber dem Original aus, mit “X bauen wir später wieder ein”-Features, die nie wieder gebaut werden. Bepreisen Sie das als: “Was ist der Erwartungswert des Rewrites, gewichtet mit der Erfolgswahrscheinlichkeit?” Die Zahl ist meist kleiner, als die Führung sie sich vorstellt.

Wenn ich auf diese Kosten drücke, ändert sich das Gespräch. Ein CTO, der sich den Rewrite als “sechs Monate, etwas Gemurre, sauberer Code” vorgestellt hat, verlässt das Gespräch meist mit dem Bild “achtzehn Monate, verzögerte Roadmap, 30% Scheiternsrisiko, und die Daten und Kunden müssen wir sowieso vom alten System herüberziehen”. Dasselbe Projekt, anderer Rahmen. Der Rahmen ist es, der eine klare Entscheidung möglich macht.

Wenn die Antwort tatsächlich Rewrite lautet

Ich habe gesagt, dass ich ihnen fast immer davon abrate. Manchmal tue ich es nicht, und es lohnt sich, diese Fälle zu benennen.

Die Sprache ist tot und unhireable. Wenn Sie im Jahr 2026 auf PHP 5.4 sitzen, nicht aus Vernachlässigung, sondern weil die Codebasis Bibliotheken nutzt, die nie vorwärts portiert wurden, und die Community rund um die Sprache weitergezogen ist, sitzen Sie in einer Ecke, die Refactoring nicht erreicht. Eine Migration auf einen aktuell unterstützten Sprachstack ist ein Rewrite unter anderem Namen. Tun Sie es, aber in Phasen (Strangler Fig über Versionen hinweg, kein Big Bang).

Das Datenmodell ist für das Produkt, zu dem das Geschäft geworden ist, fundamental falsch. Wenn das Geschäft um “Nutzer” gebaut war und jetzt um “Accounts, die Teams enthalten, die Nutzer enthalten” gebaut ist und die bestehenden Tabellen das überhaupt nicht abbilden, ist das Entflechten manchmal so umfangreich, dass ein Parallelbau günstiger ist als ein Umbau im Bestand. Selten, aber real.

Eine kritische regulatorische Anforderung ist mit der bestehenden Architektur nicht erfüllbar. Wenn Sie in den Gesundheits- oder Finanzregulierungsbereich eintreten und das aktuelle System PII und operative Daten auf eine Weise vermischt, die sich nicht sauber trennen lässt, brauchen Sie möglicherweise einen Rewrite mit eingebauter Trennung. Das ist selten genug, dass ich vor der Akzeptanz ein schriftliches regulatorisches Gutachten sehen möchte.

Der ursprüngliche Stack ist eine bekannte Sackgasse. Teams, die auf Frameworks gebaut haben, die später ihre Community verloren haben (oder auf proprietären Systemen, deren Anbieter pleitegegangen ist), sind in einer anderen Lage als Teams, die eine funktionierende Symfony- oder Rails-Codebasis pflegen. Ein totes Ökosystem zu verlassen, ist manchmal die richtige Entscheidung.

Beachten Sie: Keiner dieser Gründe lautet “der Code ist hässlich” oder “die Feature-Velocity ist langsam”. Diese Probleme haben günstigere Lösungen. Die oben genannten Gründe beschreiben kategoriale Fehlpassungen zwischen dem bestehenden System und der Zukunft des Geschäfts, nicht lokale Probleme der Codequalität.

Was ich stattdessen empfehle, fast jedes Mal

Wenn die vier Fragen das Gespräch vom Rewrite wegdrücken, läuft meine Empfehlung meist auf irgendeine Variante von Folgendem hinaus:

  1. Stabilisieren. Investieren Sie ein bis zwei Monate in Qualitätshygiene. PHPStan-Level hochziehen, Deprecations aufräumen, Testabdeckung auf den heißen Pfaden, eine Deployment-Pipeline, die tatsächlich sicher ausliefert. Der Schmerz des Teams sinkt allein dadurch messbar.
  2. Kartieren. Erstellen Sie eine Karte der technischen Schulden (siehe Technische Schulden sind eine Karte, kein Backlog). Identifizieren Sie, welche Regionen des Systems die Velocity blockieren, welche in Ruhe gelassen werden können und welche in Wirklichkeit in Ordnung sind, wenn Sie ehrlich hinschauen.
  3. Ein Ding herauslösen. Nehmen Sie das einzelne Modul, das den meisten Schmerz verursacht. Lösen Sie es mit dem Strangler Fig Pattern heraus, entlang der Ideen von Fowler und Lewis’ Patterns of Legacy Displacement. Liefern Sie es aus. Löschen Sie den alten Code. Messen Sie die Wirkung.
  4. Neu bewerten. Nach Schritt drei hat das Team Evidenz. Entweder der Schmerz ist messbar reduziert und das Programm läuft weiter, oder nicht, dann ist der Rewrite-Case stärker als zuvor.

Dieser Plan dauert drei bis sechs Monate, kostet einen Bruchteil eines Rewrites und ist in jedem Schritt umkehrbar. Wenn er funktioniert, haben Sie Jahre produktiver Weiterentwicklung aus dem bestehenden System herausgeholt. Wenn er nicht funktioniert, wissen Sie genau, warum, und der Rewrite-Case ruht jetzt auf Evidenz statt auf Intuition.

Die meisten Teams, die diesen Plan durchziehen, brauchen den Rewrite nie. Einige doch, und sie starten ihn mit einem klareren Verständnis davon, was sie eigentlich reparieren und warum.

Das Gespräch, das ich führen möchte

Die CTOs, mit denen ich spreche, sind fast ohne Ausnahme nachdenkliche Menschen, die versuchen, das Richtige für ihre Teams und ihr Geschäft zu tun. Sie schlagen Rewrites nicht vor, weil sie naiv sind. Sie schlagen Rewrites vor, weil der Rewrite die sichtbarste Option in dem Gespräch ist, das sie mit ihrer Führung führen.

Mein Job in diesen Gesprächen ist, das Gespräch zu öffnen. Die kleineren, günstigeren, weniger heroischen Optionen sichtbar zu machen. Die Evidenz zu zeigen, dass sie funktionieren. Dem CTO einen anderen Satz für das Board mitzugeben: “Statt eines achtzehnmonatigen Rewrites werden wir drei Monate modernisieren, sechs Monate die zwei Module herauslösen, die tatsächlich langsam sind, und nach neun Monaten neu bewerten.” Dieser Satz ist einfacher zu finanzieren, einfacher zu verteidigen und hat eine dramatisch höhere Erfolgswahrscheinlichkeit als der Rewrite.

Das Ziel ist nicht, alle Rewrites zu verhindern. Es ist, die zu verhindern, die Symptome statt Heilmittel waren. Der Rewrite, der alle vier Fragen mit ehrlichen Antworten übersteht, ist wahrscheinlich die richtige Entscheidung. Das ist nur eine viel kleinere Menge als die Menge der Rewrites, die vorgeschlagen werden.

Wenn Sie einen Rewrite abwägen und unsicher sind, ob der Case unter Druck hält, beginnt mein Monolith-Modernisierungs-Engagement mit genau diesem Gespräch. Vier Fragen, ehrliche Antworten, eine schriftliche Entscheidung in die eine oder andere Richtung und (wenn die Antwort nicht der Rewrite ist) ein konkreter Plan für die günstigere Alternative, die die Symptome tatsächlich adressiert.

Referenzen

Insights

Bereit, Ihre Architektur in den Griff zu bekommen?

Buchen Sie ein kostenloses 30-minütiges Gespräch mit Silas. Kein Verkaufsgespräch, nur ein direkter Austausch über Ihre Herausforderungen.

Antwort in der Regel innerhalb von 24 Stunden.

Kostenloses Gespräch buchen