Auch ein geschenkter Gaul muss mal zum Zahnarzt

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.

auto

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.

[fblike style=“button_count“ showfaces=“false“ width=“90″ verb=“like“ font=“arial“ float=“left“] [fbshare type=“button“ float=“left“] [google_plusone size=“medium“ float=“left“] [twitter style=“horizontal“ float=“left“ lang=“de“] [linkedin_share style=“right“ float=“left“]

Verwandte Beiträge

Leave a comment

p1F0

Bitte geben Sie den Text vor: