Wer für Software-Entwicklung bezahlt, hält es für selbstverständlich, qualitätsvolle Software zu bekommen. Welch ein Irrtum das sein kann!
Selbst weltweit anerkannte IT-Dienstleister (s.u. Beispiele) liefern hin und wieder absolut unbrauchbare Software und bescheren so ihren Kunden Verluste in Millionen-Höhe.
Warum nur fühlen sich Software-Entwickler so wenig für die Qualität ihrer Erzeugnisse verantwortlich?
Warum nur sehen sie Qualität so gar nicht als eines ihrer wichtigsten Ziele?
Liegt es daran, dass ihre Auftraggeber Qualität nur allzu pauschal fordern (und denken, sie nicht extra bezahlen zu müssen)?
Traurige Tatsachen sind:
- Wartbarkeitsaspekte — für Eigentümer und Betreiber der Software extrem wichtig — adressiert kaum jemand: Wie sich die Total Cost of Ownership niedrig halten lässt, diskutieren Entwickler nicht wirklich (sie müsste vom Auftraggeber schon explizit gefordert sein, …).
- Benutzerfreundlichkeit scheint Entwicklern völlig egal (so ergab eine Studie aus 2012).
Eine 2001 im Auftrag des deutschen Forschungsministeriums erstellte Studie kam zum Ergebnis: Für Software-Dienstleister ist Qualität ein Fremdwort, und so ist es heute noch:
- Im Früjahr 2013 bestätigt ein SAP-Team diese Einschätzung ganz unfreiwillig im wirklich übelsten Sinne des Wortes: durch Auslieferung einer absolut unbrauchbaren Neuimplementierung des Payroll Systems der kalifornischen Behörden auf der SAP Plattform (siehe [1], kürzer [CW]).
- Ähnliches war einige Monate früher IBM passiert (siehe [2]). Diesem Team misslang die Neuimplementierung eines Order Management Systems. Man streitet sich jetzt vor Gericht um einen zweistelligen Millionenbetrag.
- Vorher schon hatte IBM in Australien Software abgeliefert, die unbrauchbar war: "The system, which was delivered 20 months after deadline and 300 per cent over budget, led to 70,000 staff in Queensland’s health system being underpaid, overpaid or not paid for months."
- Ein ganz ähnliches Beispiel aus Deutschland (2015).
- Leider sind das keineswegs die einzigen Beispiele für in den letzten Jahren komplett schiefgelaufene, wirklich große Software-Entwicklungsprojekte. Siehe auch Zahlen dazu, z.B. von 2010.
Man muss sich ernsthaft fragen, ob gängige Software-Entwicklungsmethodik (insbesondere die neue, sog. agile) nicht ganz grundsätzlich nur für Projekte kleiner oder mittlerer Größenordnung funktioniert.
Wie sonst nämlich wäre es erklärbar, dass man mit den heute zur Verfügung stehenden wunderbaren, kaum noch verbesserungsfähigen Entwicklungswerkzeugen an der Neuimplementierung von Anwendungen scheitert, die man vor 30-40 Jahren schon einmal – und damals doch durchaus erfolgreich – geschaffen hatte (!).
Oder sind vielleicht die Einkäufer schuld, die davon ausgehen, dass der jeweils billigste Anbieter das Projekt schon stemmen werde? Wollen sie Qualität zum Nulltarif?
In 2010 schrieben Wissenschaftler der Carnegie Mellon University, die Software-Entwicklungsprozesse untersucht hatten: The software industry is the only modern high-tech industry that ignores quality until test.
Inzwischen aber zeigt sich noch Schlimmeres:
Selbst wirkungsvoller Test gelingt Software-Entwicklern nicht wirklich (siehe etwa [3], [4] und [5] sowie The Healthcare Go Live Debacle).
Wie wenig effektiv Tester bisher sind, spiegelt sich auch wider in Gartners Erkenntnis: 40% of problems are found by end users.
Wie lange noch — so frage ich — werden Auftraggeber sich das gefallen lassen?
Und insbesondere: Wann endlich werden Software-Entwickler die Konstruktion von Qualität ebenso ernst nehmen, wie das Konstruieren der Software selbst?
Bisher ist das Streben nach Qualität auf Seiten der Entwickler selten mehr als ein Lippenbekenntnis.
Tatsache ist: Wo Termin und Budget eng werden, wird weniger getestet — mit oft schlimmen Folgen (immer für den Auftraggeber, nicht selten auch für den Auftragnehmer). Beide Vertragspartner sollten sich dessen bewusst sein und nicht versäumen, dem ganz entschieden zu begegnen: Auf jeden Fall weit effektiver als bisher zu beobachten.
Den oft jungen Entwicklern sei gesagt:
Zu glauben, dass sogenanntes agiles Vorgehen die früher übliche, peinlich genaue Dokumentation aller zu entwickelnden Funktionalität überflüssig macht, ist ein ganz gewaltiger Irrtum: Der Wille, praktisch alles, was man produziert, in jedem noch so unfertigen Zustand gerne dem Anwender zu zeigen (damit der sage, wo er was anders haben möchte), mag ja gut gemeint sein, ist aber einfach nur naiv, denn solches Vorgehen überfordert den Anwender – man schiebt ja so nur eigene Verantwortung auf ihn ab.
Kluge Kunden durchschauen das und akzeptieren es nicht.
Vorzugehen, wie im Agilen Manifest gefordert, kann nur gut sein für prototypische Entwicklung in sehr kleinen Teams. Viele der heutigen Entwickler wollen das nicht einsehen. Methodiker, die ihnen Einhalt gebieten, gibt es nicht mehr wirklich. Es fehlt wohl die Einsicht, dass sie zu bezahlen sehr gut angelegtes Geld wäre …
SCRUM-Verfechter, eine spezifische Subklasse der Agilisten, übersehen, dass sich mit täglichen Stand-up-Meetings nur Mikroprozesse steuern lassen — auf keinen Fall aber Großprojekte.
ggreiter 
