15.07.2024 - Tobias Hundt
⏱ Lesedauer: 5 Minuten
Technische Schulden und was Sie darüber wissen sollten
Wer Software entwickelt kennt den Begriff der "Technischen Schuld". Er beschreibt eine Anhäufung von Qualitätsmängeln im Verlaufe eines Softwareprojektes, die aus bestimmten Gründen entstehen. An dieser Stelle wollen wir uns dieses Thema etwas genauer ansehen und beleuchten, welche Auswirkungen sie haben, wie wir sie für uns nutzbar machen können und wie wir sie wieder loswerden.
Grafik KI-generiert
Was sind technische Schulden und woher kommen sie?
Die Arbeit, die ein Software-Entwickler in das Entwickeln und Schreiben von Code steckt kann in zwei Kategorien eingeteilt werden. Die eine Kategorie wird vom Nutzer wahrgenommen und erzeugt dort Wert. Dazu gehören neue Funktionen, neue Integrationen oder die Optimierung von spürbaren Performance-Defiziten. Die andere Kategorie wird nicht vom Nutzer wahrgenommen und erzeugt dort nicht direkt Wert. Das sind beispielsweise Architekturanpassungen, die nötig werden, um im weiteren Projektverlauf die geforderten Features umsetzen zu können oder um Code-Komplexität zu reduzieren. Es ist oft schwer, dem Kunden zu vermitteln, warum wir unsere Arbeitszeit in die zweite Kategorie stecken sollten, wenn sie doch nicht unmittelbar zu seinem Wertgewinn beiträgt. Allerdings trägt sie zu seinem Wertverlust bei, wenn wir sie vernachlässigen. Warum ist das so?
Technische Schulden sind
hingenommene Qualitätsdefizite
Wann immer wir Software entwickeln treffen wir Entscheidungen für eine bestimmte Architektur oder ein bestimmtes Datenbank-Design. Diese Entscheidung treffen wir auf Grundlage der aktuellen Anforderungen und unseres aktuellen Wissens. Mit dieser Entscheidung leben wir, bis wir neue Anforderungen oder neues Wissen haben und veranlasst sind, diese Entscheidung zu überdenken.
Beispielsweise entscheiden wir, eine Funktion in einen eignen Microservice auslagern zu wollen. Vorher war das nicht nötig, aber nun wird diese Funktion so wichtig, dass ein eigenes Team daran arbeiten und sie weiterentwickeln soll.
Das Auslagern dieser Funktion kostet Zeit und Geld und schafft dem Kunden keinen direkten Wert. Er bekommt im besten Falle nicht einmal mit, dass sich etwas geändert hat. Wir müssen nun entscheiden, ob wir diese Architektur-Änderung bzw. dieses Refactoring jetzt einplanen und möglichst schnell umsetzen, damit das neue, dedizierte Team in Kürze die Arbeit aufnehmen kann, oder ob wir aufgrund des hohen Drucks durch den Kunden die Anforderungen an neue Features erfüllen wollen. Wir entscheiden uns, das Refactoring nach hinten zu schieben bis der Druck nachlässt und wir wieder mehr Zeit für Aufräumarbeiten haben. Mit dieser Entscheidung haben wir eine neue technische Schuld auf unserem Konto, mit der wir die schnellere Feature-Entwicklung erkauft haben, die der Kunde erwartet.
Welche Auswirkungen haben technische Schulden?
Wie oben beschrieben sind technische Schulden unterlassene aber notwendige Anpassungsleistungen. Im Prinzip also hingenommene Qualitätseinbußen. In der Folge gibt es viele Auswirkungen, von denen drei skizziert werden sollen:
- Um weiterhin Features zu liefern, obwohl die architektonischen Grundlagen nicht mehr hinreichend sind, müssen Entwickler immer häufiger Kompromisse eingehen und Workarounds hinnehmen, die es ohne diese technische Schuld nicht bräuchte. Das verringert die Code-Qualität nur noch weiter. Das ohnehin schon schwierige Refactoring wird nach und nach noch schwieriger und damit teurer.
- Die tatsächliche Arbeit dauert immer länger. Aus dem Beispiel von oben: Das neue, dedizierte Team nimmt seine Arbeit auf und entwickelt Änderungen an der wichtiger werdenden Funktion, die immer noch sehr eingebettet ist in die übergeordnete Codebasis. Das führt zu Abhängigkeiten zwischen dem Basis-Team und dem Feature-Team. Man muss sich aufwändig koordinieren, regelmäßig Austausch finden, gehäuft Merge-Konflikte lösen, die es ohne die technische Schuld nicht bräuchte. Beide Teams können nicht ihr Potential entfalten.
- Das Testing der qualitätsreduzierten und workaround-behafteten Code-Basis wird immer komplexer und fehleranfälliger. Gepaart mit einer höheren Bug-Wahrsheinlichkeit ergibt sich daraus eine gesteigerte Menge von Funktions-einschränkungen, Systemausfällen und am Ende eine verringerte Zuverlässigkeit, die der Kunde spürt. Das hat auch einen Einfluss auf unsere Mitarbeitenden, die immer häufiger debuggen müssen und unter noch höherem Druck stehen.
Diese Auswirkungen können wir reduzieren, indem wir eine saubere Test-Strategie einsetzen, die uns weitgehend beschützt, Bugs und Fehler zu produzieren und die uns zwingt, Best Practices einzuhalten. Wichtig ist allerdings: Auch wenn die Tests viele Fehlerquellen reduzieren sind sie keine Alternative zum Abarbeiten der technischen Schuld.
Können wir technische Schulden für uns nutzbar machen?
Technische Schulden sind nicht per sé schlecht. Richtig eingesetzt sind sie ein Werkzeug im Repertoire des Teams. Wir führen dazu eine Schuldenliste, um einen Überblick über ausstehende Refactorings zu behalten. Kommt eine dringende Anforderung des Kunden rein, kann die Entscheidung richtig sein, eine technische Schuld einzugehen und sich darauf zu verständigen, dass diese schnellstmöglich abgearbeitet wird. Das ist essentiell, um nicht in der beschriebenen Abwärtsspirale zu landen, aus der wir immer schwerer heraus kommen.
Technische Schulden sind auch
ein Management-Werkzeug
Eine ausgereifte Test-Strategie kann uns in diesen Fällen mehr Vertrauen geben, wenn wir wissen, dass eine technische Schuld keine all zu gefährlichen Auswirkungen haben kann. Treffen wir diese Entscheidung, ist auch die Einbindung des Kunden wichtig. Wenn wir transparent kommunizieren, dass wir für den kurzfristigen Geschwindigkeitsgewinn die Refactoring-Arbeiten vernachlässigen, können wir auch argumentieren, dass wir im nächsten Sprint diese Aufräumarbeiten nachholen und dafür auf eine Feature-Implementation verzichten müssen. Kommunizieren wir nicht transparent kann der Kunde das Gefühl bekommen, dass das Team nun immer so schnell neue Features implementiert und wird nur noch schwerer davon zu überzeugen sein, dass das Team Zeit für Refactorings benötigt, die ihm keinen direkt sichtbaren Wert liefern.
Wie werden wir technische Schulden wieder los?
Der effektivste Ansatz ist natürlich, erst gar keine technischen Schulden zu akzeptieren. Wir geben Änderungen an der Architektur oder an Datenbankdesigns immer den Vorrang vor Bug-Fixings oder Feature-Requests des Kunden. Diese Idee scheitert allerdings sofort an der Realität, da wir dem Kunden möglichst schnell und zuverlässigen Wert liefern wollen.
Ein oft zitierter Mittelweg ist, einen gewissen Teil der regulären Arbeit für Refactorings zu blocken, um auf aufkommende Änderungen schnell reagieren zu können und nicht gegen Feature-Implementierungen abwägen zu müssen. Oft werden 20% der Zeit als Faustformel für Refactoring eingeplant. Das stellt eine durchgehend bessere Codebasis sicher und erlaubt gleichbleibend hohe Entwicklungsgeschwindigkeiten.
Sollten dennoch technische Schulden anfallen, sei es aus expliziter Entscheidung oder aus unvorhergesehenem Wissensgewinn, müssen auch diese wieder abgearbeitet werden. Hier können wir die Abwägung treffen, ob wir sie in unserer regulären Refactoring-Zeit abarbeiten können, oder ob sie dafür zu groß sind und wir beispielswiese einen Refactoring-Sprint brauchen, um im Anschluss wieder mit gewohnter Geschwindigkeit weiterarbeiten zu können.
Möchten Sie mehr über dieses Thema erfahren oder mir Feedback geben, schreiben Sie mir gern unter:
Blue Atlas Technologies GmbH
Altewiekring 20a
38102 Braunschweig
Telefon: +49 176 637 645 63