For the English readers: This article is written in German. If the ideas get more ripe, then I think I’ll translate it into English. So long, you have to rely on Google Translate (and it does a remarkably good job).

Warum die Bewertung der inneren Softwarequalität schlecht für Entscheidungsträger ist (und warum es den Kunden sowieso nicht interessiert…).

Einführung

Die innere Qualität der Software wird als immer wichtiger angepriesen. Innere Softwarequalität – das sind die Eigenschaften der Software, welche vorwiegend von den Entwicklern der Software gesehen werden: gute Codequalität, einfache Architektur, einheitliches Design, zuverlässige Tests etc.

Zugleich bauen Softwareentwickler täglich immer mehr sog. technische Schulden auf – also genau das Gegenteil von innerer Qualität. Durch technische Schulden wird ein Softwaresystem schwerer wartbar, d. h. schwerer anpassbar, unberechenbarer…schlichtweg teurer in der Weiterentwicklung. Die verwendete Metapher der “(Kredit-)Schulden” (nicht der Metapher der “Schuldzuweisung”!) sagt bewusst, dass Zinsen in Form von immer länger dauernden Aufwänden für die Änderung an der Software zu zahlen sind (OK, fast, diese Art von “Schulden” können ja schnell “gelöscht” werden 😉 ). Die Behebung der inneren Softwarequalität wird dadurch umso teurer, je länger gewartet wird. Zudem wird in der Praxis das Konzept der technischen Schulden teilweise missbraucht, um Hacks in einer Softwareanwendung zu rechtfertigen. “Das machen wir später (wenn Zeit = Geld da ist)” ist gefühlt einer der am häufigsten gebrauchten Todschlagargumente, wenn es darum geht, die Erosion der inneren Softwarequalität wegzudiskutieren. In diesem Fall wird aus einer technischen Schuld ein “technischer Diebstahl”, da hier oft die Absicht dahinter steckt, die “Schulden” sowieso nicht zurückzuzahlen.

Der Fokus auf bessere, innere Softwarequalität steht mit der ständigen Erhöhung der technischen Schulden im Gegensatz. Qualitätsbewusste Softwareentwickler fragen sich zunehmend, warum denn ihr Kunde oder ihr Chef keine Software haben wollen, die qualitätstechnisch auf hohem Niveau ist. Diese Infragestellung geht sogar so weit, dass gute Softwareentwickler vermehrt kündigen, in der Hoffnung, dass andere Arbeitgeber sich bzgl. der inneren Qualität ihrer Softwareprodukte einsichtiger zeigen. Dass es dort notwendigerweise auch nicht besser ist (sondern nur anders), möchte ich mit folgenden Standpunkten der zwei genannten Interessensgruppen verdeutlichen – dem Kunden der Software sowie dem Entscheidungsträger, unter dessen Führung die Software entstanden ist. Diese beiden Akteure haben die Verfügung über das Budget und können hier auch qualitative Verbesserungsmaßnahmen beauftragen.

Allgemein soll dieser Artikel zur Sensibilisierung bzw. Ernüchterung enthusiastischer “Qualitätsverbesserer” dienen. Daher versuche ich (teilweise extreme) Perspektiven auf die innere Qualität der Software darzustellen. Ich hoffe dadurch, dass sich Entwickler dadurch auf andere, für das Business wichtigere Dinge konzentrieren könne, statt Kämpfe führen, die sie nicht gewinnen können (und aus Frust evtl. kündigen oder in einen Burn-Out rennen).

Hinweis: Bei folgenden Erläuterungen gehe ich von einer Standardsoftware aus, welche für einen erlauchten Kundenkreis auch kundenspezifisch angepasst wird. Somit bewegen wir uns zwischen den Extremen “Individualsoftware” und “Massenprodukt”.

Der Kunde

Durchleuten wir als erstes die Bedürfnisse und Interessen unseres Kunden, welchen wir unterstellen, an einer Software mit einem optimalen “Preis-/ Leistungsverhältnis” interessiert zu sein. Ihm unterstellen wir folgende Standpunkte:

Die Software tut es doch

Fakt ist, dass es Software auf dem Markt gibt, die hinsichtlich ihrer inneren Qualität extrem defizitär ausgelegt ist, aber trotzdem anscheinend einen gewissen Wert für den Kunden liefert. Das liegt etwa daran, dass vor Jahren manuell durchgeführte Arbeiten inkl. vielen Medienbrüchen durch den Einsatz eines “schrottigen”, jedoch maßgeschneiderten Softwareprodukts erheblich effizienter gestaltet wurden. Dieser Nutzenzuwachs von der durch vorgenommenen Rationalisierung wurde und wird als solch ein große Effektivitätssteigerung im Unternehmen des Kunden empfunden, dass er ein paar kleine Softwarefehler positiv gegenüber den früheren möglichen Fehlerquellen aufwiegt. Was sind denn schon ein paar Anwendungsabstürze gegenüber verlorengegangener Verrechnungschecks? Der Kunde hat sich auch an die evtl. vorhandenen Makeln der Software gewöhnt und entsprechende Verhaltensanpassungen im Umgang mit Fehlern entwickelt.

Zudem sind Kunden mit Standardproblemen nicht mehr bereit, für Individualsoftware immense Summen aufzuwenden. Ein Kunde sieht es daher auch überhaupt nicht ein, explizit für eine qualitativ bessere Software zu zahlen, weil er bereits mit der bestehenden Softwareversion in seiner Arbeit signifikant produktiver ist. Die bestehenden Risiken auf Grund einer schlechten inneren Softwarequalität geht er daher (bewusst oder unbewusst) gerne ein.

Guter Vertrag

Einkäufer auf der Kundenseite sind meist geschickte Strategen und “Absicherer”, was die Gestaltung von Verträgen zwischen ihnen und ihren Softwarelieferanten betrifft. Hier liegt geballte Erfahrung aus zig knallharten Verhandlungen mit anderen, ebenfalls erfahrenen Verkäufern vor. Nun sind wir mal ehrlich: Die meisten Softwareentwickler sind nicht gerade die besten Verkäufer. Sie verkaufen sich oft unter Wert. Außerdem verkaufen sie kein physisches Produkt mit definierten Eigenschaften, sondern immaterielles Wissen, welches in Quellcode gegossen wurde. Da gibt es einfach nichts Großartiges zum Angeben. Womöglich ist es auch so, dass es für gestandene Software kaum mehr möglich ist, die gesamten Eigenschaften bzw. ihren Funktionsumfang zu beschreiben.

Bescheiden wie Softwareentwickler nun mal sind, überlassen sie diese Dinge lieber anderen Leuten. Daher gibt es bei Softwarelieferanten auch das Äquivalent zu den Verkäufern – zur Unterscheidung im Folgenden “Vertriebler” genannt. Diesen sei unterstellt, dass sie alles nur Mögliche verkaufen (zur Optimierung ihrer Boni), was nicht bei drei auf den Bäumen ist. Da wird schon mal ein Stück Software, welches ein Student während seiner Abschlussarbeit geschrieben hat, als hochinnovatives Tool “vermarktet”. Das uralte, nicht mehr wartbare System bekommt ein GUI-Neuanstrich und wird als supertolle Neuentwicklung verkauft. Unter der Haube läuft aber weiterhin der alte Schrott, der schon etliche Entwickler zum (innerlichen) Kündigen motiviert hat. Oft werden dann noch Eigenschaften des Softwareprodukts zugesichert, welche noch gar nicht existieren.

Einkäufer auf Kundenseite lassen jedoch die vom Vertriebler dargestellten Eigenschaften der Software vertraglich zusichern. Im Vertrag sind dann irrwitzigen Formulierungen zu finden wie “alles soll so gut funktionieren wie im alten System, nur “besser” oder “die Erweiterung um <Name einer Funktionalität, wo weder der Kunde noch der Softwarelieferant weiß, was das genau werden soll> wird zum <beliebiges, unrealistisches Datum, welches an irgendeinem Monat, Quartal oder Jahr endet> bereitgestellt” – und das zu einem Spottpreis super Angebot.

Das noch Schlimmere dabei ist, dass es sich der Vertrieb und die Chefetage bewusst darauf einlassen. Die Hoffnung, durch Folgeaufträge dann doch noch Gewinn zu erwirtschaften, übertrifft den gesunden Menschenverstand. Denn wie wird es sein – und damit zurück zum Vorteil für den Kunden? Das Projekt kommt in Verzug, weil das bestehende System doch nicht so einfach erweitert werden kann und die “versprochen-vorhandenen” Funktionen nicht richtig funktionieren. Der Kunde droht mit Vertragsstrafen, der Vertrieb beschwichtigt und stellt die vorher hoffnungsvoll, gewinnbringenden Erweiterungen wieder zum Spottpreis oder sogar kostenlos zur Verfügung, nur um Schlimmeres zu vermeiden. Der Kunde ist in solchen Situationen (mit einem auf Seiten des Softwarelieferanten mit Hoffnungen begründeten Erstvertrag) immer der Gewinner. Der Kunde hat mit einem solchen Vertrag den Softwarelieferanten unter Kontrolle gebracht!

Eine schlechte innere Qualität einer Software ist für ihn sogar noch von Vorteil, da der Softwarelieferant nicht in die Gänge kommt!

Entscheider

Und die Entscheider der Softwarelieferanten? Jahrelang habe ich auch geglaubt, dass es für Entscheider (Ressourcen mit Leitungsfunktionen und Mitarbeiterverantwortung) interessant wäre, wie es um die innere Qualität ihrer verantworteten Software bestellt ist. Ich dachte mir, dass zuverlässige Aufwandsabschätzungen wichtig seien, welche inkl. einer vorherigen Betrachtung der Änderungs- und Analysierbarkeit auch realistisch dargestellt würden. Ich dachte mir, dass durch die Quantifizierung der inneren Qualität ein angemessenes Risikomanagement vorgenommen werden könne, um größere Schäden wegen Strafzahlungen oder grober Fahrlässigkeit vom Unternehmen abzuwenden.

Anscheinend ist das völlig egal, u. a. wegen den folgenden Gesichtspunkten:

Gewolltes Geschäftsmodell

Der Gegenpol zum obigen Kundenaspekt “Vertrag” ist ein “schwacher” Einkäufer auf Kundenseite mit einem “knallharten” Vertriebler auf der Seite des Softwarelieferanten. Es existieren Wartungsverträge mit dem Kunden oder der Kunde ist bereit für Change Requests oder Bugfixes zu bezahlen. Es ist für einige Entscheider also nur eine Frage der Vertragsgestaltung, um weiterhin ihr Softwareprodukt erfolgreich zu verkaufen. In der Praxis kann dies mit Lockangeboten durchaus funktionieren. Ist die eigene Software in einer Standardausführung erst einmal beim Kunden produktiv im Betrieb, ist ein Abschalten schwer möglich. Evtl. noch notwendige Erweiterungen der Software können daher teuer verkauft werden. Der Vendor-Lock-in macht es möglich.

Unklare Bewertungsbasis

Um überhaupt über eine Qualitätseigenschaft reden zu können, muss diese irgendwie quantifizierbar dargestellt werden. Hier haben wir bereits den ersten Widerspruch: qualitative Eigenschaften sind an sich nicht messbar (sonst wären sie ja quantitativ). Das macht es schwierig, objektive Messinstrumente für die innere Softwarequalität zu finden. Oft wird daher auf quantifizierbare Eigenschaften des Softwareprodukts zurückgegriffen (z. B. Anzahl der Bugfix-Tickets, Anzahl der nicht-kommentierter Quellcodezeile etc.). Jeder dieser Metriken hat jedoch einen anderen Fokus auf das Softwareprodukt und kann auch nur eingeschränkt für einen speziellen Kontext “gültige” (falle es so etwas überhaupt gibt) Aussagen treffen.

Fakt ist, dass es ich bei den “Quantifizierern” von Qualität lediglich um Heuristiken handelt. D. h. was gemessen wird, ist ein quantifizierender Stellvertreter für eine nicht messbare qualitative Eigenschaft. Das bedeutet, dass die von den Metriken erzeugten Ergebnisse keine “Wahrheit” darstellen, sondern eine Abschätzung für das liefern, was der Erfinder der Metrik im Sinn hatte (welcher hoffentlich gut nachzuvollziehen ist). Daher verbleibt immer ein großer Interpretationsspielraum der gelieferten Messergebnisse, welcher leider als “schwammig” bezeichnet werden muss. Budgetentscheidungen auf einer solch schwammigen Basis sind daher sehr schwer bis unmöglich zu treffen. Es gibt zu viele andere Gesichtspunkte, welche durch die gewählten Metriken evtl. nicht erfasst werden können. Eine Entscheidung für Maßnahmen zur Verbesserung der inneren Softwarequalität ist daher ein hohes Risiko. Die Messung der Verbesserungsmaßnahmen ist zudem mit einfachen Metriken bzw. günstig zu ermittelnden Messwerten nahezu unmöglich.

Transparenz als Karrierekiller

Was wäre, wenn doch die Erosion der Software irgendwie quantifizierbar wäre? Wie wäre es, wenn die schlechte Qualität offen kommuniziert würde? Dann besteht die Gefahr eines Fingerpointings. Die Offenlegung der inneren Softwarequalität kann von anderen Mitarbeitern als Druckmittel / Waffe genutzt werden, welche z. B. bei Personalentscheidungen von den Mitbewerbern um eine besser gestellte Position vorteilhaft genutzt werden kann. Der Entscheider, der die innere Softwarequalität des von ihm verantworteten Softwareprodukts offenlegt, legt auch die Qualität der eigenverantworteten Führungsarbeit offen. Ist das Produkt Schrott, ist die Reputation des Entscheiders im Keller.

Zusammenfassung

Geldwerte Effekte durch Rationalisierung, Automatisierung und Standardisierung können für den Kunden nicht mehr durch den Einsatz neuer Standardsoftware erzielt werden. Die Potenziale sind bereits durch die eingesetzte Software gehoben worden.

Die verständliche und handlungsorientierte Bewertung der inneren Softwarequalität ist Gift für jeden Entscheidungsträger. Dadurch werden Maßnahmen notwendig, welche auch durchgeführt, aber mit dem vorhandenen Budget nicht bewältigt werden können. Zudem stellt eine Offenlegung der inneren Softwarequalität unternehmensöffentliche Zäsur entgegen den Kompetenzen des Entscheidungsträgers dar.

Tipps

Nach all diesen negativen Schwingungen muss es natürlich auch Ideen geben, wie der oben durchscheinende Missmut bewältigt werden kann. Leider gibt es moralisch weniger positiv anmutende Mittel (“the dark side”), aber auch ein paar Lichtblicke (“die gute Seite”).

The Dark Side

• Knallharte Vertriebler einstellen, welche sich über die Interessen auf der Einkäuferseite durchsetzen kann
• Rechtsberatung nutzen (evtl. sogar dedizierten Justiziar einstellen), um Verträge wasserdicht zu gestalten (nach einem Buy-In und gewonnenem Vertrauen durch “Polished-Features” hat der Kunde eh keine Chance mehr, ohne große Verluste “aus der Software” herauszukommen).
• Nur kleinen Umfang für die Implementierung der Software im Unternehmen des Kunden definieren. Erweiterungen vertraglich gesondert (lese: bezahlt) regeln.
• Für Demos nur kleine Teile des Anwendungssystem (z. B. Haupt-Use-Cases) polieren und nur diese dem Kunden zeigen (bösartig könnte ich hier von MVP reden…)
• Zum Marktführer werden, danach auf Kundensonderwünsche verzichten (Vendor-Lock-In)
• Hohes Risiko eingehen. Dann aber bitte auch verantworten!

Die gute Seite

• Intelligenter Softwarerückbau: Proaktives Löschen von nicht mehr benötigter Funktionalität aus der Anwendung
• Ersetzbarkeit etablieren: Softwarekomponenten und -architektur für “replace” statt “reuse” konzipieren, um System stückweise am Leben erhalten zu können
• Erwartungshaltung klären: Demo-App mit dem aktuellen Funktionsumfang zur Verfügung stellen
• Funktionsumfang reduzieren: Nicht jeden Kundenschrottwunsch erfüllen, sondern Kompetenz in der fachlichen Domäne des Kunden aufbauen und mit wenigen Features überzeugen, welche das Kerngeschäft des Kunden immens produktiver gestalten
• Intelligenter kodieren: So wenig coden wie möglich, dafür Standardprodukte verwenden (die eigene Programmierproduktivität geht dadurch ins unendliche)
• Business first, technology second: Technologie in den Hintergrund stellen (nicht selbst versehentlich in den Vendor-Lock-In geraten und auch nicht selbst durch den Einbau von Trends die Zukunft verbauen). Das eigentliche Geld liegt in der Software, welche fachlichen Prozessen optimal unterstützt.

Die spiegelt natürlich nur meine eigene (bisherige) Sichtweise auf die Kernprobleme wider. Es gibt bestimmt noch andere Gesichtspunkte. Immer her damit!