Technical Debt Aufzucht und Hege der Technischen Schuld

Anbieter zum Thema

Vector Informatik GmbH

MicroConsult Academy GmbH

emlix GmbH

Parasoft® Deutschland GmbH

Wie entsteht Technische Schuld, wie erkennt man Sie frühzeitig – und wie wird man sie wieder los? Entwickler sollten in der Lage sein, sich die Problematik bewusst zu machen, ehe die Auswirkungen überhaupt erst spürbar werden. Auch, um sich selbst die Arbeit zu erleichtern...

Technische Schuld findet man in jeder Software, mal mehr und mal weniger. Sie gilt als eher lichtscheu und vermehrt sich prächtig, solange sie ignoriert wird. Technische Schuld ist sehr beliebt, da sie dabei hilft, auch anspruchsvolle Terminvorgaben einzuhalten ohne übermäßigen Aufwand spendieren zu müssen. Dennoch sind ihr nicht alle Menschen wohlgesonnen, da ihre Pflege langfristig zunehmend mehr Zeit in Anspruch nimmt. Man sagt ihr auch nach, dass sie für Softwarefehler oder sogar Terminverzögerungen verantwortlich sein soll. Wie ist das möglich?

In diesem Beitrag wollen wir der technischen Schuld die Aufmerksamkeit schenken, die sie verdient. Welche Arten von technischer Schuld gibt es, wo finden wir sie, wie kommt es zu Ihrer Vermehrung und was können wir dafür tun einem exponentiellen Wachstum entgegenzuwirken. Insbesondere wird die Frage beleuchtet, warum sich technische Schuld nicht mit Softwarequalität verträgt, die sich trotz des kurzfristigen, nicht unerheblichen Mehraufwandes, wegen der langfristigen Haltungsvorteile zunehmender Beliebtheit erfreut.

Was ist „Technische Schuld"?

Der Begriff der „Technischen Schuld“, abgeleitet vom englischen „Technical Debt“, bezeichnet eine technische Verschuldung, also sozusagen die Aufnahme eines technischen Kredits. Im Deutschen kann „Schuld“ aber auch im Sinne von „schuldig“ verstanden werden, was automatisch negativ assoziiert und eher in der Rechtsprechung verortet ist. Eine eindeutigere und korrektere Übersetzung für „Technical Debt“ wäre „Technische Schulden“ bzw. „Technischer Kredit“, denn ein (technischer) Kredit kann im Projekt durchaus „unschuldig“, nämlich absichtlich und tatsächlich auch sinnvoll aufgenommen werden, z.B. um ansonsten unrealisierbare Terminvorgaben einzuhalten. Es handelt sich dann um eine bewusste Verschuldung, bei der sich die Schuldfrage nicht stellt. Grundsätzlich sollte man sich bei der Aufnahme eines Kredits aber der Tatsache bewusst sein, dass der Kredit zurückgezahlt werden muss, zumeist inklusive zusätzlich anfallender Zinsen.

Technische Schulden entstehen leider häufig unbewusst und ungeplant, und die trotzdem anfallenden Zinsen summieren sich in Form von Mehraufwänden in der Projekt¬entwicklung und der Projektwartung. Es stellt sich dann durchaus die Frage: Wer ist schuld an der technischen Schuld?

Bild 1 veranschaulicht technische Schulden durch eine Gegenüberstellung des tatsächlich betriebenen Entwicklungsaufwands und einem idealerweise betriebenen Entwicklungsaufwand. Der nicht-betriebene Aufwand in der Design-, Coding- oder Testphase wird zu technischen Schulden.

Arten der technischen Schuld: Die Fauna der Software

Im Prinzip kann jeder Schritt in der Produktentwicklung zur technischen Schuld werden, nämlich dadurch, dass er unzureichend oder gar nicht gemacht wird. Dennoch sollen im Folgenden exemplarisch einige technische Schulden aufgeführt werden, ohne Anspruch auf Vollständigkeit:

• Keine oder unvollständige funktionale Anforderungen

• Keine oder unvollständige Metrik Erfassung

• Keine oder nicht eingehaltene Kodierregeln

• Keine oder fehlerhafte statische Codeanalyse

• Keine, unvollständige oder fehlerhafte Softwaretests (Unit-, Integrations-, Systemtests)

• Keine oder unvollständige Codeabdeckungsmessung

• Keine oder unvollständige Dokumentation

• Keine oder unvollständige Automatisierung

• Unsaubere Architektur (fehlende Modularität, fehlende Hardwareabstraktion, fehlende Kapselung…)

• Komplizierte und komplexe Software

• Viele Codeklone

• Nicht-beseitigte Fehler

Grundsätzlich gilt: Eine nicht-ergriffene Maßnahme zur Sicherung oder Verbesserung der Softwarequalität darf als Beitrag zur technischen Schuld verstanden werden. Insofern ist die Summe der technischen Schulden automatisch umgekehrt proportional zur Softwarequalität und somit auch eine Möglichkeit, Softwarequalität zu messen und zu bewerten. Denn der Aufwand zur Beseitigung der technischen Schuld ist zumindest annäherungsweise schätzbar und je höher der Aufwand, desto geringer die Qualität, wie in Bild 2 veranschaulicht.

Wie entsteht technische Schuld: Aufzucht und Vermehrung

Wie bereits Eingangs erwähnt können technische Schulden durchaus vorsätzlich in Kauf genommen werden, z.B. um sportliche Terminpläne einzuhalten. Steht man in Konkurrenz zu einem Mitbewerberprodukt, dann kann der Zeitpunkt der Markt-einführung mitentscheidend für den Erfolg eines Unternehmens sein. Zum Problem wird es erst dann, wenn die technischen Schulden in der folgenden Produkt¬weiter-entwicklung ignoriert werden, weil man sich der Schulden nicht bewusst ist oder weil man mit dem reduzierten Aufwand ja auch zum Ziel gekommen ist.

Das Problem entsteht dadurch, dass sich nicht nur alte und neue technische Schulden aufsummieren, sondern durch die schlechtere Wartbarkeit des Produkts entstehen auch Entwicklungsbegleitende Mehraufwände, die über die Zeit exponentiell wachsen.

Bild 3 zeigt den exponentiell steigenden Zusatzaufwand, der durch die Vernachlässigung technischer Schulden entstehen kann. Die verringerte Wartbarkeit der Software führt zu einem höheren Entwicklungsaufwand, verursacht höhere Fehlerzahlen und erschwert Fehlerkorrekturen. Mehr Fehler bedeutet, dass mehr Aufwand in Fehlersuche und Fehlerkorrektur investiert werden muss und damit der Neuntwicklung nicht zur Verfügung steht. Das wiederum erhöht den Termindruck im folgenden Release, wodurch wieder mehr Kredit aufgenommen werden muss.

Trotz unmittelbarer Einsparung von Arbeit beim Aufbau von technischen Schulden entsteht also mittel- bis langfristig mehr Arbeit, die zu einer schlechteren Planbarkeit und schließlich zu Terminverzögerungen führen wird.

Erkennen der technischen Schuld: Symptome und Beobachtungstipps

Symptome einer technischen Überschuldung sind das, was mich zu diesem Beitrag motiviert hat. Denn mehrfach bin ich in jüngster Vergangenheit nach Vorträgen zum Thema Softwarequalität (auch und gerade auf dem ESE Kongress) von Zuhörern angesprochen worden, die von zunehmendem Unbehagen bei der täglichen Arbeit getrieben wurden, ein Gespräch zu suchen und im besten Fall Hilfe zu finden. Es waren immer Softwareentwickler aber von verschiedenen Firmen und aus verschiedenen Industriezweigen, die von einer Machtlosigkeit gegenüber der zunehmenden Komplexität und Unwartbarkeit des eigenen Produkts berichteten. Da ich selbst in einem früheren Leben fast 20 Jahre Software entwickelt habe ist mir dieses Gefühl sehr wohl vertraut. Die Verantwortung, die jede Änderung einer Codezeile mit sich bringt, ist groß und wird bei fehlenden Qualitätssicherungsmaßnahmen leider viel zu häufig als Belastung mit nach Hause genommen.

‚Unbehagen‘ ist also ein mögliches erstes Symptom, an dem man das Vorhandensein technischer Schulden erkennen kann. Das ist zwar interessant, aber wenig hilfreich, weil schwerlich objektiv messbar. Auch kann jegliches Unbehagen grundsätzlich andere Ursachen haben. Besser und eindeutiger erkennbar sind technische Schulden an messbaren Größen wie Fehlerzahlen oder Arbeitszeiten, die für Projektentwicklung oder Fehlerbeseitigungen aufgewendet werden. Grundsätzlich sollte eine Softwarequalitätsinitiative immer mit Metriken starten. Zum einen um Defizite zu benennen und gezielt adressieren zu können, zum anderen um durch kontinuierliche Verfolgung der Metriken über die Zeit eine Verbesserung oder eine Verschlechterung der Softwarequalität zu erkennen.

Hier eine Auswahl empfohlener Metriken zur kontinuierlichen Softwarequalitäts-überwachnung:

Requirements

• Anzahl Requirements (System-, High-Level-, Low-Level-)

• Anzahl Testfälle je Requirement

Quellcode

• Anzahl Files, Funktionen, Codezeilen

• Kommentardichte

• Zyklomatische Komplexitäten

Statische Analyse

• Anzahl Infos/Warnings/Errors

Dynamische Tests (Unit-, Integrations-, Systemtests)

• Anzahl Pass/Fail

• Laufzeiten

• Codeabdeckung

Softwarefehler

• Anzahl gefundener Fehler in

•  Statische Analyse

•  Dynamische Analyse

•  Review

•  Neue Tests/Regressionstests

• Anzahl Fehler beim Kunden

Geleistete Mitarbeitenden Stunden für

• Design

• Entwicklung

• Test

• Maintenance

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Adressieren der technischen Schuld: Populationskontrolle und Reduzierung

Manche Metriken können als alleinstehender Wert bereits Anlass zur Ergreifung von Maßnahmen sein. Zum Beispiel sollte möglichst schnell Code korrigiert werden, wenn die statische Analyse Probleme identifiziert hat, die mit geringem Aufwand korrigiert werden können, aber potentiell fatale Auswirkungen haben können, wie z.B. nicht initialisierte Variablen. Auch zyklomatische Komplexitäten von Funktionen sollten gewisse Grenzwerte nicht überschreiten, ein Redesign wird allerdings aufwendiger sein. Andere Metriken werden erst interessant beim Betrachten der Veränderung über die Zeit. In jedem Fall ist es empfehlenswert, alle Metriken über die Zeit zu verfolgen, z.B. um zu überprüfen, ob ergriffene Maßnahmen zum gewünschten Erfolg führen, aber auch um zu erkennen, wenn sich bisher vernachlässigte Metriken in eine falsche Richtung entwickeln.

Bild 4 zeigt Metriken eines Projekts nach einem Jahr der Implementierung eines neuen Features in eine bestehende Codebasis. Die linke Seite zeigt die Veränderungen am Quellcode, speziell dass 42% mehr Source Code dazugekommen sind. Die rechte Seite zeigt die Veränderung der technischen Schuld, mit einem Zuwachs von 28%. Die Höhe der technischen Schuld im Quellcode wurde ermittelt über den (geschätzten) zeitlichen Aufwand, den es benötigen würde zur Beseitigung der jeweils erkannten technischen Schuld.

Basis für die Bewertung und die Analyse der Entwicklung der technischen Schuld ist eine kontinuierliche, automatisierte Erfassung der Metriken. Zum einen sollten die jeweiligen Werte dazu automatisiert ermittelt werden, zum anderen muss diese Ermittlung kontinuierlich erfolgen, die Werte müssen einer Datenablage zugeführt werden und bestenfalls grafisch aufbereitet präsentiert werden. Zusätzlich sollte, wo möglich, eine automatische Überprüfung der Einhaltung von Grenzwerten erfolgen, zum Beispiel die Vermeidung von statische Analyse Fehlern in neuem Code oder das Unterschreiten einer vorgegebenen Obergrenze für die zyklomatische Komplexität von Funktionen.

Bestens geeignet für diese Aufgabe, zumindest, soweit es quellcode- und testspezifische Metriken betrifft, sind Pipelines, wie sie in der heutigen Projektentwicklung im CI-Umfeld bereits gang und gäbe sind. Metriken, die sich aus der statischen Analyse und dem dynamischen Test ergeben, sind dort automatisch verfügbar und die Einhaltung von Obergrenzen kann in ‚Quality-Gates‘ automatisiert überprüft werden. Beispielhaft ist in Bild 5 eine solche Pipeline dargestellt, inklusive finalem Export der Daten an ein zentrales Dashboard.

Die Einrichtung und Betreuung von Pipelines ist mit einem nicht zu unterschätzenden Aufwand verbunden. Auch setzt die in Bild 5 beschriebene Pipeline ein Vorhandensein statischer und dynamischer Testtools voraus. Wenn nichts davon vorhanden ist, dann sollte ein erster Schritt die Erfassung von Basis-Metriken zur Überzeugung des Managements sein, dass eine Einführung entsprechender Tools notwendig ist, um das nötige Investment in Zeit und/oder Geld bereitgestellt zu bekommen. Das können je nach Management verschiedene Metriken sein, z.B. Fehlerstatistiken, Daten bezüglich Softwarekomplexitäten, Arbeitszeiten, Mitarbeiter- oder Kundenzufriedenheiten.

Das initiale Aufsetzen einer Pipeline und der zugehörigen Infrastruktur wird aufgrund der Nähe zum Quellcode und der Komplexität der Aufgabe häufig durch die Entwicklungsabteilung erfolgen, die weitere Betreuung sollte aber, je nach Mitarbeiterzahlen, durch eine Test- und Qualitätsabteilung übernommen werden. Und auch wenn Quellcode, Testdaten und Qualitätsvorgaben immer identisch sind, werden final unterschiedliche Pipelines für verschiedene Anwendungsfälle benötigt, wie in Bild 6 dargestellt.

Die Entwicklungsabteilung wird zu jedem Entwicklungsschritt Quellcode und Testfälle auschecken, Änderungen an Code und Testfällen vornehmen und erwartet eine Pipeline, die möglichst schnell Ergebnisse liefert, um fehlerhafte Testfälle zu korrigieren, statische Analyse-Meldungen zu adressieren und iterativ alles zu tun, um die Quality-Gates einzuhalten. Verkürzte Laufzeiten der Pipeline können z.B. durch Testfall Priorisierung oder inkrementelle Testfallausführung auf nur einer Codevariante und im Simulator erreicht werden.

Aufgabe der Test- und Qualitätsabteilung ist die Kontrolle der Reports und der Funktion der automatisierten Pipelines sowie die Sicherstellung der Vollständigkeit der Metriken und der Tests. Fehlende Testfälle sollten entsprechend ergänzt werden. Falls Metriken oder Tools fehlen, oder wenn Laufzeiten der Pipelines zu lang werden, sollte das Management involviert werden, um entsprechend aufzurüsten.

Eine oder mehrere automatisierte Pipelines sollten regelmäßig oder wenigstens vor jedem Merge-Request einen vollen Testlauf auf allen Quellcodevarianten und allen Zielsystemen durchführen, und nur bei Einhaltung der Zielvorgaben aus den Quality-Gates eine Freigabe für weitere Schritte erteilen. Hier kann auch ein Export von Daten an ein Qualitäts-Dashboard erfolgen.

Zusammenfassung

Produktqualität und speziell die Qualität der Software in einem Produkt sind ausschlaggebend nicht nur für die Kundinnen- und Kundenzufriedenheit, sondern auch für die Mitarbeiterinnen- und Mitarbeiterzufriedenheit und die Identifikation mit dem eigenen Produkt. Die ersten Mitarbeitenden, die mit wachsenden technischen Schulden zu kämpfen haben, sind die Softwareentwicklerinnen und Entwickler, ein unspezifisches Unbehagen in der Entwicklung sollte also nicht ignoriert, sondern konsequent adressiert werden. Eine Initiative zur Reduktion der technischen Schulden sollte daher bestenfalls aus der Entwicklung kommen, bevor andere Abteilungen die Auswirkungen zu spüren bekommen.

Unterstützt durch entsprechende Metriken sollte ein Unbehagen der Entwickelnden bezüglich der Softwarequalität mit dem Management geteilt werden, damit Ressourcen zur Verfügung gestellt werden, um bestehende technische Schulden zu analysieren und kontinuierlich zu reduzieren, und neue technische Schulden zu vermeiden.

Pipelines mit Quality-Gates und Anbindung an Qualitäts-Dashboards sind bestens dazu geeignet, technische Schulden im Produkt und deren Entwicklung über die Zeit zu verfolgen.

 (sg)

Dieser Beitrag stammt aus dem Tagungsband zum ESE-Kongress 2025

* Ingo Nickles blickt auf mehr als 20 Jahre Berufserfahrung in der Softwarentwicklung für embedded Geräte in der Telekommunikationsbranche zurück. Seit 2012 ist er Field Application Engineer für die Firma Vector und verantwortlich für Schulungen, Seminare, Präsentationen und den Support rund um PC-lint Plus und die VectorCAST Produktfamilie.

(ID:50916205)