Suche
Kolumne

Knigge für Softwarearchitekten: Fortschritt oder Verschlimmbesserung?

Gernot Starke, Peter Hruschka

Ändern und erweitern unter Zeitdruck – das ist traurige Normalität für viele Softwerker. Ständig zwingen uns widrige Umstände oder dunkle Mächte dazu, mit zu wenigen Informationen oder zu wenig Zeit neue Features oder auch notwendige Änderungen suboptimal umzusetzen. Wir möchten gerne besser arbeiten, aber nur selten geben uns die dunklen Mächte die Chance dazu.

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)

Bildschirmfoto 2017-01-25 um 08.40.07

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.

Bildschirmfoto 2017-01-25 um 08.40.28

Abb. 2: Features werden im Lauf der Zeit teurer

W-JAX
Christian Schneider

Schlimmer geht immer – eine Auswahl der Top-10-Hacks der letzten Jahre

mit Christian Schneider (Christian Schneider IT-Security)

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.

Bildschirmfoto 2017-01-25 um 08.40.44

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.

Bildschirmfoto 2017-01-25 um 08.40.59

Abb. 4: Architecture Improvement Method AIM42 [2]

Ganz wichtig: Es geht beim Evaluieren um die Schätzung der Problemkosten, nicht der Lösungsaufwände! Anders ausgedrückt: Mit evaluate finden Sie heraus, wie schlimm die Probleme Ihres Systems wirklich sind und wie gravierend die Probleme in Relation zueinander sind.

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.

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.