Der Mythos der technischen Schulden
Technische Schulden müssen wie alle anderen Schulden beglichen werden. Sonst droht uns Ungemach. In Form von Folgekosten oder Qualitätsmängeln. So auf jeden Fall die landläufige Meinung. Lösen wir uns davon!
Eine typische Situation bei vielen Vorhaben: Ein Meilenstein oder ein Release-Termin will in jedem Fall eingehalten werden. Und das Credo lautet, die geforderte Funktionalität in der geforderten Zeit und Qualität mit dem geplanten Aufwand zu liefern. Leider ist das nicht immer möglich. Insbesondere am Beginn eines Projekts ist es sehr schwierig, die geplanten Zielsetzungen einzuhalten. Der Hauptgrund dafür ist die Tatsache, dass zu diesem Zeitpunkt schlicht und einfach noch die Erfahrung und das kollektive Wissen des Teams fehlt, um präzise genug zu planen. Die Folge: Wir liefern nicht, was wir versprochen haben und haben uns damit technische Schulden aufgeladen. Diese gilt es dann im Laufe des Vorhabens abzubauen. Wenn uns das nicht gelingt, werden sie unweigerlich zu höheren Betriebs- und Unterhaltskosten führen. So weit die Theorie.
Vom Versuch einer Messung
Der Begriff «technische Schulden» ist seit 30 Jahren ein Begleiter der agilen Vorgehensweise. Einer der Mitautoren des Agilen Manifests, Ward Cunningham, hat diesen Begriff geprägt und er wird bis heute im modernen Scaled-Agile-Framework-Zeitalter (SAFe) kultiviert. «Technische Schulden können das Team dazu veranlassen, bestimmte Komponenten neu zu strukturieren», heisst es da recht unverfänglich. Refactoring-Papst Martin Fowler hat den «Technical Dept Quadrant» geprägt und selbst «Uncle Bob» hat sich mit der Fragestellung auseinandergesetzt. Renommierte Organisationen wie die ACM führten sogar Konferenzen zum Thema durch. Alle bestrebt, sich mit dem Phänomen auseinanderzusetzen und Strategien für den Schuldenabbau aufzuzeigen. Konkrete Messungen sind selten, abgesehen von der Studie «Evolution of Technical Debt», die anhand von sogenannten «Code Smells» (unsaubere Stellen im Quellcode) zu sehr interessanten Ergebnissen gekommen ist. Tausende von Dateien aus mehr als 20 Projekten renommierter Firmen wie Microsoft, SAP, Netflix oder Twitter wurden analysiert. Das Resultat: Je kleiner die Datei, desto höher die Dichte technischer Schulden. Mit zunehmender Grösse nehmen die technischen Schulden also ab. Das Fazit der Forscher ist klar: Technische Schulden sind vor allem zu Beginn eines Projekts hoch, dann nehmen sie ab.
Technische Schulden – ein irreführender Begriff
Weitere Versuche, vernünftige Messungen zu etablieren, sind kläglich gescheitert. Nicht einmal die Klärung des Begriffs ist gelungen. Ein internationales Forscherteam hat schon vor zehn Jahren versucht, den Begriff von seinen Mythen zu befreien und zu präzisieren. Ohne Erfolg.
Was sich in der Realität abspielt: In jedem Vorhaben lernen wir mit der Zeit, wie wir besser werden. Zu Beginn machen wir mehr Fehler als später, und wir sind gezwungen, mehr wegzulassen, um Termine halten zu können. Diese Fehler als technische Schulden zu bezeichnen, ist nicht hilfreich. Manchmal ist es klug, schnell statt vollständig zu liefern, um früh zu lernen und uns laufend zu verbessern. Darüber hinaus gehört das Weglassen von überflüssiger Funktionalität zu den wichtigsten Erfolgsfaktoren eines Projekts. In vielen Fällen ist eine einfachere Lösung die bessere Lösung, auch wenn sie nicht alle Wünsche erfüllt. In der Praxis hilft uns der Begriff «technischen Schulden» nicht – niemand braucht diesen erhobenen Zeigefinger – befreien wir uns davon!