Rewrites, die nichts heilen (5/8)
Rewrites bleiben verführerisch, weil alter Code fremde Entscheidungen enthält und neuer Code sich nach Fortschritt anfühlt, während die Domäne unverändert bleibt. Die meisten verschieben Komplexität, statt sie zu reduzieren, und beruhen auf emotionaler statt messbarer Begründung. Das Härteste an Software ist nicht, neuen Code zu schreiben, sondern alten zu lesen und zu verstehen, warum er funktioniert.
Einleitung
Jeder, der lange genug in der Branche arbeitet, war irgendwann dabei,
als ein Team beschlossen hat, das alte System „einfach komplett neu zu schreiben”.
Fast alle, die das erlebt haben, haben auch erlebt,
wie das Projekt nach zwei Jahren leise in einem Statusbericht erwähnt wird,
bevor es ein Jahr später stillschweigend eingestellt wird.
Ein alter Text, immer noch richtig
Joel Spolsky schrieb „Things You Should Never Do, Part I” im Jahr 2000.
Netscape war damals mitten im eigenen Rewrite.
Das wurde Mozilla.
Es hat sehr lange gedauert, bis daraus etwas wurde, das funktionieren konnte.
Der Text ist immer noch richtig.
Er wird immer noch kaum gelesen.
Warum Rewrites verführen
Die Antwort ist psychologisch, nicht technisch.
Alter Code ist das Werk fremder Leute.
Er ist unordentlich, weil er zehn Jahre Änderungen aufgenommen hat, die niemand mehr begründen kann.
Ihn zu lesen fühlt sich an wie Archäologie.
Neuer Code fühlt sich an wie Fortschritt.
Man entscheidet selbst.
Jede Zeile ist eine eigene Aussage.
Niemand mag es, an fremden Entscheidungen zu arbeiten.
Die Domäne schreibt sich nicht um
Die Geschäftsregeln bleiben.
Die Randfälle bleiben.
Die stillen Anforderungen bleiben.
Das neue Team löst dieselben Probleme in einer anderen Sprache.
Und es sieht eine Zeit lang besser aus — weil die neuen Bugs noch nicht gefunden wurden.
Viele Rewrites gelten als gelungen, solange sie nicht in Produktion laufen.
Sobald sie laufen, beginnt die zweite Welle:
- Altlasten werden wiederentdeckt
- Die elegante Architektur zeigt ihre Lücken
- Nach drei Jahren hat das neue System seine eigene Schuldenkurve — manchmal steiler als die des alten
Wann Rewrites sinnvoll sind
Nicht nie. Aber selten.
Sinnvoll sind sie, wenn sich die Anforderungsbasis grundlegend verändert hat:
- Das alte System stammt aus dem Client-Server-Zeitalter, heute ist die Welt mobil und verteilt.
- Der Datenmodellkern kann ein neues Geschäftsmodell strukturell nicht abbilden.
- Die Sicherheitsannahmen des alten Systems sind fundamental überholt — Nachrüsten wäre teurer als neu machen.
In diesen Fällen ist der Rewrite kein Theater.
Dann ist er eine Investition mit prüfbarer Begründung.
Die emotionale Begründung
Die meisten Rewrites, die ich gesehen habe, hatten diese Begründung nicht.
Sie hatten stattdessen eine emotionale:
„Das System ist einfach nicht mehr zeitgemäß.”
Das ist keine Begründung.
Das ist ein Gefühl.
Man darf es ernst nehmen.
Aber man sollte es nicht mit einem Projekt von mehreren Millionen Euro beantworten.
Eine ehrliche Faustregel
Eine gute Faustregel, die ich mir angewöhnt hatte:
Wenn ich einen Rewrite vorschlug, musste ich vorher erklären können,
was genau ich durch den Umbau erwartete.
Nicht „sauberere Architektur”.
Sondern:
- Welches konkrete Problem wird gelöst?
- Welches messbare Verhalten ändert sich?
- Welche Kosten fallen an?
- Über welchen Zeitraum amortisieren sie sich?
Wenn ich das nicht konnte, wollte ich keinen Rewrite.
Dann wollte ich nur mein Unbehagen an fremdem Code in ein Projekt verwandeln.
Das ist menschlich, aber keine Strategie.
Zentrale Beobachtung
Das Härteste an Software ist nicht, neuen Code zu schreiben.
Es ist, alten Code zu lesen und zu verstehen, warum er funktioniert.
Abschlussgedanke
Ein Rewrite ist oft die Flucht davor.
Manchmal ist sie nötig.
Meistens ist sie nur bequemer.
