Follow my new blog

Donnerstag, 12. Juli 2012

Machbare Veränderungen - Daneben statt rein

imageDas Brownfield ist überall. Teams ersticken in Support, strategische Entwicklung findet nur zufällig statt, Kunden warten lange auf zugesagte Änderungen, das Backlog enthält Tausende Einträge aus mehreren Jahren. Alles schon gesehen. Und nicht nur einmal.

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.

image

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.

image

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.

image

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.

5 Kommentare:

cplussharp hat gesagt…

Schöne Beschreibung. Wir machen das schon seit Jahren so mit unserer Software. Da kann es dann auch schon mal vorkommen, das in einer alten MFC VC++6 Anwendung ein .Net3 WinForms Control und ein .Net4 WPF Control eingebunden ist. Das sieht dann zwar ein bisschen komisch aus, aber die alte Anwendung ist einfach zu komplex um sie mal schnell zu erweitern oder gar abzulösen.

Man sollte so eine Mischung meiner Meinung nach nicht zu lange hinziehen, weil auch dieses seine Nachteile haben kann. Wenn es wie bei uns dann soweit kommt, dass man krampfhaft über irgend welche COM-Schnittstellen versucht alles beieinander zu halten, tut dies der Komplexität und Wartbarkeit leider nichts gutes.

Unknown hat gesagt…

Kann ich nur bestätigen. So schafft man es auch eher mal Verbesserungen in Legacy Systemen einzubringen. Das Risiko und die Komplexität sind überschaubar.
Des Weiteren kann man so häufig auch die alte und die neue Implementierung parallel betreiben und via Konfiguration o.Ä. umschalten. Somit hat man im Fehlerfall immer noch eine Fallback Lösung und es wird für den Kunden auch attraktiver.
Natürlich sollten die alten Code Teile in Folgeversionen entfernt werden.

Unknown hat gesagt…

Sehr schön geschriebener Artikel, weil sehr anschaulich und nachvollziehbar. Danke.

Malte Finsterwalder hat gesagt…

Ich habe gerade mit einem Kollegen über den Artikel diskutiert, und wir waren uns uneins, wie man die Teile "rausschneiden" sollte, die man als Greenfield-Projekt daneben stellt.

Hast Du, Ralf, da irgendwelche Ideen zu?

Wir haben in den letzten 2 Jahren aus einer Anwendung etliche Services als eigenständige Projekte herausgezogen und sprechen diese nun aus unserer Web-Anwendung heraus an. Teile des Brownfields wurden gelöscht und statt dessen Greenfield Services erstellt.

Die Web-Schicht (die besonders verwoben ist) wurde jedoch bisher nicht in gleichem Maße aufgeräumt. Jeder Request geht also noch immer durch eine Legacy-Schicht und spricht erst in der Kernfunktionalität mit den neuen Services. Es gibt keine vertikalen Durchstiche, die komplett Greenfield sind.

Ich verstehe Deinen Artikel so, dass beides in Dein Konzept passt. Hast Du das so gemeint? Bevorzugst Du eine der beiden Vorgehensweisen? Ich sage mal vertikaler Durchstich vs. Komponenten herausschneiden.

Ralf Westphal - One Man Think Tank hat gesagt…

@Malte: Ich halte einen vertikalen Schnitt erstmal für einfacher. Da kann quasi alles neu gedacht werden. Da gibt es höchstens eine Abhängigkeit im Datenmodell.

Wenn der unterhalb einer dünnen Oberfläche ansetzt, weil es dir schwer fällt, ein GUI neben das schon vorhandene zu setzen, dann ist das ok. Besser fände ich aber die vollständige Trennung.

Eine weitere Aufteilung in Services ist was für Fortgeschrittene. Wünschenswert, doch schwieriger.