Technische Schulden verfolgen mit NDepend 2017.2

NDepend nutzte ich mittlerweile häufig zur Analyse meiner Anwendungen. Die statische Codeanalyse liefert zwar kein vollständiges Bild zum Zustand einer Anwendung, aber man erhält genügend Informationen um Probleme frühzeitig zu erkennen. Die früheren Versionen hatte ich bereits hier und hier beschrieben. In der neusten Version kommt nun das Thema der technischen Schulden grosse Beachtung. Ein leicht zu verstehender Indikator liefert einem schnell einen Wert um Projekte untereinander zu vergleichen. Genau so etwas hatte ich bereits in meinem ersten Beitrag dazu gewünscht.

Technische Schulden?

Als technische Schulden bezeichnet man all die Abkürzungen und Hacks, die einem in der Vergangenheit ein zügiges Release ermöglichten und nun je länger je mehr im Weg stehen. Die Hacks bringen einem einen kurzen Vorteil, doch sind die damit verbundenen Folgekosten nicht zu unterschätzen.

Genauso so verhält es sich auch bei den Schulden in der nicht-virtuellen Welt: Richtig genutzt kann man schnell etwas haben worauf man sonst lange warten muss (z.B. mittels Hypothek ein Eigenheim kaufen, dafür keine Miete mehr bezahlen um so langfristig finanziell besser dazustehen).
Allerdings kann man auch Schulden für Konsumgüter anhäufen, bei denen man am Ende nichts an Wert mehr besitzt, während man immer noch die Schuldzinsen bezahlt – ohne die Schulden selbst je tilgen zu können. Viele technische Schulden fallen in diese Kategorie. Ein kurzer Gewinn steht langen Zinszahlungen gegenüber: Keine durchdachten Datenstrukturen, keinerlei Tests, keine klaren Anforderungen usw. erschweren einem die tägliche Arbeit.

Baut man diese technischen Schulden nie ab (z.B. mittels Refactoring), befindet man sich schnell in einer Abwärtsspirale: Neue technische Schulden werden angehäuft um überhaupt noch etwas machen zu können. Nur verlangsamen diese einem erneut, was im nächsten Sprint noch mehr Hacks erfordert. Am Ende dieser Spirale steht kein funktionierendes Release, sondern der unausweichliche grosse Crash.

Wie misst NDepend die technischen Schulden?

In NDepend gibt es unzählige vorgefertigte Regeln. Beim Sammeln und auflisten der Regelverstösse war NDepend schon immer sehr gut. Neu wird jede dieser Regelverstösse gezählt und mit einem Zeitaufwand für die Behebung multipliziert. Dieser Multiplikator ist frei wählbar und kann bei komplexeren Projekten erhöht werden.

Für die Beurteilung von A (gut) bis E (sehr schlecht) werden die Kosten für die Neuerstellung dem Aufwand zur Behebung aller technischen Schulden gegenübergestellt. Somit hat man einen Wert in Relation zur Anwendungsgrösse und kann sehr einfach über mehrere Projekte beurteilen, wo man als erstes Zeit investieren sollte.

Bei den jährlichen Zinsen lässt sich der Berechnungsfaktor nach Schweregrad festlegen. Dies finde ich sehr praktisch, da kritische Fehler in der Regel viel grössere Auswirkungen auf die Weiterentwicklung haben als schematische Nuancen.

Wo beginnen?

Sobald man eine Auswertung der technischen Schulden vor sich hat, dürften die meisten erstaunt sein wie hoch diese ausfällt. Die nächste Reaktion ist dann die Frage, wo man mit dem Abbau beginnen soll.

NDepend hilft einem mit dieser Frage bei der Auflistung der Regelverstösse. Dort wird nicht nur die technische Schuld und die jährlichen Zinsen angezeigt, sondern auch wann die geschätzten Kosten zur Behebung gleich hoch sind wie die geschätzten Zinskosten. Diesen Wert sieht man in der Spalte Breaking Point, wo sich bei einem kleineren Wert die Beseitigung der Schulden schneller rechnet.

Ein Rechenbeispiel mit der untersten Zeile: 30 Sekunden zur Behebung stehen jährlichen Zinsen von 2 Minuten entgegen. Nach einem viertel Jahr (~91 Tage) kosten die Zinsen gleich viel wie die Behebung.

Da die Zinsen ständig wachsen, sollte man sich zuerst mit tiefen Breaking Points beschäftigen. Hier wirkt der Hebel am stärksten, reduziert man doch mit 30 Sekunden Aufwand heute die Schulden in einem Jahr um 2 Minuten.

Was mit diesen kleinen Zahlen beim Template für Webanwendungen lächerlich unwichtig erscheint, sieht bei realen Projekten schon ganz anders aus. Da rechnen wir dann nicht mehr in Minuten, sondern in Stunden und Wochen. Wer dann noch die Tage der Zinsen mit den Tagesansätzen der Entwickler multipliziert, sieht dann sehr deutlich, was da für Kosten auf einem zukommen.

NDepend bietet neben dem Aufwand in Tagen auch die Darstellung der Kosten an. Diese Auswertung dürfte für so manche Geschäfts- und Projektleitung unangenehm hohe Zahlen enthalten...

Veränderungen verfolgen

Führt man die Analysen mit NDepend regelmässig mit jedem Release durch, kann man die Veränderungen der technischen Schulden und der Qualität der Anwendung jedem Release genau zuordnen. Die Ergebnisse können dann in die Retrospektive einfliessen, was wiederum eine nachhaltige Verbesserung bewirken kann. Allerdings bedingt dies die Bereitschaft, aus den gewonnenen Informationen auch Aktivitäten abzuleiten. NDepend kann einem diese Arbeit auch in der neusten Version nicht abnehmen.

Fazit

Die neuste Version von NDepend macht einen grossen Sprung vorwärts und beantworten gerade im Bereich der technischen Schulden viele Fragen, die man sich oft nicht zu stellen wagt. Diese Informationen kann man zur Planung der nächsten Schritte benutzen, ohne sich stundenlang in komplizierten Reports zu vertiefen. Diesbezüglich hat NDepend aus meiner Sicht einen grossen Sprung in die richtige Richtung gemacht.

Update (10.7.2017 21:10): Kleiner Fehler im Kapitel "Technische Schulden?" korrigiert und Beispiel ergänzt.