Softwareprojekt retten oder neu bauen: So treffen Sie die Entscheidung

Wenn ein Softwareprojekt lange genug scheitert, stellt irgendwann jemand die Frage, der alle bisher ausgewichen sind: Sollen wir dieses Projekt retten oder von Grund auf neu bauen? Es wirkt wie eine Entweder-oder-Entscheidung: den bestehenden Code behalten und versuchen, ihn zu reparieren, oder alles wegwerfen und neu anfangen.

Diese Sichtweise ist falsch, und eine Fehlentscheidung wird in beide Richtungen teuer. Eine Rettung bei einem System, das sich tatsächlich nicht stabilisieren lässt, verschwendet Monate und liefert am Ende eine etwas bessere Version eines grundlegend kaputten Produkts. Ein Neubau, der beginnt, ohne dass jemand verstanden hat, was schiefgelaufen ist, wiederholt mit ziemlicher Sicherheit dieselben Fehler und dauert doppelt so lange wie jede Schätzung.

Die vier echten Wege

Zwischen Rettung und Neubau liegen vier unterschiedliche Wege, jeder mit eigenem Kostenprofil, eigenem Zeitrahmen und eigenen Voraussetzungen.

• Stabilisieren: Das bestehende System hat ein solides Fundament. Die Architektur ist vertretbar, das Team versteht sie, der Business Case trägt noch. Aber die Lieferung ist zusammengebrochen. Ansetzen muss man bei Prozessen und Verantwortlichkeiten, nicht am Code. Die meisten Projekte, die als „Rettung“ bezeichnet werden, sind in Wahrheit Stabilisierungen.
• Modernisieren: Das System funktioniert und liefert Wert, aber einzelne Architekturentscheidungen haben so viele technische Schulden angehäuft, dass jede Änderung teuer und langsam wird. Der Weg ist eine gezielte Modernisierung des Engpasses, nicht des ganzen Systems. Dieser Weg wird am seltensten genutzt: Unternehmen springen direkt zum „Neubau“, obwohl „eine Schicht modernisieren“ dasselbe Ergebnis schneller und günstiger gebracht hätte.
• Gezielt neu bauen: Teile des Systems sind tatsächlich nicht mehr zu retten (falsche Architektur für die aktuelle Last, keine Testabdeckung, kein Engineer, der versteht, wie sie funktionieren), der Rest des Systems ist aber solide. Der Weg: die klar abgegrenzten Komponenten identifizieren, die neu gebaut werden müssen, und sie chirurgisch ersetzen, ohne anzufassen, was funktioniert.
• Kompletter Neustart: Der Business Case hat sich so stark verändert, dass das bestehende System das falsche Problem löst, oder die Architektur passt so grundlegend nicht zu den Anforderungen, dass keine gezielte Arbeit die Lücke schließen kann. Ein Neustart ist selten gerechtfertigt. Ist er es aber, dann ist Aufschieben die teuerste aller Entscheidungen.

Warum die Engineers neu schreiben wollen

Engineers, die seit Monaten in einer schwierigen Codebasis arbeiten, entwickeln eine ganz bestimmte Art von Frust. Sie kennen jeden Irrweg in der Geschichte des Systems. Sie wissen, welche Module man nur mit Angst anfasst und warum. Sie wissen, dass der Test, der ständig fehlschlägt, ein Verhalten prüft, das niemand absichtlich so festlegen würde. Sie wollen neu schreiben, weil sie klar sehen, wie das System hätte gebaut werden sollen.

Dieses Wissen ist echt und sollte nicht abgetan werden. Doch der Impuls zum Neuschreiben reagiert auf die angehäuften Kosten des bestehenden Systems, ohne die Kosten für den Bau eines Ersatzes vollständig einzurechnen. Das bestehende System funktioniert, so schmerzhaft es auch ist, bis zu einem gewissen Grad. Es hat Nutzer, Daten, Integrationen und Sonderfälle, deren Entdeckung Jahre gedauert hat. Ein Rewrite macht all das zunächst unsichtbar und entdeckt es dann Stück für Stück neu, meist in der Produktion.

Bei den Problemen haben die Engineers recht. Wie lange ein Ersatz dauert und wie viele der alten Probleme in neuer Form wiederkehren, schätzen sie meist falsch ein.

Warum die Führung einen Rewrite fürchtet

Führungskräfte, die schon einen gescheiterten Rewrite erlebt haben, tragen ganz bestimmte Narben. Sie haben gesehen, wie ein Projekt, das sechs Monate dauern sollte, drei Jahre dauerte. Sie haben gesehen, wie eine Migration, von der Nutzer nichts merken sollten, den Service sechs Monate lang verschlechterte. Sie haben gesehen, wie das zweite System nach zwei Jahren Arbeit immer noch nicht den Funktionsumfang des ersten erreichte.

Auch diese Angst ist berechtigt. Die Erfahrungswerte zu groß angelegten Rewrites sind wirklich schlecht. Das typische Muster des Scheiterns (funktionierende Software wegwerfen und dann feststellen, dass die Funktionalität darin komplexer und korrekter war als gedacht) ist zu oft vorgekommen, um es als Einzelfall abzutun.

Der Second-System-Effekt

Fred Brooks hat den Second-System-Effekt 1975 benannt: Engineers, die ein erstes System erfolgreich gebaut haben, übernehmen sich beim zweiten oft, weil sie jede Funktion und jede Idee einbauen, die sie beim ersten bewusst weggelassen haben. Bei einem Rewrite zeigt sich der Effekt in einer bestimmten Form: Das Team baut jede Verbesserung ein, die es schon immer machen wollte, entwirft für jeden Sonderfall, den das alte System schlecht gelöst hat, und plant Skalierung und Flexibilität ein, die das neue System auf Jahre nicht brauchen wird.

Das Ergebnis ist ein System, dessen Bau zwei- bis dreimal so lange dauert wie eine originalgetreue Nachbildung und das schwerer zu verstehen und zu warten ist als das alte System oder ein einfacher Ersatz. Das zweite System erbt die Komplexität der Funktionen des ersten und packt die Komplexität seiner eigenen Ambitionen obendrauf.

Fixierung auf Funktionsgleichheit

Das umgekehrte Scheitern ist ebenfalls häufig. Ein Team, das ein System neu bauen soll, beschließt, vor dem Launch jede Funktion des bestehenden Systems nachzubauen. Es verbringt Monate damit, exakte Kopien von Funktionen zu bauen, die fast niemand nutzt. Zu spät stellt es fest, dass das Verhalten des bestehenden Systems in Sonderfällen nirgends dokumentiert war. Es ist über Jahre aus Produktionsvorfällen und manuellen Eingriffen gewachsen, und wer es nachbilden will, muss das alte Verhalten aus dem alten Code rekonstruieren.

Wer auf Funktionsgleichheit fixiert ist, behandelt das bestehende System als Spezifikation. Doch das bestehende System ist eine unvollständige, historisch gewachsene und teils widersprüchliche Spezifikation. Wer es zum Ziel macht, erbt seine Zufälle ebenso wie seine Absichten.

Die sechs Faktoren auf die Entscheidung für einen Neubau anwenden

Dieselben sechs Faktoren, mit denen Sie entscheiden, ob ein Projekt noch zu retten ist, bestimmen auch, welcher der vier Wege der richtige ist. Auf die Frage „Retten oder neu bauen?“ angewendet, sieht das so aus.

Geschäftswert: Wenn sich der Business Case für das Produkt grundlegend geändert hat (der Markt hat sich verschoben, der Anwendungsfall ist ein anderer, die Integrationsanforderungen passen nicht mehr zur bestehenden Architektur), behandelt eine Stabilisierung nur ein Symptom. Ein Neubau oder Neustart ist dann womöglich der einzige Weg zu einem System, das das Unternehmen tatsächlich braucht.

Restarbeit: Wenn das Projekt tatsächlich zu 40 % fertig ist und die restlichen 60 % eine grundlegend andere Architektur brauchen als die vorhandenen 40 %, ist es meist schneller, die unfertigen Teile gezielt neu zu bauen, als den bisherigen Ansatz zu Ende zu bringen und danach neu zu bauen. Ist das System zu 80 % fertig und seit Jahren in Produktion, ist ein kompletter Neustart wirtschaftlich fast nie sinnvoll.

Architektur: Das ist meist der entscheidende Faktor. Ein System, dessen Architektur die Änderungen, die das Unternehmen braucht, nicht sicher aufnehmen kann (nicht irgendwann, sondern in den nächsten 12 Monaten), ist ein Kandidat für gezielten Neubau oder Modernisierung. Die Frage ist nicht, ob die Architektur elegant ist, sondern ob ein Entwickler eine notwendige Änderung umsetzen kann, ohne das ganze System zu verstehen. Lautet die Antwort Nein, wird jede künftige Funktion mehr kosten, als sie sollte.

Leistungsfähigkeit des Teams: Ein Team, das ein System gebaut hat, das es selbst nicht mehr versteht, ist ein anderes Problem als ein Team, das das System versteht, aber auf eine Weise arbeiten soll, die nicht zur Struktur des Systems passt. Das Erste ist ein Grund für einen Neubau, weil das Wissen im Unternehmen, das für eine sichere Wartung nötig ist, nicht mehr existiert. Das Zweite ist ein Grund, die Organisation umzubauen, nicht das System.

Dienstleisterrisiko: Wenn ein Dienstleister die Codebasis, die Zugänge und den Deployment-Prozess in der Hand hat, steht eine Rettung womöglich gar nicht zur Wahl, denn der Dienstleister entscheidet, ob eine Stabilisierung möglich ist. In diesem Fall ist ein Neubau manchmal der einzige Weg, die Kontrolle über das System zurückzugewinnen.

Time to Market: Ein gezielter Neubau dauert länger als eine Stabilisierung und kürzer als ein kompletter Neustart. Wenn eine harte Deadline jeden Weg ausschließt, der länger als 90 Tage dauert, bleibt nur die Stabilisierung. Dann lautet die Frage, welcher Umfang an Stabilisierung innerhalb dieser Grenze machbar ist.

Was jeder Weg tatsächlich kostet

Die Stabilisierung gilt oft als sichere, konservative Wahl. Bei einem System mit solidem Fundament stimmt das. Bei einem System mit grundlegenden Architekturproblemen ist sie weder sicher noch konservativ, sondern ein Aufschub, der auf die bestehenden Schulden noch Zinseszins packt.

Der Neubau gilt oft als mutige, moderne Wahl. Bei einem System, das sich tatsächlich nicht stabilisieren lässt, kann das stimmen. Liegen die Probleme aber bei Prozessen und Verantwortlichkeiten statt in der Architektur, reproduziert ein Neubau dieselben Probleme in einer neuen Codebasis, meist innerhalb von 18 Monaten.

Teuer ist nicht die Wahl des falschen Wegs. Teuer ist es, sich für irgendeinen Weg zu entscheiden, bevor die Belege vorliegen: bevor die Architektur unabhängig geprüft, die Leistungsfähigkeit des Teams ehrlich bewertet und der Business Case mit den heutigen Zahlen neu gerechnet wurde. Die Frage „Retten oder neu bauen?“ lässt sich nicht verlässlich von innen beantworten, also nicht von den Menschen, die das Projekt gebaut haben.

So treffen Sie die Entscheidung

Beginnen Sie mit dem Faktor Architektur, denn er ist am aussagekräftigsten und am besten überprüfbar. Ein Architekt, der nicht an der Geschichte des Projekts beteiligt war, kann meist innerhalb einer Woche beurteilen, ob die aktuelle Architektur die notwendigen Änderungen sicher aufnehmen kann. Lautet die Antwort Ja, ist die Stabilisierung sehr wahrscheinlich der richtige Weg. Lautet sie Nein, entscheiden die übrigen Faktoren, ob ein gezielter Neubau oder ein kompletter Neustart sinnvoller ist.

Rechnen Sie dann den Business Case nüchtern neu, als würden Sie ihn zum ersten Mal bewerten: mit den heutigen Kosten für einen Ersatz, den heutigen Marktbedingungen und ohne Vorgeschichte. Hält der Business Case diesem Test nicht stand, ist keiner der beiden Wege wirtschaftlich sinnvoll. Dann geht es nicht mehr um Retten oder Neubauen, sondern darum, ob Sie überhaupt weitermachen.

Kann die Architektur die nötigen Änderungen tragen und hält der Business Case, ist die Stabilisierung fast immer der richtige erste Schritt, selbst wenn der Code wehtut und die Engineers frustriert sind. Eine Stabilisierung mit einem parallelen Plan, die am stärksten bremsenden Komponenten zu modernisieren, ist fast immer schneller und günstiger als ein Neubau. Und sie bewahrt die über Jahre gewachsene Korrektheit des Produktivsystems, statt sie mühsam neu entdecken zu müssen.