Softwarewartung – das ungeliebte Kind

Was soll ich mich um diese Klassen kümmern? Das hat wer anderes vor vier Jahren verbrochen! Ich befasse mich lieber mit den aktuellen Themen.“ So oder ähnlich klingt es häufig, wenn es um die Wartung alter Teile unserer Software geht. Legacy ist nicht sexy. Der eigenen Weiterentwicklung und der Karriere wird das wohl kaum nützen. Doch weit gefehlt. Betriebswirtschaftlich ist der Umgang mit den Legacy-Teilen unserer Software von sehr großer Bedeutung. Und besonders anspruchsvoll sind die Wartungsaufgaben auch häufig. Ich denke, hier lohnt ein genauerer Blick.

Wartung ist nicht Bugfixing

Erst einmal gilt es zwischen Wartung und Bugfixing zu unterscheiden. Fehler in bestehender Software zu korrigieren ist eine Pflichtaufgabe für ausnahmslos jedes Teammitglied aus den Entwicklungsteams. Erst recht, wenn ein Fehler erst durch die Anwender gefunden wurde und nicht schon im Rahmen der vorhergehenden Qualitätssicherungsmaßnahmen.Die Wartung von Software beinhaltet aber andere Aufgaben als reine Fehlerkorrekturen. Es ist sogar so, dass Fehlerkorrekturen oft Auslöser für spätere Wartungsaufgaben sein können. Viel zu oft sind die Lösungen von heute die Probleme von morgen. Doch was ist denn nun eigentlich Softwarewartung?Verlassen wir kurz die Softwareentwicklung und betrachten wir die Wartung von Kraftfahrzeugen. Meist einmal pro Jahr kommt ein Auto in die Werkstatt zur Inspektion. Das Öl wird gewechselt und Verschleißteile nach dem Plan des Herstellers getauscht, bevor sie kaputt gehen und größeren Schaden anrichten können. Die Fahrzeugsoftware wird aktualisiert, falls dies nicht bereits über andere Wege erfolgt ist. Kommt es hingegen zu einem Fehler, der eine dringliche Lösung erfordert, zum Beispiel mit den Airbags, so wird dies durch einen Rückruf in die Werkstätten gelöst. Der Wagen kommt zusätzlich zur Inspektion in die Werkstatt und der Fehler wird behoben.Kommen wir zurück zur Softwareentwicklung (wiewohl so manches Auto heutzutage eher ein rollender Computer ist). Die Fehlerbehandlung verhält sich bei uns ähnlich, doch wo findet die Softwareinspektion statt? Software verschleißt doch nicht wie ein Bremsbelag.Über die Softwarewartung halten wir unsere Software am Leben. Die Analogie zum Verschleiß sind die technischen Schulden (siehe Kasten Technische Schulden), die zum Beispiel bei den Fehlerkorrekturen gemacht werden. Mit diesen verhält es sich genauso wie mit echten Schulden: Wir müssen sie mit Zinsen zurückzahlen. Doch es gibt noch viel mehr! Das Softwareumfeld verändert sich. Offensichtlich ist dies bei Betriebssystemen und Browserversionen. Gerade besonders erfolgreiche Software wird hier über die Jahre immer wieder auf den neuesten Stand gebracht.

Brown oder Green Field?

Verlassen wir für einen Augenblick noch einmal die Softwareentwicklung und widmen uns etwas Handfestem, den Verkehrs- und Städtebauprojekten. Die meisten, die schon einmal in Berlin waren, kennen ihn, den Berliner Hauptbahnhof. Auch vom DB-Projekt Stuttgart 21 werden die meisten gehört oder gelesen haben, selbst wenn sie noch nie in Stuttgart waren. Zwei Projekte, wie sie unterschiedlicher nicht sein könnten. Der Berliner Hauptbahnhof gilt als Erfolgs­story für Großprojekte, Stuttgart 21 ist eher ein Beispiel, wie Geld verbrannt wird. Was sie gemeinsam haben? Den Projektleiter Hany Azer [1].Wie kann das sein? Azer ist ein Projektleiter mit enormer Erfahrung, zahlreichen Erfolgen und Auszeichnungen. Die Antwort liegt in den Projekten: Sie sind im Kern vollkommen verschieden. Der Berliner Hauptbahnhof ist quasi auf der grünen Wiese entstanden. Stuttgart 21 dagegen ist ein klassisches Brown-Field-Projekt. Der Bahnhof und seine meist unterirdisch geführten Anbindungen liegen mitten in bestehender Infrastruktur. Allein die Anzahl der Stakeholder steigert sich dadurch enorm.Es braucht also unterschiedliche Fähigkeiten, um Green- und Brown-Field-Projekte zum Erfolg zu führen. Zumindest müssen wir uns über die Unterschiede und die dazu passenden unterschiedlichen Lösungswege im Klaren sein.Kommen wir zurück in unser Metier. Natürlich sind Neuentwicklungen anspruchsvoll. Diverse größere und kleinere Entscheidungen gilt es zum richtigen Zeitpunkt zu treffen, um den späteren Erfolg sicherzustellen. Doch verglichen mit der Wartung und Erweiterung eines bestehenden, in Betrieb befindlichen Projekts sind die Abhängigkeiten um ein Vielfaches geringer. Wartung ist ein Brown-Field-Projekt!

Wartung ist extrem komplex

Aus dem Zusammenspiel von Fehlerkorrekturen und der Behebung technischer Schulden im Rahmen eines Brown-Field-Projekts ergibt sich eine enorme Komplexität. Wie können wir mit dieser Komplexität erfolgreich umgehen? Indem wir den Inspect-and-adapt-Zyklus (Bild 1) am Laufen halten und regelmäßige Lernschleifen aufsetzen [2]. Viele der dabei zu diskutierenden Aspekte betreffen architekturelle Themen, wie sie vor ein paar Monaten hier in zwei Artikeln vorgestellt wurden [3][4].

Die Rolle der Lead Developer beziehungsweise Architekten umfasst daher verschiedene Aufgaben im Lernprozess der eigenen Organisation (Bild 2). Sie können Moderatoren, Experten, Gutachter oder Coaches sein, die mit den Teams direkt daran arbeiten, die Wartungsthemen umzusetzen, daraus zu lernen und das Gelernte gezielt in der Organisation zu verteilen [5]. Für diese anspruchsvolle Rolle braucht es die besten Softwareentwickler, die wir bekommen können. Es geht nicht nur darum, technische Themen bis ins kleinste Detail zu durchdringen, sondern es gilt auch, aktiv als Multiplikator dafür zu sorgen, dass die Kollegen und Teams Sprint für Sprint besser werden.

Wartung – Lernen im Großen

Dieser Lernprozess aus Bild 2, der für die Teams den Kern der Wartung ausmacht, ist umfangreich. Gemeinsam mit den ­Scrum Mastern beziehungsweise Agile Coaches kann die Entwicklung zu einer lernenden Organisation vorangetrieben werden [5]. Die Wartung bildet dabei einen zentralen und dauerhaften Ausgangspunkt. Hier lernen wir wirklich, was unsere Software ausmacht und wie die Wertschöpfung der Anwender vonstattengeht.Damit ist die Wartung ein Kernelement der Wirtschaftlichkeit unserer Arbeit. Das gilt im Besonderen für Softwareprodukt- und Inhouse-Entwicklungen. Um ein Produkt auf den Markt zu bringen, braucht es vielleicht ein bis zwei Jahre. Wenn es erfolgreich ist, wird es mehrere Versionen durch­laufen und über zehn Jahre in der Weiterentwicklung und Wartung sein. Um den Preis für die Lizenzen konkurrenzfähig zu halten, darf uns der Wartungsaufwand über lange Zeit nicht durch die Decke gehen. Im Gegenteil muss er trotz aller Unwägbarkeiten plan- und kalkulierbar bleiben. Das schaffen wir nur, wenn wir unsere Software im Griff haben.Was bedeutet das? Wir müssen unser Softwareprodukt auf allen Ebenen verstehen. Das betrifft auch Konzepte, die vielleicht bereits zehn Jahre alt oder noch älter sind und unter ganz anderen Rahmenbedingungen umgesetzt wurden. Die Dokumentation der Architektur und der getroffenen Entscheidungen [6] ist hier ebenso von Bedeutung wie die Analysierbarkeit und Testbarkeit des Codes [2]. Und da wir in der Regel mit mehreren Teams gemeinsam entwickeln, müssen wir auch die Kommunizierbarkeit dieser Themen sicherstellen. Nur so ist es möglich, gemeinsam sinnvolle Entscheidungen zu treffen und gemeinsam zu lernen.

Bugfixing – Lernen im Kleinen

Und was ist mit Bugfixing? Hier geht es meist darum, das Verhalten der Software „im Kleinen“ zu verändern. Diese Codeanpassungen verändern aber weder die Spezifikation der Software noch fügen sie neue Funktionalität hinzu. Auch hier gilt es für jede beteiligte Person zu lernen. Die Lernfelder liegen jedoch im Vergleich zur Wartung eher in der konkreten Implementierung oder aber im Verstehen der Anforderungen an die Software.Auch hierbei findet Lernen statt. In der Verantwortung des jeweiligen Entwicklers, der eine Korrektur vornimmt, liegt es dabei, das Team über neue Erkenntnisse zu informieren. Das kann zum Beispiel auf den täglichen Standup-Meetings erfolgen. Im Rahmen übergeordneter Verfahren wie ­Scrum of Scrums können dann wertvolle Informationen in die anderen Teams fließen.

Offener Umgang mit Schwächen

Damit das skizzierte Vorgehen in der Wartung und im Bugfixing funktioniert, braucht es einen konstruktiven Umgang mit den neuen Erkenntnissen. Sowohl die Wartung wie auch das Bugfixing werden offen und transparent auf den Taskboards über entsprechende Aufgaben verwaltet, geplant und nachverfolgt. Das erfordert eine ganze Menge an Selbstreflexion und Selbstbewusstsein von allen Beteiligten und einen offenen, angstfreien Umgang miteinander.Wir erkennen, dass getroffene Entscheidungen jetzt nicht mehr passen und dass einzelne Personen fehlerhaft gearbeitet haben. Jetzt konstruktiv zu bleiben und aktiv an der Lösung von Problemen zu arbeiten, kann den einzelnen Personen viel abverlangen. Man ärgert sich schnell über sich selbst und andere. Hier sind vor allen Dingen die Führungskräfte gefordert, Beschuldigungen und Schuldzuweisungen sofort zu unterbinden und auf keinen Fall als schlechtes Vorbild voranzugehen. Zu einfach ist es, seinem Ärger Luft zu machen. Hier wird von jedem ein hohes Maß an Selbstbeherrschung gefordert.Der Lohn ist jedoch enorm. Eine Software flexibel und erweiterbar zu halten, auf Wechsel bei den Rahmenbedingungen wie Betriebssysteme, Architekturkonzepte und so weiter schnell reagieren zu können und die Softwarefehlerquote langfristig niedrig zu halten, ist nicht nur wirtschaftlich sinnvoll, sondern macht auch noch richtig viel Spaß.

Fazit

Das Wartung und Bugfixing einen schlechten Ruf haben, ­begrenzt nicht nur die Lernfähigkeit einer Organisation, sondern ist auch in wirtschaftlicher Hinsicht hoch riskant.Es mag zu Beginn sehr aufwendig erscheinen, sich mit den qualifiziertesten Personen den Wartungsthemen zu widmen. Ich bin aus ­eigener Erfahrung jedoch fest davon überzeugt, dass es sich nicht nur wirtschaftlich lohnt, sondern darüber hinaus dafür sorgt, dass das Lernen innerhalb der Softwareentwicklung gestärkt und die Lösungskompetenz jedes einzelnen Teammitglieds erhöht wird. Beides sind zentrale Eigenschaften einer agilen Entwicklung. Wenn wir dies ignorieren, verschenken wir nicht nur die langfristige Zukunft unseres Softwareprodukts, sondern wir demotivieren auch noch die Menschen im Team.

Fussnoten

1. Neue Struktur und Leitung für Bahnprojekt Stuttgart–Ulm, Bahnfahren.info, http://www.dotnetpro.de/SL2309Softwarewartung1
2. Uwe Vigenschow, APM – Agiles Projektmanagement, dpunkt.verlag, 2015,
3. Hendrik Lösch, Attila Bertok, Architektur blitzblank, dotnetpro 3/2023, Seite 28 ff., http://www.dotnetpro.de/A2303CleanArchitecture
4. Hendrik Lösch, Attila Bertok, Architektur blitzblank, dotnetpro 4/2023, Seite 26 ff., http://www.dotnetpro.de/A2304CleanArchitecture
5. Uwe Vigenschow, Lernende Organisationen, dpunkt.verlag, 2021,
6. Stefan Zörner, Softwarearchitekturen dokumentieren und kommunizieren, 3. Auflage, Carl Hanser, 2021,
7. Ward explains debt metaphor on YouTube, http://www.dotnetpro.de/SL2309Softwarewartung2
8. Was sind technische Schulden?, Wissen kompakt, t2informatik, http://www.dotnetpro.de/SL2309Softwarewartung3