Knigge für Softwarearchitekten: Fortschritt oder Verschlimmbesserung?

Bevor wir Ihnen die Auswege aus dieser Misere verraten, wollen wir Ihnen die beiden Dimensionen aufzeigen, auf die es bei jeder Verbesserungen ankommt. Meistens wollen wir ein System im Laufe der Zeit durch zusätzliche fachliche Funktionalität verbessern, die Performanz steigern oder die Benutzerfreundlichkeit erhöhen. Wir nennen das „äußere Qualitäten verbessern“, weil man dem Produkt diese Eigenschaften quasi von außen ansehen kann.

Andererseits könnten wir daran arbeiten, die innere Qualität unserer Systeme systematisch zu verbessern. Dafür sorgen, dass der Source-Code sauber gehalten wird, die Modularität verbessert wird, die Wiederverwendbarkeit für zukünftige Systeme einen hohen Stellenwert bekommt oder dass die Dokumentation aktuell bleibt und neue Mitarbeiter sich leicht einarbeiten können. Als Entwickler wünschen wir uns solche Verbesserungen der zweiten Art.

Lesen Sie auch: Knigge für Softwarearchitekten: Der Flexibilisator

Wir schaffen es zwar meistens, unter Druck, die von Kunden, Auftraggebern oder Management gewünschten – wir sollten besser sagen „verlangten“ – neuen Features und Performanzverbesserungen zu liefern, aber oft auf Kosten der inneren Qualität. Das bedeutet: Wir steigern unter Zeitdruck äußere Qualitäten auf Kosten der inneren Qualitäten. Die Komplexität steigt, es bleibt keine Zeit zum Refactoring und technische Schulden wachsen immer weiter. Kurzum, die Erweiterbarkeit, Änderbarkeit und Verständlichkeit unseres Systems wird immer schlechter (Abb. 1)

Abb. 1: Zwei Dimensionen der Verbesserung

Wenn die innere Qualität abnimmt, dann wird Ihr Management schnell feststellen, dass die Kosten pro geliefertem Feature von Release zu Release drastisch steigen. Wir können nicht mehr so produktiv arbeiten wie früher, das EntwicklerInnen-Leben wird ständig schwerer [1].

Wegen sinkender Codequalität, mangelnder Modularität, zu starker Kopplung sowie fehlender Homogenität – aka konzeptioneller Integrität – werden auch kleine Änderungen zunehmend zum Vabanquespiel. Selbst kleine Änderungen führen zu ungewollten Seiteneffekten, weil die übermäßige Komplexität den systematischen Überblick über das System zuverlässig verhindert. Für neue Features brauchen wir viel länger als früher, bis sie endlich laufen. Abbildung 2 zeigt diesen desaströsen Effekt. Wir betrachten diesen Verlauf der Grafik als traurigen Normalfall.

Abb. 2: Features werden im Lauf der Zeit teurer

Verbesserer, Verschlimmbesserer und Chaoten

Betrachten wir anhand der Achsen aus Abbildung 1 die möglichen Änderungen an einem System nochmals systematisch (Abb. 3) und beginnen mit den grünen Pfeilen. Natürlich wäre es für alle Beteiligten schön, wenn die Richtung 1 wahr wäre: Wir schaffen äußere Qualitäten, also neue Features oder mehr Performanz, und verbessern so nebenbei auch noch die innere Ordnung. Wenn das mit der gleichzeitigen Verbesserung der inneren Qualität nicht klappt, wollen wir wenigsten auf gleichem Niveau bleiben (Pfeil 2). Als Entwicklungsteam bauen wir keine neue Komplexität ein, behalten anständige interne Schnittstellen und passabel sauberen Code.

Abb. 3: Über Verbesserungen und Verschlimmbesserungen

Architekten und viele Entwickler lieben Variante 3: Gezielte Verbesserung der inneren Ordnung, Abbau technischer Schulden, bessere Modularisierung und Reduktion von Kopplung und Komplexität. Damit erleichtern wir unser zukünftiges Leben mit dem System. Solche Änderungen schaffen keine direkten Businessvorteile, sprich neuen Funktionen. Viele kurzfristig denkende Manager, Projektleiter oder Auftraggeber stehen diesem Vorgehen skeptisch gegenüber, weil sie nach außen nichts Neues verkaufen können. Falls Sie als Architekt oder Entwickler solche Vorschläge unterbreiten, bekommen Sie zu hören: „Das ist doch Geld- und Zeitverschwendung“. Streben Sie deshalb lieber die Variante 1 an, also die Verbesserung äußerer und innerer Qualität. Damit verbessern Sie im Inneren, geben aber dem Business gleichzeitig auch ein paar Goodies.

Kommen wir nun zu den gelben Pfeilen, den Aktionen der Verschlimmbesserer. Variante  4 treffen wir in der Praxis am häufigsten an: Wir müssen unter Zeitdruck neue Features liefern. Koste es, was es wolle. Die Verschlechterung der inneren Qualität fällt ja erst mit zeitlicher Verzögerung auf, aber die funktionale Verbesserung sieht man sofort. Denken Sie stets an die desaströse Langzeitwirkung aus Abbildung 2. Lange können Sie solche Änderungsstrategien nicht durchhalten.

Etwas ungewöhnlicher ist Variante 5. Hier entscheiden wir uns gezielt, die innere Qualität zu verbessern, z. B. durch Einführen neuer Technologien, Neustrukturierung signifikanter Systemteile, Entfernen unnötiger Abhängigkeiten, Säuberung von Code oder Reduktion technischer Schulden. Leider schaffen wir es aber nicht, sofort die vollständige, vorher vorhandene äußere Qualität aufrecht zu erhalten, z. B. die Funktionalität oder die Performance. Aus der Businessperspektive bedeutet Variante 5 zumindest kurzfristig eine deutliche Verschlimmbesserung. Wir halten das als Zwischenlösung auf dem Weg zu einem aufgeräumten Produkt manchmal für sinnvoll, wenn auch schmerzlich.

Die roten Pfeile haben wir nur wegen der Vollständigkeit mit aufgenommen, denn wir halten sie für pathologische Fälle. Wir setzen Maßnahmen um, die äußere Qualitäten schwächen und gleichzeitig nichts an inneren Qualitäten verbessern oder diese sogar verschlechtern. Solche Änderungen würde doch niemand ernsthaft in Erwägung ziehen. Es sei denn, unser Spieltrieb ist mit uns durchgegangen und wir haben das Risiko von Änderungen unterschätzt.

Verbessern, aber richtig!

Um systematisch zu verbessern und Verschlimmbesserung zu verhindern, schlagen wir folgenden dreistufigen, iterativen Prozess vor [2], [3]: Bevor Sie mit Verbesserungen oder Änderungen loslegen, sollten Sie zunächst Ihre momentanen Schmerzen und Risiken aufschreiben. Etwas formaler nennen wir das Analyze-Phase oder „Erstellen einer Issue-Liste“. Issues können beispielsweise Fehler im System sein, ungeeignete Technologien, überhöhte Kopplung oder schlechte Schnittstellen. Andererseits gehören auch mangelnde Sicherheit, Stabilität, Performance oder fehlende Systemfunktionalität dazu, ebenso ungeeignete Betriebs- oder Entwicklungsprozesse.

Schätzen Sie in der Evaluate-Phase danach für jeden Issue die Höhe des Schadens oder die Höhe des Businesswerts ein. Wir wissen, das hört sich zuerst schwierig bis unmöglich an. Finden Sie heraus, wie oft Sie etwas tun müssen, um einen derzeitigen Issue zu behandeln, wie lange Sie dafür brauchen, wie viele Personen betroffen sind oder wie viel Geschäft Ihnen verloren geht (pro Monat/pro Jahr/pro Eintreten des Problems). Grobe Schätzungen genügen. Am besten geben Sie diese Schätzungen in Intervallen an und verwenden Geld oder Zeit als Einheiten. Denn diese Größen versteht Ihr Management.

Abb. 4: Architecture Improvement Method AIM42 [2]

Schließlich dürfen Sie in der Improve-Phase für Ihre Issues mögliche Verbesserungen (Improvements) vorschlagen. Normalerweise finden wir für jeden Issue recht schnell eine Reihe von Möglichkeiten, diesen zu beseitigen. Bewerten Sie dann für jede Improvement-Maßnahme, wie viel Aufwand und Geld deren Umsetzung kosten würde. Das sind dann die verbreiteten, klassischen Aufwandsschätzungen.

Lesen Sie auch: Knigge für Softwarearchitekten: Die Agilitekten

Und jetzt bitte aufmerksam weiterlesen: Verbessern Sie nur, wenn die Improvement-Kosten deutlich kleiner sind als die Schmerzkosten. Durch diesen Vergleich finden Sie heraus, ob Ihre Improvement-Maßnahmen überhaupt durchgeführt werden sollten. Außerdem sehen Sie so, ob sie in die wünschenswerten Richtungen der Windrose von Abbildung 3 gehen, also sowohl äußere wie innere Qualitäten verbessern.

Software irgendwie ändern ist leicht. Sie gezielt so zu ändern, sodass dabei äußere und innere Qualitäten im Einklang bleiben, erfordert ein bisschen mehr nachdenken. In diesem Sinne wünschen wir Ihnen erfolgreiches Architecture Improvement.