Widersprechen Technische Schulden dem Stand der Technik?

"Technische Schulden" sind gemäß Wikipedia "eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software." Sie beschreiben also juristisch gesehen einen versteckten Mangel, der zwar die Erfüllung der funktionalen Anforderungen nicht behindert, aber zu höheren Kosten führt und einklagbar ist.

Schlechte technische Umsetzung entspricht auch nicht dem "auf einschlägige wissenschaftlichen Erkenntnissen beruhenden Stand der Entwicklung", was Voraussetzung für den Stand der Technik wäre. Darum gilt:

Software mit technischen Schulden ist mangelhaft und nicht am Stand der Technik.

Viele Informatiker werden nun einwenden, dass es eine schier endlose Zahl an möglichen technischen Schulden gibt:

Software kann aus vielen tausenden Zeilen Code bestehen, es gibt Unmengen an technisch mehr oder weniger geeigneten Architekturen, Designs, Architektur-, Analyse- und Entwurfsmuster, Libraries und Frameworks, es gibt je nach Programmiersprache viele Werkzeuge die hunderte Arten von technischen Schulden alleine durch statische Codeanalyse aufzeigen, hunderte mögliche Anti-Pattern und Code-Smells und unterschiedliche Programmierstile. Diese alle zu berücksichtigen scheint unmöglich und würde mehr Kosten verursachen, als es bringt.

Die kurze Antwort darauf ist folgende: Ja, das ist alles richtig. Aber das gilt nicht nur für Software, sondern für alle Arten komplexerer technischer Erzeugnisse. Von einem KFZ-Hersteller erwartet man ja auch, dass jedes einzelne und das Zusammenspiel aller Teile des Fahrzeuges technisch einwandfrei ist. Andernfalls würde man bei dem Auto selbstverständlich von einem Mangel und Verfehlung des Standes der Technik sprechen.

Die etwas längere Antwort lautet aber folgendermaßen: Nicht alle technischen Schulden führen immer zu Mehrkosten, die die Kosten für Analyse bzw. Behebung der Schulden übersteigt (z.B. bestimmte Naming-Conventions). Es gibt technische Schulden deren (unintelligente) Behebung mehr Schaden als Nutzen stiftet (z.B. nachträgliche Erhöhung der Coverage durch Unit-Tests). Es gibt technische Schulden, die selbst oder in ihrer Ausprägung auch durch Experten unterschiedlich beurteilt werden (z.B. "ab wieviel Zeilen Code gilt eine Methode als zu lange"). Es gibt Situationen, wo eine Behebung technischer Schulden keinen Sinn macht (z.B. Migrationstools nach der Migration)
→ Um späteren Streit zu vermeiden, ist es also sinnvoll, rechtzeitig mit Kunden bzw. Auftraggebern zu vereinbaren, wie und welche technischen Schulden geprüft bzw. vermieden und behoben werden. Dem Auftraggeber müssen dabei aber sowohl die rechtlichen als auch kostenmäßigen Implikationen der Entscheidung klar gemacht werden - was viele Informatiker gar nicht können. Dafür einen unparteiischen Experten hinzuzuziehen macht sowohl inhaltlich, als auch haftungsmäßig, als auch kostenmäßig Sinn.

Fazit: Software mit technischen Schulden ist mangelhaft und entspricht nicht dem Stand der Technik. Da die Verhinderung bzw. Behebung aller möglicher technischen Schulden u.U. kontraproduktiv ist, tut man gut daran, mit Kunden bzw. Auftraggebern zu vereinbaren, wie und welche technische Schulden zu vermeiden bzw. zu beheben sind.