Brooks hat 1975 über den Second-System-Effect geschrieben, und jedes Team, in dem ich seitdem war, hat ihn neu entdeckt — meistens um den Zeitpunkt, wenn ihr Rewrite Monat sechs erreicht, ohne funktionierenden Prototypen. Die Falle ist nicht der Wunsch nach einem besseren System — sie ist die Überzeugung, das alte sei durch Zufall zusammengehalten worden. Dieser Post ist die Checkliste, durch die ich jetzt jedes “Lass uns das einfach neu schreiben”-Gespräch zwinge.
Was der Second-System-Effect eigentlich ist
Brooks’ Behauptung — von allen paraphrasiert, auch von mir — ist, dass das zweite System, das ein Designer baut, das am stärksten überengineerierte ist. Das erste System wurde unter Constraints gebaut; es hat dem Designer beigebracht, was wichtig ist. Beim zweiten fühlt sich der Designer befreit, kennt “wo die Leichen begraben sind”, und darf es endlich richtig machen. Er übertrifft sich. Er fügt jedes Feature hinzu, das er zuvor verweigert hat. Das Ergebnis ist ein aufgeblähtes System, das schwieriger zu shippen, schwieriger zu warten und schwieriger zu ersetzen ist — und es dauert dreimal so lang zu shippen wie das erste.
Was Brooks nicht betont hat, aber 50 Jahre Evidenz klargestellt haben: Der Second- System-Effect ist fast immer ein Rewrite, kein Greenfield. Und Rewrites scheitern fast immer aus denselben sechs Gründen.
Die sechs Warnsignale
Wenn jemand im Team “Lass uns das einfach neu schreiben” sagt, stelle ich jetzt diese sechs Fragen in dieser Reihenfolge. Wenn die Antworten falsch sind, wird das Rewrite sterben. Nicht vielleicht. Es wird.
1. Kannst du auf den genauen Production-Schmerz zeigen?
Nicht “der Code ist schwer zu bearbeiten.” Nicht “die Tests sind langsam.” Nicht “das Framework ist alt.” Ich will ein spezifisches, production-sichtbares Verhalten: einen Latency-Spike, eine Bug-Klasse, die immer wieder auftritt, ein Feature, das dreimal verzögert wurde, weil die aktuelle Architektur es teuer macht.
Wenn die Antwort ein Developer-Experience-Schmerz statt eines Production- Schmerzes ist, wird das Rewrite scheitern. Denn die Entwickler des zweiten Systems werden unweigerlich ihre eigenen Developer-Experience-Schmerzen haben, die noch niemand aufgelistet hat. Du tauschst bekannten Schmerz gegen unbekannt geformten Schmerz.
2. Hast du mit der Person gesprochen, die es ursprünglich gebaut hat?
Der ursprüngliche Designer weiß, warum das seltsam aussehende Ding da ist. 70 % der Zeit ist die Antwort ein Production-Incident von vor vier Jahren, der nicht in der Commit-History steht. Wenn du nicht fragst, wirst du den Bug neu implementieren, den sie behoben haben. Ich habe das zweimal passieren sehen, mit mir selbst.
Wenn der ursprüngliche Designer gegangen ist: Finde die Incident-Post-Mortems. Wenn die auch nicht existieren: Skaliere dein Vertrauen um die Hälfte herunter. Der Code, den du neu schreiben willst, ist auf Arten tragend, die du nicht sehen kannst.
3. Gibt es ein “Walking Skeleton” im Plan?
Ein Rewrite, das in den ersten zwei Wochen nichts End-to-End shippt, wird niemals etwas shippen. Der Plan sollte ein Tag-14-Milestone haben, der so aussieht: “Ein echter Request fließt durch das neue System in Production, shadowend das alte, mit 0 % Traffic.” Wenn der Plan mit “zuerst bauen wir das neue Datenmodell, dann den neuen API-Layer, dann den neuen UI-Layer” beginnt — herzlichen Glückwunsch, du hast 2026 einen Waterfall-Plan geschrieben, und niemand hat es gemerkt.
Bei Bytro funktionierte die Event-Driven-Modernisierung, die wir gemacht haben, weil wir ab Woche zwei einen Live-Shadow betrieben haben. Jeder Request traf sowohl das alte als auch das neue System. Wir haben die Outputs nächtlich verglichen. Die Diskrepanzen waren die Spec.
4. Hast du eine klare Metrik für “fertig”?
“Das alte System ist weg” ist keine Metrik. “99 % der Requests werden vom neuen System bedient, p99 innerhalb von 10 % der Baseline, Error-Rate flach oder niedriger” ist eine Metrik. Wenn du nicht weißt, wann du fertig bist, wirst du niemals fertig sein, und das Team wird ewig zwischen zwei Systemen oszillieren.
Das Second-System-Effect-Ruin ist nicht, dass das neue System schlecht ist. Es ist, dass die Org jetzt zwei Systeme wartet, während die “Fertigstellung” des Rewrites perpetuell ein Quartal entfernt ist. Ich habe Unternehmen gesehen, die drei Jahre lang in diesem Zustand liefen.
5. Wer besitzt das alte System, während das neue gebaut wird?
Die unglamouröse Antwort: Dieselben Leute, die das neue bauen sollten. Wenn dein Rewrite-Plan still davon abhängt, das alte System einzufrieren — “wir hören einfach auf, 18 Monate lang Features daran hinzuzufügen” — ist dein Rewrite tot, bevor es geshipt wird.
Das alte System akkumuliert seine eigenen kritischen Bug-Fixes, während das neue gebaut wird. Entweder du überträgst diese Fixes (was bedeutet, sie zweimal zu bauen), oder du shipst das neue System ohne 18 Monate inkrementeller Fixes (was bedeutet, es ist kein echter Drop-in-Ersatz).
6. Was ist die Rollback-Story?
In dem Moment, in dem du das neue System bei 1 % Traffic einschaltest — was passiert, wenn p99 auf 2 Sekunden geht? Wer bemerkt es? Was tun sie? Gibt es ein Dashboard? Gibt es einen Alarm? Ist das Rollback ein Befehl oder ein Reconfigure-und-Redeploy?
Ein Rewrite ohne schnellen Rollback ist eine Wette. Wetten zahlen sich gelegentlich aus, meistens wenn der Engineer, der die Wette macht, einen karrieredefinierten Grund hatte, Recht zu haben. In allen anderen Fällen sind sie ein Resume-generierendes Event für denjenigen, der den Ausfall erklären muss.
Das Rewrite, das ich wirklich genossen habe
Das einzige Rewrite in meiner Karriere, das reibungslos verlief, war die Bytro- Modernisierung. Es funktionierte, weil wir diese sechs Fragen bevor wir begannen beantworteten — und sie größtenteils mit “Ja” beantworteten:
- Production-Schmerz: Event-Ordering im Echtzeit-Game-Backend verursachte spielervisible Desync bei Match-Joins. Quantifiziert, user-gemeldet, Priority-1.
- Ursprünglicher Designer: Noch im Team, aktiv am Rewrite beteiligt. Die Leichen waren sichtbar.
- Walking Skeleton: Woche zwei, ein Endpoint fließt durch den neuen Event-Bus. Woche sechs, fünf Endpoints. Woche zwölf, der kritische Pfad.
- Metrik für fertig: 99 % der Matches werden über den neuen Pfad gejoint, p99 innerhalb der Baseline. Hat ungefähr 11 Monate gedauert — zwei Monate über Plan, was ungewöhnlich nah war.
- Ownership während der Transition: Dasselbe Squad besaß beide Systeme, und wir haben nicht-kritische Änderungen am alten eingefroren. Product hat dem zugestimmt, weil wir ihnen wöchentlichen Fortschritt auf dem neuen Pfad gezeigt haben.
- Rollback: Ein Feature-Flag-Flip. Das Flag wurde wöchentlich getestet — nicht nur definiert, getestet. In einem echten On-Call-Drill. Das hat uns in Monat acht gerettet, als ein Randfall auftauchte.
Jedes andere Rewrite, das ich sterben sah, hat 3+ dieser sechs verfehlt. Ich kenne kein einziges Gegenbeispiel.
Die 2026-Version davon
Rewrites haben 2026 eine neue Versuchung: “Die KI schreibt es einfach neu.” Ich habe durch diese Site allein ungefähr 3.400 Commits KI-gestützter Entwicklung im letzten Jahr geführt, und ich sage die stille Wahrheit: KI schützt dich nicht vor dem Second-System-Effect. Die Versuchung zu rewriten ist sogar einfacher zu nachgeben, wenn der erste Draft sich kostenlos anfühlt.
Was KI-gestützte Entwicklung günstig ermöglicht, ist, einen Migrationspfad zu spiked — eine 48-Stunden-Version des neuen Systems gegen einen Endpoint zu bauen, zu schauen, was wehtut, sie wegzuwerfen. Das ist eine phänomenal untergenunutzte Technik. Die meisten Rewrites committen auf Basis eines Slide-Decks; ein KI- unterstützter Spike gibt dir eine Woche echter Evidenz zum Preis eines Decks.
Wenn du eine Sache aus diesem Post mitnimmst: Lass das Rewrite nicht von einem Slide-Deck starten. Spike es, wirf den Spike weg, und dann entscheide.
Das Ding, bei dem ich mich selbst ertappe
Ich habe diesen ganzen Post geschrieben, um gegen Rewrites zu argumentieren. Ich betreibe auch gerade Fulcrum — eine Agent-Control-Plane, die ich gebaut habe, weil keines der bestehenden Runtimes zu meiner Arbeitsweise passte — was, pedantisch gesehen, ein Rewrite von etwas ist, das ich auf bestehenden Tools hätte bauen können.
Ich habe es durch meine eigene Checkliste geführt. Der Production-Schmerz war real (kein bestehendes Tool koordinierte Multi-Agent-Runs so, wie ich es wollte). Ich habe mit dem Designer gesprochen (mir selbst; ich habe auch die History aufgeschrieben). Walking Skeleton wurde in Woche eins geshipt. Ich habe eine klare Metrik für fertig. Ich besitze sowohl den alten Script-basierten Workflow als auch das neue Ding. Rollback ist “Fulcrum-CLI schließen und zurück zu Shell-Aliases gehen.”
Sechs von sechs. Also habe ich mir das Rewrite erlaubt. Hätte ich drei von sechs getroffen, hätte ich es verworfen. Das ist der Bar. Benutze ihn, und deine Rewrites werden geshipt. Ignoriere ihn, und du verbringst 18 Monate damit zu erklären, warum das neue System “fast fertig” ist.