Das neue Feature musste unter Zeitdruck programmiert werden. Den Projektplan konnten die Entwickler nur einhalten, weil sie auf gründliche Tests verzichteten. Mit Fragen von Sicherheit oder Wartung hielten sie sich nicht lange auf, vordergründig wich das mit heißer Nadel gestrickte Feature nur geringfügig vom bisherigen Qualitätsniveau ab. Monate, manchmal auch Jahre später sind Anwender wie Entwickler frustriert: das System ist langsam, es stürzt immer wieder ab, Installationen und Rollouts scheitern immer wieder, das bleibt auch dem Vorstand nicht verborgen.

Das ist eine typische Situation, die Josef Adersberger und sein Team vorfinden, wenn sie als Softwaresanitäter zum Kunden gerufen werden. "Softwareprobleme kommen schleichend. Erst wenn sie massiv werden, wird das ganze Ausmaß deutlich. Darum kommen viele Kunden erst sehr spät zu uns", sagt der technische Geschäftsführer der QAware. Der Informatiker promovierte vor elf Jahren und gründete parallel dazu mit Johannes Weigend das Unternehmen und spezialisierte sich unter anderem auf die Sanierung maroder Softwaresysteme. Das Geschäft betreiben die Münchner mit großem Erfolg: die mittlerweile 80 Mitarbeiter, davon ein Großteil Softwareingenieure, sind so zufrieden mit ihrem Arbeitgeber, dass dieser von Great Place to Work oder Kununu wiederholt als bester IT-Arbeitgeber ausgezeichnet wurde.

Marode Software: Die Diagnose ist am schwierigsten

Wie für ihre Kollegen aus der medizinischen Welt beginnt der Einsatz der Softwaresanitäter von QAware zuerst mit Fragen an die IT- und Fachabteilungen, aber auch an die Geschäftsführung des Kunden, so Adersberger: "Der Kunde hat oft ein Bauchgefühl, ob die Sanierung der Software Sinn macht oder nicht. Unsere Aufgabe ist es, nach Anamnese und Untersuchung des Systems die Diagnose zu stellen und das ursprüngliche Bauchgefühl strukturiert zu einer Entscheidungsempfehlung zu bringen." Dabei sei es wichtig, nicht als Besserwisser aufzutreten und gut zuzuhören, um möglichst viel über die Symptomatik und die Projekthistorie zu lernen. "Unsere Diagnosegeräte ähneln einem EKG. Wir legen von außen Softwaresensoren auf den Code, die Daten sammeln und bis zu 1000 unterschiedliche Dinge bei einer Software messen sowie Anomalien anzeigen", beschreibt Adersberger die anschließende Untersuchung der Software.

Darauf folgt die Diagnose, aus seiner Sicht der schwierigste Part. Hier gilt es, die Fehlerursachen aufzulisten und einen Katalog von 20 bis teilweise 50 Maßnahmen vorzuschlagen, wie und mit welchem Aufwand diese Fehler behoben werden können. Läuft die Software überhaupt nicht mehr, müssen die Softwareingenieure von QAware erst mal ein paar "Pflaster kleben", wie es Adersberger nennt, das heißt, das System so zu stabilisieren, dass es kurzfristig weitergeht.

Qualitätsschulden treten erst später auf

Die wichtigste Aufgabe sei aber der langfristige Behandlungsplan, so der Informatiker: "Zu dem gehört immer eine Qualitätsoffensive: Ein bis zwei Monate lang ergreifen wir Maßnahmen, um die Qualität der Software zu heben und diese damit zukunftsfähig zu machen. Dann schulen wir das Team beim Kunden, damit bei der Entwicklung neuer Features keine neuen Qualitätsschulden entstehen."

Mit Qualitätsschulden meint Adersberger die künftigen Kosten, die durch falsche Kompromisse bei der Softwareentwicklung hinsichtlich der Qualität entstehen. In der Regel müsse man 20 Prozent der Kosten einer Software für den Abbau der Qualitätsschulden veranschlagen. Dass diese zunächst nicht anfallen, sich aber mittelfristig auftürmen und immensen Schaden anrichten können, ist vielen Kunden nicht bewusst, so die Erfahrung des Informatikers. Daran ändern auch neue Methoden wie Scrum nichts, im Gegenteil: "Durch agile Entwicklungsmethoden ist die Qualität von Software nicht unbedingt besser geworden. Es werden immer mehr Features draufgepackt, ohne zu fragen, ob das Fundament des Programms das aushält."

Das liegt auch daran, dass die Reise in das Fundament einer Software ziemlich beschwerlich sein kann. Etwa wenn die Dokumentation im Code fehlt und dieser übermäßig komplex ist. Oder wenn die Software auf über zwei Millionen Lines of Code angewachsen ist. Müssen hier die Softwaresanitäter nach unbenutztem oder fehlerhaftem Code suchen, gleicht das einer Urwaldexpedition: Sie müssen sich den Weg Schritt für Schritt freischlagen und haben immer wieder neue Lianen vor der Nase, die den Blick verstellen. Haben sie ihn gefunden, können sie ihn wie ein Arzt herausschneiden (Sectio) oder bei zu großen Abhängigkeiten auch einmauern (Sarkophag).

Entwickler im Code-Labyrinth

Am besten können sich die Softwaresanitäter von QAware im Code-Labyrinth zurechtfinden, wenn sie ähnlich wie ihre Kollegen, die neue Software entwickeln, im so genannten Flow arbeiten. Dabei helfen mehrere Bildschirme, Noise-Control-Kopfhörer, die jegliches Geräusch fernhalten, und die kugeligen Lampen auf den Schreibtischen. Sie leuchten in der Farbe, in der sich das Projekt befindet: Von rot über orange bis hin zu grün, wenn alles in Ordnung ist. So sieht der Kollege auf den ersten Blick, wann er am besten nicht stören sollte.

Zudem zeigt der Information Radiator an, was jede Codeänderung bewirkt. Das aus einer Dissertation hervorgegangene System läuft auf großen Flachbildschirmen in jeder Kaffeeküche von QAware und jeder hat beim Espresso im Blick, ob die Performance im vereinbarten Bereich ist, ob die Testabdeckung stimmt oder ob der Code noch konsistent zur Softwarearchitektur ist. Dadurch seien alle bestens informiert und auch angespornt.

Niedrige Ziele motivieren mehr

Je maroder die Software, desto wichtiger sei es, sich anfangs sehr niedrige Ziele zu stecken, räumt Geschäftsführer Adersberger ein. Diese werden dann Schritt für Schritt bis zur Erfüllung des Qualitätskontrakts angehoben. Jeden Freitag geht das Sanierungsteam, das je nach Projekt aus drei bis fünf Softwareingenieuren besteht, in Klausur und überprüft, ob die Qualität der Maßnahmen den Zielen auch Stand hält.

So gut die Visualisierung innerhalb des IT-Beratungs- und Softwarehauses funktioniert, so anspruchsvoll gestaltet sie sich beim Kunden. Josef Adersberger erklärt, warum: "Da bei einer Qualitätsoffensive in der Regel kein Funktionshub erfolgt, muss man die Endanwender auf anderem Weg für das neue Release begeistern, etwa mit einer höheren Performance oder einer besseren Usability."

Und die Motivation für die eigenen Mitarbeiter? "Wenn von der Sanierung einer Software 500 Arbeitsplätze abhängen, ist das eine große Motivation für unser Team", sagt Adersberger, weist aber auch darauf hin, dass die Entwickler auch in das zweite Geschäftsfeld "Innovation" wechseln können, in dem sie Software für neue Geschäftsideen entwickeln.