Definition „Technical Debt“ Was sind technische Schulden?

Wer Schulden macht, muss diese später begleichen. Das gilt für Kredite ebenso wie für technische Schulden; denn selbst im Development ist es möglich, Schulden zu machen.Aber wir entsteht Technical Debt und warum sollte sie vermieden werden?

Im Development kostet jede Minute und jede Codezeile Geld. Die Entwicklung einer Software ist daher stets auch mit einem Abwägen verbunden zwischen der technischen Perfektion und einer lauffähigen Version, die zeitnah veröffentlicht werden kann.

Wirtschaftlichkeit ist bei der Entwicklung mindestens genau so wichtig wie technische Abwägungen. Aus genau dieser Spannung heraus können technische Schulden entstehen: Bugs müssen schnell gefixt, ein System irgendwie lauffähig gemacht und Code fertiggestellt werden, ohne auf Streamlining achten zu können.

Zeitliche und wirtschaftliche Vorteile stehen hierbei den technischen Nachteilen gegenüber, letztere werden dabei als Schulden angelegt. Was im Jetzt spart, erfordert später zusätzliche Kosten.

Was genau sind technische Schulden?

Technische Schulden (oder Technical Debt im Englischen) beziehen sich auf die Kosten der Nachbesserung oder Optimierung, die in der Zukunft und als Folge von in der Gegenwart getroffenen Entscheidungen entstehen Oft werden auch die Kurzbegriffe Tech Debt oder Code Debt genutzt, gemeint ist jedoch stets das gleiche Konzept, welches 1992 vom Entwickler Ward Cunningham geprägt wurde.

Wirklich vollständig vermeidbar sind technische Schulden eigentlich nur in der Theorie. In jedem praktischen Szenario, das an Budgets und Veröffentlichungsdaten oder einen festen Updatezyklus gebunden ist, müssen Kompromisse gemacht werden. Diese Kompromisse werden sich früher oder später als Code Debt zeigen.

Dies ist deshalb unabwendbar, weil technische Korrektheit und Optimierung gegen die Faktoren Zeit und Geld aufgewogen werden müssen. Überdies gilt es, Teamgröße und -qualifikation miteinzubeziehen, da in der Praxis nicht immer Entwickler und Entwicklerinnen zur Verfügung stehen, die einen perfekt optimierten Code schreiben können.

Tatsächlich sind technische Schulden auch nicht immer etwas Schlechtes. Ein Team, das eine Software mit technical debt entwickelt, sollte lediglich ein Bewusstsein für das Ausmaß der Schulden haben. Projektmanagement kann diese Schulden in die Planung der Softwarebetreuung einrechnen und somit mit der Begleichung der Schulden planen.

Eine eingehaltene Deadline kann sich auch unter Schulden rentieren, wenn damit das Ausbessern des Codes im folgenden Quartal finanziert werden kann. Im Bezug auf die Wirtschaftlichkeit eines Projektes sind technische Schulden also ein Faktor, mit dem Teams kalkulieren können bzw. kalkulieren müssen.

Die Gründe für technische Schulden

Das Anlegen technischer Schulden kann ganz unterschiedliche Ursachen haben und ist von einer Vielzahl von Faktoren abhängig. Zu einigen gängigen Gründen gehören:

• Wirtschaftlicher Druck: Teams müssen Deadlines einhalten, mit Crunch arbeiten oder sich einer starken Konkurrenzsituation stellen.

• Mangelnde Qualifikation: Teams haben nicht die Fachkenntnisse, um einen sauber optimierten Code zu schreiben und die Fertigstellung wird gegenüber elegantem Code priorisiert.

• Zu hohe Komplexität: der Code ist bereits zu komplex und selbst kleine Änderungen führen zu Fehlern, so dass bereits vorhandene Schulden zu weiteren Schulden führen.

• Outsourcing: Teile des Codings werden extern erledigt und durch mangelnde Absprachen kann der Code nicht optimiert zusammengeführt werden.

• Kein Refactoring/Qualitätsmanagement: Ob aus finanziellen oder zeitlichen Gründen – fehlen Refactoring und QA, dann können Deadlines vorgezogen werden, aber finanzielle Schulden entstehen.

• Fehlende Dokumentation: Code lässt sich einfacher optimieren, wenn eine angemessene Dokumentation vorhanden ist. Wird diese Dokumentation weggelassen oder vernachlässigt, können allerdings Kosten gespart werden.

Diese häufig auftauchenden Gründe geben natürlich nur einen kleinen Einblick in die verschiedenen Ursachen, aus denen heraus technische Schulden entstehen. Einen besseren Überblick über die Gründe für technical debt gibt Martin Fowlers Quadrantensystem, in dem sich die Schulden kategorisieren lassen. Diese Kategorien zu analysieren kann Development Teams dabei helfen, notwendige und überflüssige technische Schulden klar zu differenzieren.

Martin Fowlers Technische-Schulden-Quadranten

Kategorie 1 – Bewusste und rücksichtslose Schulden: Hierunter fallen etwa Schulden, die aus einem Mangel an Budget und Zeit heraus entstehen. Auch vernachlässigtes Refactoring gehört in diese Schuldenkategorie, die oft Folge mangelnder Projektplanung ist.

Kategorie 2 – Bewusste und umsichtige Schulden: Diese Kategorie stellt Teams in die Verantwortung, eine schnelle Lieferung durch nachgezogenes Refactoring auszugleichen.

Kategorie 3 – Versehentliche und rücksichtslose Schulden: Diese Form von technischen Schulden entsteht in der Regel durch Unvermögen oder Arbeit an überaltertem Code. Fehlende Qualifikationen, Overengineering, mangelnde Dokumentation oder Code Erosion verursachen diese Form von Schulden, die oft noch mehr technische Schulde nach sich ziehen.

Kategorie 4 – Versehentliche und umsichtige Schulden: Schulden, die in Kauf genommen aber durch konstantes Refactoring behoben werden. Die technischen Schulden dienen somit als Altlast, aber auch als Lerngrundlage. Studienprojekte fallen etwa in diese Kategorie.

Mit technischen Schulden richtig umgehen

Aus dem Prinzip der technischen Schulden erwuchs auch die Forderung zu einer besseren flexibleren Softwareentwicklung. Die Idee der agilen Entwicklung ist designt worden, um einem Übermaß an Schulden entgegen zu wirken.

Kürzere Arbeitszyklen und schnellere Veröffentlichungen sowie die Einteilung in kleinere Subprodukte reduzieren die technischen Schulden in der alltäglichen Arbeit und räumen bereits entstandene Schulden laufend aus. Standardisierte Arbeitsabläufe, stete Analyse und bessere Qualifikationen können Schulden zwar vermeiden helfen, doch auch hier sollte stets bedacht werden, dass es Diskrepanzen zwischen Theorie und Praxis gibt.

(ID:48613268)