5 falsche Einschätzung bzgl. Refactoring versus Renewal
Ist Refactoring vs. Renewal eine reine Kostenfrage…?
Irgendwann gelangt man an einen Punkt in einem alten Projekt das „gewachsen“ ist, an dem Fehler in großer Zahl nach Änderungen auftreten und vor allem Änderung maßgeblich aufwändig werden. Der Kunde (egal ob intern oder extern) hat kein Verständnis und das Developer Team gelangt immer mehr in Erklärungsnotstand, warum scheinbar kleine Ergänzungen Tage bis Wochen an Codebasteln und manuelles Testen in Anspruch nehmen.
Ein anderes Szenario ist folgendes. Die Firma die das bestehende System entwickelt hat fällt weg. Der Grund ist unwichtig, oft aber eine Unzufriedenheit wegen des fehlenden Zahlungswillen großer Summen bei kleinen Änderungen des Auftraggebers. Eine neue Firma wird gesucht und alle ausgesuchten Kandidaten kommen zum selben Ergebnis: Das Projekt muss ganz neu gemacht werden. Der Code sei unverständlich, veraltet und zu risikoreich für die Übernahme des Projektes.
Kurzum man steht früher oder später vor der vermeintlichen Entscheidung, ob man das System neu aufbauen muss oder das bestehende überarbeiten kann.
Hier sind die häufigsten Argumente die für das Neuerstellen dabei ins Felde geführt werden
Die nachfolgenden Argumente klingt grundsätzlich mal alle nachvollziehbar und hören sich vorteilhaft an. Die Wahrheit liegt, wie so oft, irgendwo dazwischen und die Konsequenzen der tatsächlichen Umsetzung werden gerne außer Acht gelassen. Ich möchte zu jedem Punkt die fehlerhafte Einschätzung aufzeigen.
1. Wir hätten die Chance das Projekt endlich auf solide Beine zu stelle
Meistens wird die Vorarbeit für dieses Argument übersehen. Dazu gehört das Erfassen der Funktionen, das aufschreiben einer Dokumentation, die Befragung der Benutzer usw.
Dazu kommt der Personalmangel, da das ganze Team die bestehenden Systeme betreut. Wer macht denn dann die neue Software? Im schlimmsten Fall entscheidet man sich für eine externe Firma, das dazu führt, dass am Ende der Neuentwicklung das Team ein System übergeben bekommt, dass sie nicht kennen und frustriert ist, weil die „schöne Arbeit“ des Entwickeln von der grünen Wiese weg jemand anderer machen durfte.
2. Unit Tests könnten endlich eingeführt werden
Aufgrund der fehlenden Ressourcen werden oft wieder keine Unittests eingeführt und die Dokumentation wird wieder weggelassen. Hier findet meistens keine Verbesserung statt.
3. Die Kosten sind geringer als weiterhin den schleppenden Betrieb zu bezahlen.
Sie müssen sich vorstellen, dass der aktuelle Betrieb schon teuer ist, d.h. die Ressourcen werden zu großen Teilen bereits verwendet und ohne weiteres Personal ist das Erneuern nicht rasch durchzuführen sondern dauert womöglich Jahre. Also unterm Strich sind die Kosten für die Erneuerung meistens höher, wenn man den Betrieb mit in die Kalkulation nimmt.
4. Man kann nach dem Neubau viel leichter Änderungen oder Neuerung einzubauen
Das ist auch ganz sicher der Fall, aber es führt dazu, dass neue Features im bestehenden Betrieb nicht implementiert werden, damit man keine Arbeit doppelt macht. Da die Erneuerung aber lange Zeit in Anspruch nimmt, werden alle Kunden auf später vertröstet und die Frustration mit dem Bestandsystem steigert sich weiter.
5. Man könnte beim Neubau gleich die Features aus der Pipeline/ dem Backlog mit einbauen (und alte Features weg lassen)
Auf Platz eins der Prioritätenliste des Neubaus steht, die Wiederherstellung der Funktionen des bestehenden Systems. Bevor das neue System nicht zumindest das gleiche kann wie das alte, werden keine weiteren Funktionen ergänzt. D.h. man wartet als Kunde, ähnlich wie bei Punkt 5, sehr lange auf neue Funktionen.
Zu diesen 5 Punkten kommt die Migration der Daten vom alten in ein neues System, die dann auch parallel gepflegt werden. Wenn ein vorgegebener Stichtag näher rückt, werden wieder Notlösungen im neuen System geschaffen, damit das System zum Tag X einsatzbereit ist. Die Spirale beginnt dann von Neuem.
Nach einiger Zeit wird es dann eine Neue Version geben, die aber weder erprobt noch vollständig sein wird. Meistens entscheidet man sich dann für einen Parallelbetrieb, der noch stärker in die Ressourcen eingreifen wird, als der bisherige Parallele Entwicklungsbetrieb.
Fazit
Auch wenn Renewal gut klingt, unterm Strich ist die Umsetzung teuer und die Machbarkeit ungewiss. Eine Schrittweise und kontrollierte Überarbeitung des bestehenden Codes ist daher meistens die bessere Entscheidung.
Wir helfen Ihnen gerne bei der Strategie und Planung um ihr Legacy System wieder zu dem Value Zugpferd zu machen, dass es am Anfang war mit der Möglichkeit es sauber weiter zu entwickeln.
Further Readings
Share / Beitrag Teilen
Kontaktieren Sie uns jetzt.