Wie verhindert man, dass nutzlose Legacy-Systeme entstehen?

Die einzige Möglichkeit, diesen Teufelskreis zu durchbrechen ist, ihn an der Quelle zu bekämpfen - dem Mangel an Vertrauen in die Durchführung von Änderungen. Ich habe gesehen, wie ein Team das geschafft hat, indem es schlicht manuelle Tester eingestellt hat, die alle Änderungen vor dem Einsatz gründlich (manuell) testen sollten. Das verlangsamt zwar die Iterationszeiten und bringt höhere Personalkosten mit sich. Aber zumindest durchbricht es den Teufelskreis.

Der häufigere und ideale Weg, ist jedoch, in automatisierte Tests, schrittweises Ausrollen und die automatische Überwachung und Warnung bei Fehlern im Produktionsbetrieb zu investieren.

Es kostet viel Zeit und Mühe, automatisierte Tests als First-Class-Objekt im Entwicklungsprozess zu etablieren - vor allem, um die Werkzeuge zu entwickeln, die für qualitativ hochwertige Integrations- und End-to-End-Tests erforderlich sind. Aber die Vorteile sind enorm, denn die Entwickler müssen dann eben nicht mehr Unmengen an Zeit für manuelle Tests aufwenden.

Schrittweises Ausrollen und bessere Warnungen im Produktionsbetrieb können Bugs vielleicht nicht verhindern, aber sie können enorm dazu beitragen, sie zu entschärfen. Bei Unternehmen wie Amazon und Google werden neue Software-Builds oft erst mal nur auf einer Maschine bereitgestellt. Einer Maschine, die sich in der Produktionsreihe befindet und den Produktionsverkehr bedient, genau wie der Rest der Maschinen. Nach einer gewissen Zeit wird der Build dann inkrementell auf immer mehr Rechnern bereitgestellt, bis er schließlich auf allen zum Einsatz kommt.

Das lässt sich besonders gut mit automatischen Warnungen kombinieren. Mit einer Fail-Fast-Methode und einer Code-Konfiguration, die bei solchen Fehlern automatisch Alarm schlägt, werden Bugs schnell entdeckt - und nicht erst Wochen oder Monate später, wenn die Kundenbeschwerden hereinkommen. In Verbindung mit einem schrittweisen Ausrollen können neue Builds auf nur wenigen Rechnern freigeben werden. Es wird überprüft, ob ein Alarm ausgelöst wird, und wenn das so ist, wird das Ausrollen zurückgenommen. So wird nur ein winziger Bruchteil der Nutzer betroffen sein - was nicht ideal, aber um Längen besser ist als die Alternative.

Sich überwinden

Wenn sich ein Team bereits in dem besagten Teufelskreis befindet, kann es sehr schwer sein, daraus auszubrechen. Die oben genannten Lösungen liefern an und für sich keinen Geschäftswert - man schiebt sie also lieber auf die lange Bank. Es ist schwer zu rechtfertigen, viel Zeit für das Testen, Überwachen und Bereitstellen von Verbesserungen für ein funktionierendes Legacy-System aufzuwenden, wenn das Marketingteam gleichzeitig darauf drängt, das nächste Killer-Feature herauszubringen, das die Nutzer begeistern und die Konkurrenz ausstechen wird.

Aus der Schleife auszubrechen, kann mit gemeinsamen Anstrengungen und mit Investitionen gelingen. Allerdings ist das den meisten Wartungsteams nur selten gegeben. Sie drehen sich also immer weiter und weiter in der Schleife ... bis alles so schlecht ist, dass beschlossen wird, das ganze Ding zu verwerfen und von Grund auf neu zu schreiben. An diesem Punkt wird ein Legacy-System in den Ruhestand versetzt und das nächste Legacy-System wird geboren.