In lockerer Folge erzähle ich hier ein paar Geschichten zur so genannten technischen Schuld, den verborgenen Kosten schlampig gemachter Software. In Anlehnung an einen aktuellen Bestseller behaupte ich dabei frech, Beispiele aus 5000 Jahren Menschheitsgeschichte abdecken zu können.
Wie kocht ein Mathematiker Tee? Er räumt zunächst alle Utensilien auf, um dann von einem bekannten Problem ausgehen zu können.
Wie kocht ein Programmierer Kaffee? Er nimmt sein Auto, um mit dem Kühlwasser den Kaffee zu brühen.
Klar, Wiederverwendbarkeit ist eine clevere Idee. Aber vielleicht übertreiben es die Programmierer manchmal? [1, 2] Wozu eine Mega-Codebasis einbinden, wenn man das Problem auch mit einer schlanken Bibliothek lösen kann? Wozu eine Bibliothek, wenn der Adapter zum Einbinden der Bibliothek aufwendiger ist, als die Funktion direkt zu implementieren?
Ein wesentliches Problem unpassend großer Komponenten ist die technische Schuld, die in den Komponenten bzw. der Form ihrer Einbindung verborgen liegt. Auch wenn der Wasserkocher in der Anschaffung mehr kostet als ein schrottreifes Auto das gerade noch das Kühlwasser zum Kochen bringt, spart der Wasserkocher doch Betriebskosten im Vergleich zum Auto. Von der Geschmacksqualität des Kühlwassers ganz zu schweigen.
Häufig blendet man die verborgenen Kosten der technischen Schuld aus. Die BSD-lizenzierte, Kann-alles-gewinnt-immer-Bibliothek ist keineswegs kostenlos, sondern kostet Zinsen in Form eines möglicherweise hohen Pflegeaufwands. Gibt es eine stabile Community, die das leistet? Pflegt sie alle Eigenschaften und Schnittstellen, die ich brauche? — Oft unterschätzt man den Aufwand und leistet sich ein aufgeblähtes Design, das dann mit der Zeit im Klein-Klein zu vieler Komponenten untergeht. Aber ein Auto für 100 EUR im Monat zu leasen ist eben nicht hundert Mal billiger als es für 10.000 EUR zu kaufen — sprich ein passgenaues System zu entwerfen und zu bauen! Das mag trivial erscheinen. Dennoch beschert dieses Missverständnis der Kreditindustrie eine rege Nachfrage und der IT-Industrie einen steten Strom im Nachhinein unzufriedener Kunden.
Man kann eben nicht immer alle Kundenanforderungen ins Prokrustes-Bett eines Universalwerkzeugs pressen. Wo bleibt die Systemauswahl? Wo die Abwägung zwischen Kosten und Nutzen? Da werden Open Source Software-Boliden zusammengesteckt, ohne dass die Beteiligten verstehen, warum das Gesamtsystem überhaupt funktioniert. Da werden Daten durch ein Dutzend verschachtelte Schnittstellen gejagt, ohne dass jemand dabei den Überblick behalten könnte. “Schau, es geht doch.” ist dann die Rechtfertigung der Entwickler und “Computerfehler” die Entschuldigung des Web-Seiten-Betreibers oder Dienstanbieters, wenn es irgendwann eben nicht mehr funktioniert.
Also, lieber einfach und zielgerichtet bauen, dann läuft und läuft und läuft die Maschine … wenn’s sein muss hundert, tausend oder auch zehntausend Jahre.
Die technische Schuld häuft sich?
Auch dann ist es nicht zu spät! Wie das Gebiss des Gaules könnt ihr auch euer IT-Projekt noch retten. Findet ihr selbst keinen Ansatzpunkt, unterstützen wir euch, den Hebel zu finden und den faulen Zahn zu ziehen. Mehr zu unserem Notfallplan unter agile-projektrettung.de.