Hier ist meine persönliche Top 8 der größten Fehler beim Rewrite von Softwaresystemen:

  1. Big-Bang Rewrite. Erst muss die gesamte Funktionalität im neuen System abgebildet sein, bevor die Bestandskunden auf das neue System migriert werden. Martin Fowlers Antwort darauf: “If you do a big-bang rewrite, the only thing you’re guaranteed of is a big bang.”

  2. Die besten Leute auf das neue System ansetzen, alle anderen bleiben beim Bestandssystem. Sie fühlen sich natürlich wie auf dem Abstellgleis. “Wir sind hier nur die Cleanup Guys.” und “Warum kriegen die anderen so viele Ressourcen, wir sind doch hier diejenigen die das Geld reinholen?” hört man dann immer wieder.

  3. Migration erst planen, wenn das neue System “fast fertig” ist und der Druck von außen immer größer wird. An dieser Stelle hat man sich schon viel verbaut. Eine schmerzarme Migration ist unter Umständen gar nicht mehr möglich. (“Oh, das Kopieren der Daten dauert mehrere Tage… die Zeit wären wir dann down…”)

  4. Features im Bestandssystem nicht hinterfragen, sondern blind 1:1 übernehmen sowie Nutzer und Kunden nicht oder nur eingeschränkt mit in den Prozess einbeziehen. Dadurch hat man dann die ganze angehäufte fachliche Komplexität schnell im neuen System.

  5. Den Aufwand maßlos unterschätzen. Es ist ja auch einfach spezifiziert: “Genauso wie das Alte” - aber extrem viel Wissen steckt im Detail und im Code. 10+ Jahre Entwicklung nachzuholen dauert halt.

  6. Das gesamte System ablösen wollen. Vielleicht muss alles neu geschrieben werden. Vielleicht gibt es aber auch einen stabilen Kern, der sich nicht lohnt umzuziehen, weil er stabil läuft und es fast keine Änderungen gibt.

  7. Kunden einen zu großen Schritt zumuten. Neues System, neues Betriebsmodell, neues Pricing, erstmal kein erkennbarer Mehrwert für den Kunden → das führt zu Widerstand.

  8. Overengineering. Das ist die Chance jetzt alles besser und modern zu bauen! Schön. Erwartungsdruck und Selbstüberschätzung führen aber schnell zu Overengineering, auch bekannt als “Second-System Effect” (Brooks 1975 - Danke Heiko Koziolek für den Hinweis!). Allerdings ist das, was heute modern und sexy ist, in 3-5 Jahren schon wieder veraltet. Also Technologieauswahl mit Augenmaß und Weitsicht.

Der Hauptfehler liegt - meiner Meinung nach - in einer “alten Welt” und “neuen Welt” zu denken und beides als getrennte Systeme zu betrachten.

Es handelt sich aber um EIN PRODUKT, das schrittweise weiterentwickelt wird.

Patterns und Vorgehensweisen gibt es dazu genug: Strangler Fig, Branch by Abstraction, Parallel Run, Decorating Collaborator, …

Bücher ebenfalls:

Was sind deine Erfahrungen mit Rewrites von Softwaresystemen? Was hat gut funktioniert? Was nicht? Ich bin neugierig 😊

Live Webinar: Softwareentwicklung skalieren, ohne sich im Wachstumsprozess aufzureiben

„Im Webinar wurden genau die Pain Points angesprochen, die in unserem Wachstum gerade auftreten. Bei stetig steigender Zahl an Mitarbeitern im Dev & Product Team mussten wir selbst feststellen, wie schwierig es ist, eine sinnvolle Struktur aufzubauen, die bei jedem das Maximum an Effizienz und Leistung hervorbringt und gleichzeitig zu einer gesunden Arbeitsatmosphäre führt.”
Pascal von Briel, Co-Founder & CPO @ exporto GmbH