Was sind Technische Schulden?
Es gibt ein Zitat von Steve McConnell "The trouble with quick and dirty is that dirty remains long after quick has been forgotten." Dies zeigt treffend, wo wir in der Softwareentwicklung Schulden anhäufen - nämlich immer da, wo wir etwas „später noch einmal richtig” machen wollen.
Dokumentation? Refactoring? Umzug auf eine andere Datenbank? Alles Dinge, die wir uns vornehmen, wenn einmal Zeit ist, und ständig kommt uns das Tagesgeschäft dazwischen.
Der Begriff, den wir hier beschreiben, ist „Technische Schulden”. Genau wie ihr Vorbild aus dem Bankwesen muss man sie irgendwann tilgen und sie kosten uns Zinsen. Im Falle von Technischen Schulden besteht die Zinslast aus immer weniger Output. Mehr suchen, mehr fluchen, wir werden langsam und unflexibel.
Technische Schulden sichtbar machen
Das Problem erkennen und sichtbar machen ist hier der erste und zugleich auch schwierigste Schritt. Wir hören in Projekten oft von Diskussionen, dass Technische Schulden etwas Esoterisches seien und die Teams sollen doch lieber weiter an Features arbeiten.
Um dieser Wahrnehmung vorzubeugen, empfiehlt sich maximale Transparenz. Ein Beispiel: Immer wenn Sie sich dabei ertappen zu sagen "das mach ich später noch einmal, dann aber richtig" legen Sie ein Ticket an. Sammeln Sie alle Tickets, die Technische Schuld bedeuten, auf einer separaten Swimlane auf dem Task-Board Ihres Teams - das gibt allen Stakeholdern ein Gefühl für den aktuellen „Schuldenstand”.
Eleganter geht es mit Tools, welche die Technischen Schulden der eigenen Codebasis für Sie ausrechnen - ein Beispiel ist CQSE's Teamscale.
An dieser Stelle ein Wort der Warnung: hier kann es bei den ersten Analysen zu mehreren Personenjahren an Technischen Schulden kommen. Wie Sie hier priorisieren und Ihre Energie sinnvoll einsetzen, zeigt der folgende Abschnitt.
Wie den Schuldenabbau priorisieren?
Nachdem wir nun gesehen haben, was Technische Schulden sind und wie man sie sichtbar macht, bleibt zu klären, wo am sinnvollsten mit dem Schuldenabbau begonnen werden sollte.
Mehrere Personenmonate oder -jahre abzutragen würde bedeuten, dass de facto jede Arbeit an dem Produkt eingestellt werden müsste.
Hier kann es helfen, zunächst einmal die Komplexität in die Betrachtung mit aufzunehmen. Eine Funktion, die absolut selbsterklärend ist, kommt gut ohne Dokumentation aus, während ein hochkomplexer Algorithmus mit Rekursion und Sprüngen nach perfekter Doku verlangt. Ein Maß für Komplexität wäre hier z.B. die „zyklomatische Komplexität” von McCabe.
Mit anderen Worten: Der Abbau von Technischen Schulden sollte dort starten, wo der Code die höchste Komplexität aufweist.
In den meisten Code Bases gibt es allerdings jede Menge solcher Bereiche mit hoher Komplexität - wir sind also wieder am Beginn: Wo anfangen?
Unser Tipp lautet, hier die Komplexität des Codes in ein Verhältnis zur Commit History Ihres Repositories zu setzen - dies zeigt Ihnen die stark frequentierten Dateien.
Fazit
Wie auch im richtigen Leben rächt es sich irgendwann, wenn einmal am falschen Ende gespart wurde.
Je länger man seine Schulden anstehen lässt, desto schwieriger wird es, sie wieder abzubauen.
Eine gemeinsame Identifikation und Priorisierung der Schulden sowie ein realistischer Abbauplan sind somit das Ergebnis einer „Schuldnerberatung”, auch für technische Schulden.
Wenn wir Sie neugierig gemacht haben, dann freuen wir uns über eine Nachricht von Ihnen.