Wir bauen für Legacy

Legacy, Monolithen, historisch gewachsene Systeme, jede Software wird einmal alt. Meine Sicht auf die Dinge und Möglichkeiten damit zu leben.

Wir bauen für Legacy
Photo by Joel Moysuh / Unsplash

Legacy, Monolithen, historisch gewachsene Systeme, jede Software wird einmal alt. Wir bauen neu, um und reißen ab. Jetzt wird "alles sauber und neu", die Architektur ist "zu alt backen". All das hört man in der Softwareentwicklung sehr oft.
Historisch - oder wie ich es gerne nenne - "hysterisch gewachsene" Systeme sind der Motor vieler mittelständischer bis großer Unternehmen. Gerne wird eine neue Plattform geschaffen, um "alles richtig zu machen", nur um festzustellen, dass es am Ende auch nicht perfekt ist.

Perfection is not the goal

Perfektion ist nicht alles. Wir bauen Systeme nicht für die Ewigkeit, denn natürlich hat alles ein Ablaufdatum und kein System hält ewig. Man muss sich verabschieden von einer Realität, in der Infrastruktur unendlich erhalten werden kann. Letztlich ist alles endlich, außer der Dummheit der Menschheit, denn diese ist schließlich unendlich.


Also, warum tun wir das? Uns allen ist eigentlich bewusst, dass es kein perfektes System geben kann. Viel mehr sollte man immer sein Bestes geben und immer wieder kleine Verbesserungen veröffentlichen.
Natürlich baut man die Systeme nicht, um deren Eigenleben, sondern um dem Endnutzer, sei es jetzt ein direkter Kunde oder das Sales-Department, einen Mehrwert zu bieten. Hierbei versucht man, die Buzzwords unserer modernen Welt zu integrieren. Den neuen "geilen Shit", gute Architektur, das neueste Framework oder das neue coole Design-Pattern von Google.

Schritt zurück

Jedes System wird einmal ersetzt und das ist Fakt. Und damit sollte man sich abfinden, aber nicht deswegen schlechtere Lösungen entwickeln. Nichts ist Vergebens, die Vorgängerversion oder das vorherige Projekt erweitert den eigenen Horizont und den des Teams.
Lernen ist Key und letztendlich wird das nächste Projekt davon profitieren und dadurch nur besser.

Zyklen einberechnen

Gerade weil ein Projekt eben nicht ewig leben kann, sollte man sich ein gewisses Ziel stecken. Wie lang soll das ganze minimal funktional sein?- Sind es 3 Jahre oder eher ein Jahrzehnt?

Lang lebe der Proof of Concept

Ein Proof of Concept liefert wichtige Ergebnisse darüber, ob es sich lohnt einen Ansatz zu verfolgen. Klappt das Framework, die Technologie oder die Architektur wie man will? - Das liefert wichtige Zwischenstände und verhindert, dass ein Projekt dann scheitert, weil eben keine grundlegende Analyse stattgefunden hat. Doch was hat das mit Legacy zu tun? - Am Ende ermöglicht es einen Ausblick zu geben, ob das Projekt schon von vorneherein zum Scheitern verurteilt ist. Geht es in die komplette falsche Richtung, dann sollte man sich evtl. noch einmal neu entscheiden.
Letztlich ist das auch ein kleiner Einblick in die Zukunft desProjektes, wenn es sich schon nicht lohnt einzelne Aspekte abzudecken. Das ist wichtig, dass ein Projekt auf Dauer wartbar bleibt, oder eben bis zum Ablaufdatum.

Mindesthaltbarkeitsdatum

Ein Begriff der einem aus Lebensmitteleinkäufen bekannt ist, ist auch auf Projekte anwendbar. Denn ein Projekt ist nicht unendlich haltbar, also lohnt es sich festzulegen - Okay, das Projekt ist "mindestens 3 Jahre wartbar und erweitbar".

Mentalität

Die geistige Einstellung sollte natürlich auch passen, alle Team-Member müssen eine gute Balance finden zwischen Enthusiasmus, Entschlossenheit und Zurückhaltung. Das "neue Baby" in der Familie ist keine Ware, die nach Belieben einfach herumgeworfen kann, aber letztlich wird sie einmal erwachsen, wird ausziehen und vielleicht bei einem Autounfall sterben.

Das alles klingt jetzt etwas hart, aber bei genauerer Betrachtung macht es durchaus mehr Sinn das so zu betrachten.

Lernen "Nein" zu sagen

Nicht jedes tolle Feature sollte direkt in eine Applikation integriert werden. Die beste Systemarchitektur ist nichts Wert, wenn dann am Ende hinten "angeflanscht" wird und so ein Konstrukt entsteht, das eher einer Bestie ähnelt.

Auch bei Sachen Code-Qualität sind Code Reviews unabdingbar. Natürlich sollte das sowieso gemacht werden, doch seien wir mal ehrlich, ist dass eher die Ausnahme als die Regel. Gerade wenn eine Software länger bestehen soll, ist es wichtig, dass neuer Code "nicht schimmelt oder stinkt". Bis zu einem gewissen Grad kann das mit Code Quality KPIs gelöst werden. Doch hier zu übertreiben, führt zum negativen Effekt. Ein manuelles Review ist unabdingbar. Was automatisiert werden kann, sollte natürlich automatisch sein. Ein Reviewer soll seine Zeit nicht verschwenden, um zu prüfen, ob genug Leerzeichen in der Zeile sind. Manuelle Testausführung ist ebenso ein absolutes Anti-Pattern.

Letzte Worte

Legacy ist mehr als Teil des Lifecycles und als Möglichkeit aus Fehlern zu lernen und neu anzufangen zu sehen. Doch man sollte aufhören, das Ganze zu verteufeln oder auf fehlende Skills zu schieben. Letztlich ist alles endlich und was vor ein paar Jahren gut erschien doch nicht für die Unendlichkeit bestimmt.
Jeder sollte sich dem Verfall der Software bewusst sein, daraus resultierend realistische Ziele setzen. Auch wenn das im Business-Kontext oft Probleme bereitet und Stakeholder zur Verzweiflung treibt.