Wenn dann irgendwann das Schmerzempfinden des Teams diese Situation als wenig nachhaltig signalisiert, ist guter Rat teuer.
Kann umfangreiches Refactoring aber nicht die Situation retten? Kaum. Denn wo ist der Kunde – intern oder extern –, der es aushält, dass über diese Refactoring-Maßnahmen lange kein äußerlich sichtbarer Nutzen produziert wird.
Oder vielleicht neu schreiben? Ja! Das wäre cool. Macht auch mehr Spaß, als am alten Code rumzumokeln. VB6 geht auch beim schönsten Refactoring nicht weg. Am besten während der Neuentwicklung das Brownfield mit dem kleinstmöglichen Aufwand am Leben halten. Und irgendwann wir umgeschaltet auf das strahlende Neue. Kaum. Woher sollen denn die Ressourcen kommen, die das Neue zügig vorantreiben, wenn am Alten auch noch gebastelt werden soll? Und wie ist es mit einem Termin für die Neuentwicklung?
Möglichst schnell? Dann ist es noch schwieriger mit den Ressourcen. Vor allem haben Entwickler, die Jahre lang im Korsett eines Brownfields gearbeitet haben, wenig Übung darin, ein Greenfield zu bestellen, so dass daraus nicht bald wieder ein neues Brownfield wird.
Oder darf es ruhig dauern, bis die Neuentwicklung fertig ist? Es soll ja auch was richtig Gutes rauskommen? Dann fehlt die Motivation zu häufigem Feedback. Dann ist das Risiko groß, sich in Forschung und Frameworks zu verlieren. Eine never ending story…
Nein, ich halte beide Wege inzwischen für falsch. Aus dem Brownfield kommt man durch keinen Refactoring-Gewaltmarsch heraus und auch nicht durch den großen Wurf einer kompletten Neuentwicklung.
Die Lösung liegt vielmehr darin, an das Bestehende anzubauen. Wie oben in dem Bild. Weder wurde die Villa entkernt, noch wurde sie abgerissen, um etwas Neues zu schaffen. Vielmehr wurde sie in Ihrem Wert erhalten und um etwas Neues erweitert. Das Neue ergänzt das Alte. Das Neue ersetzt in Teilen das Alte. Vielleicht doppelt es das Alte übergangsweise auch, um es schließlich abzulösen?
Ja, so sehe ich das bei der Softwareentwicklung auch.
Das Brownfield muss nicht refaktorisiert werden, um mit ihm und in ihm weitere Jahre erfolgreich zu sein. Vielmehr ist im Brownfield ein Teil zu identifizieren, der freigestellt werden kann. Nur dieser Teil wird dann neu entwickelt. Das ist überschaubar. Während der Neuentwicklung, ist die alte Version der Funktionalität im Brownfield erhalten. Aber irgendwann wird sie dort abgeklemmt, um von der Neuenentwicklung übenommen zu werden.
Die Neuentwicklung kann mit dem Brownfield über eine gemeinsame Datenbank verbunden sein. Aber darüber sollte man gut nachdenken. Besser ist es, hier wird die Chance genutzt, um auch darin aufzuräumen. Also eine neue Datenbank aufsetzen und mit der bisherigen Synchronisieren.
Nur so geht es, glaube ich. Masterpläne, die alles auf einmal richten, sei es mit Refactoring oder kompletter Neuentwicklung, sind Geldgräber. Es kommt nichts raus. Oder es dauert zu lange, als dass es die Kunden zufriedener machen würde.
Besser ist es, Sie stellen “agile Schnellbote” neben Ihren “behäbigen Schlachtschiffen”. So können Sie schrittweise Ihr Brownfield aushöhlen. Und irgendwann gibt es nur noch einen Schwarm von “Schnellboten”, die unkompliziert separat evolvierbar sind.
So funktioniert das auch mit Städten. Die werden nicht platt gemacht – außer in Kriegen. Sondern die wachsen und verändern sich Haus für Haus. Der “Schwarm an Häusern” teilt sich natürlich Infrastruktur. Das können die vielen “Software-Schnellbote” auch. Ansonsten sind sie jedoch unabhängig. Jedes für sich kann verändert oder abgerissen werden. Kein Masterplan ist nötig. Kein “Wenn wir mal Zeit haben…”. Deshalb: Strukturieren Sie Ihre Software genauso. Versuchen Sie weniger, darin etwas großartig zu verändern. Stattdessen stellen Sie lieber die Neuerung daneben – und lösen Sie auch so Altes durch Neues ab.