Warum ich technische Schulden nicht verurteile

Mein Hintergrund

Bevor wir in das eigentliche Thema einsteigen, möchte ich etwas über meinen Hintergrund erzählen. Im Herzen bin ich Softwareentwickler. Ich mache Dinge gern richtig, und Prinzipien sind mir sehr wichtig, auch wenn sie sich rational nur schwer begründen lassen. Mit den Jahren wird man natürlich pragmatischer. Man erkennt, dass Dinge nicht immer perfekt sein können oder sollten, denn Perfektion (sofern es sie überhaupt gibt) hat ihren Preis. Diese Entwicklung führte mich zu einem Gedanken: Technische Schulden sind nicht grundsätzlich schlecht. Sie sind ein Werkzeug, das wir einsetzen können und das uns enorm dabei helfen kann, unsere Ziele zu erreichen.

Was sind Schulden?

Bevor wir direkt auf technische Schulden eingehen, betrachten wir zunächst Schulden im Allgemeinen.

Schulden sind eine Verpflichtung, durch die eine Partei Geld zurückzahlen muss, das sie von einer anderen Partei geliehen oder auf andere Weise erhalten hat.

Man erhält also Geld, das man zu einem späteren Zeitpunkt zurückzahlen muss. Dadurch können wir Investitionen tätigen, die sonst nicht möglich wären. Denken wir zum Beispiel an Wohneigentum. Ein Haus im Wert von 600.000 € aus eigenen Mitteln zu kaufen, wird immer seltener. Stattdessen geht man zu einer Bank, nimmt einen Kredit auf und kann das Haus kaufen. Natürlich hat das seinen Preis: Zinsen. Insgesamt muss man der Bank mehr Geld zurückzahlen, als man erhalten hat. Trotzdem tun es viele Menschen. Es hängt also alles von den konkreten Kreditbedingungen ab: Wie viel mehr muss zurückgezahlt werden, und in welchem Zeitraum? Diese Bedingungen entscheiden darüber, ob Schulden ein allgemein empfehlenswertes Werkzeug sind oder etwas, das zum vollständigen Bankrott führen kann. Es gibt also gute und schlechte Schulden.

Technische Schulden

Nun möchte ich die Brücke zu technischen Schulden schlagen.

Technische Schulden sind eine qualitative Beschreibung der Kosten für die Wartung eines Systems, die darauf zurückzuführen sind, dass bei seiner Entwicklung eine kurzfristig zweckmäßige Lösung gewählt wurde.

Zu einem bestimmten Zeitpunkt entscheidet man sich dafür, ein Problem in der Codebasis auf eine bestimmte Weise zu lösen. Gleichzeitig geht man davon aus, dass dieser Ansatz spätere Änderungen erschwert oder dass die gewählte Lösung sogar vollständig neu umgesetzt werden muss, um das Produkt langfristig am Leben zu halten. Die Frage lautet: Warum trifft man eine solche Entscheidung überhaupt? Zwei mögliche Antworten fallen mir ein:

1. Uns war nicht bewusst, dass eine Entscheidung die zukünftige Entwicklung negativ beeinflusst.
2. Wir haben Abkürzungen genommen, um schneller zu sein.

Antwort 1 steht nicht im Mittelpunkt dieses Artikels. Deshalb betrachten wir zunächst Punkt 2 genauer: technische Schulden, die wir bewusst aufnehmen.

Wenn wir absichtlich eine „schlechtere“ Lösung wählen, tun wir das, weil sie uns in der Gegenwart einen Vorteil verschafft - meist Geschwindigkeit. Eine frühere Veröffentlichung kann uns helfen, eine Idee zu validieren, vor der Konkurrenz auf den Markt zu kommen oder unsere begrenzten Ressourcen auf etwas Wichtigeres zu konzentrieren. Diese Abwägung kann sich lohnen, doch nicht jede Abkürzung hat dieselben Folgen. Manche bleiben über Jahre günstig, andere wachsen so lange, bis sie die weitere Entwicklung nahezu zum Stillstand bringen. Um den Unterschied zu erkennen, müssen wir die Bedingungen der Schulden genauer betrachten.

Verschiedene Arten technischer Schulden klassifizieren

Wir haben gelernt, dass technische Schulden gut oder schlecht sein können. Nun möchte ich versuchen, ein Modell zu entwickeln, das dabei hilft, die eigene Position in diesem Spektrum zu bestimmen und sie aktiv in eine günstigere Richtung zu lenken.

Die erste Dimension lässt sich direkt von gewöhnlichen finanziellen Schulden ableiten: der Zinssatz. Wenn wir Geld leihen, zeigt der Zinssatz, wie viel mehr wir zurückzahlen müssen. Dieses Prinzip lässt sich auch auf technische Schulden übertragen. Wenn ich heute auf eine Funktion verzichte, deren Umsetzung zehn Stunden dauern würde: Wie lange würde es dauern, sie in einem Jahr umzusetzen? Abhängig vom Kontext und von der Entwicklung des Systems kann dieser Aufwand drastisch steigen. Wenn man beispielsweise die Grundlagen für Authentifizierung und Autorisierung von Beginn an schafft, lässt sich das relativ schnell erledigen. Beides erst hinzuzufügen, nachdem die gesamte Anwendung fertiggestellt wurde, kann dagegen sehr schmerzhaft sein. Am anderen Ende des Spektrums könnte es eine zentrale Modal-Komponente geben, die in der ganzen Anwendung wiederverwendet wird, und wir überlegen, eine ansprechende Ein- und Ausblendanimation hinzuzufügen. Für den Aufwand spielt es kaum eine Rolle, ob wir die Animation heute oder in einem Jahr ergänzen. Solange alle Stellen bereits die zentrale Modal-Komponente verwenden, können wir die Animation einmal hinzufügen und sie überall nutzen.

Die zweite Dimension ist die angenommene Wahrscheinlichkeit, dass wir die technischen Schulden zurückzahlen müssen. Eine Funktion, die nie genutzt wird, ein Produkt, das keinen Markt findet, oder ein verworfenes Experiment machen es möglicherweise überflüssig, die dabei entstandenen technischen Schulden jemals vollständig zurückzuzahlen. Aus rein wirtschaftlicher Sicht wäre es Verschwendung gewesen, stark in die perfekte Architektur einer solchen Funktion zu investieren.

Die Kosten technischer Schulden hängen also nicht nur davon ab, wie teuer ihre Rückzahlung wäre. Sie hängen auch davon ab, wie wahrscheinlich diese Rückzahlung ist. Aus der Kombination dieser beiden Dimensionen ergibt sich ein einfaches Modell zur Klassifizierung technischer Schulden:

Cheap Option - Günstige Option

Schulden mit niedrigem Zinssatz und geringer Rückzahlungswahrscheinlichkeit sind normalerweise eine vernünftige Abwägung. Es ist unwahrscheinlich, dass sie relevant werden, und eine spätere Korrektur wäre nicht wesentlich teurer.

Calculated Gamble - Kalkuliertes Risiko

Schulden mit hohem Zinssatz, aber geringer Rückzahlungswahrscheinlichkeit sind schwieriger zu beurteilen. Die Abkürzung könnte teuer werden, aber nur, wenn die Funktion erfolgreich ist oder bestimmte Anforderungen entstehen. Für ein Experiment kann das eine rationale Wette sein, solange wir die zugrunde liegenden Annahmen im Blick behalten. Solche Entscheidungen sollten genau beobachtet werden, damit wir so schnell wie möglich reagieren können.

Manageable Dept - Beherrschbare Schulden

Schulden mit niedrigem Zinssatz, aber hoher Rückzahlungswahrscheinlichkeit müssen wahrscheinlich behoben werden. Durch das Warten werden sie jedoch nicht wesentlich teurer. Wir sollten sie sichtbar machen und die Rückzahlung einplanen, sobald sie sinnvoll wird.

Dangerous Dept - Gefährliche Schulden

Schulden mit hohem Zinssatz und hoher Rückzahlungswahrscheinlichkeit sind die gefährliche Variante. Sie betreffen einen Bereich, der sich mit großer Wahrscheinlichkeit weiterentwickeln wird, während jede neue Funktion die spätere Korrektur verteuert. Solche Schulden sollten nur dann aufgenommen werden, wenn der kurzfristige Nutzen außergewöhnlich groß ist und es einen ausdrücklichen Rückzahlungsplan gibt.

Schulden verursachen auch laufende Kosten

Bisher haben wir die Rückzahlung als einmaliges zukünftiges Ereignis betrachtet. In der Realität können technische Schulden jedoch auch fortlaufende Zinsen verursachen.

Eine Abkürzung kann dazu führen, dass jede zukünftige Änderung länger dauert. Sie kann regelmäßige Produktionsstörungen verursachen, manuelle Eingriffe erfordern oder dafür sorgen, dass Entwickler:innen Angst haben, einen Teil des Systems anzufassen. Diese Kosten zahlen wir immer wieder – selbst wenn wir die Schulden nie formell zurückzahlen.

Deshalb sollten technische Schulden nicht nur anhand des Aufwands gemessen werden, der zu ihrer Beseitigung nötig ist. Wir sollten auch fragen:

• Wie häufig werden wir in dem betroffenen Bereich arbeiten?
• Um wie viel langsamer wird jede Änderung?
• Können die Schulden Sicherheits-, Zuverlässigkeits- oder Compliance-Probleme verursachen?
• Sind die Schulden isoliert, oder werden andere Teile des Systems davon abhängig?
• Werden wir bemerken, wenn sich die Annahmen hinter unserer Entscheidung ändern?

Eine hilfreiche Zusammenfassung lautet:

Erwartete Kosten = Rückzahlungswahrscheinlichkeit × Rückzahlungskosten + aufgelaufene Zinsen

Das muss keine exakte Berechnung sein. Der Zweck besteht darin, die Abwägung sichtbar zu machen und die Diskussion darüber zu verbessern.

Schulden bewusst aufnehmen

Die Schlussfolgerung sollte nicht lauten, dass technische Schulden unwichtig sind. Sie sollte lauten, dass eine pauschale Verurteilung technischer Schulden uns daran hindert, rationale Abwägungen zu treffen.

Wenn ich bewusst technische Schulden aufnehme, helfen mir fünf Fragen:

1. Was gewinnen wir heute?
2. Was genau würde die Rückzahlung umfassen?
3. Wie wachsen die Rückzahlungskosten im Laufe der Zeit?
4. Wie wahrscheinlich ist es, dass wir den betroffenen Code in Zukunft benötigen?
5. Welches Signal zeigt uns, dass es Zeit für die Rückzahlung ist?

Die Antworten festzuhalten, muss kein langwieriger Prozess sein. Ein Kommentar in einem Architecture Decision Record oder ein Ticket mit einem Link zum relevanten Kontext kann genügen. Entscheidend ist, dass die Abkürzung eine bewusste Entscheidung bleibt, statt sich langsam in eine unerklärte Einschränkung zu verwandeln.

Wir sollten außerdem die Umkehrbarkeit berücksichtigen. Schulden in einer isolierten UI-Komponente unterscheiden sich von Schulden in der Authentifizierung, Abrechnung oder im zentralen Datenmodell. Manche Entscheidungen lassen sich günstig rückgängig machen, während andere sich im gesamten System ausbreiten. Je schwieriger eine Entscheidung umzukehren ist, desto sorgfältiger sollten wir sein, bevor wir sie akzeptieren.

Die Kosten unbeabsichtigter Schulden reduzieren

Nachdem wir bewusste technische Schulden betrachtet haben, können wir zum ersten der zuvor genannten Gründe zurückkehren: Manchmal wissen wir schlicht nicht, dass eine Entscheidung die zukünftige Entwicklung negativ beeinflussen wird. Das Ergebnis hängt nicht vollständig vom Glück ab. Wir können nicht jede Folge einer technischen Entscheidung vorhersagen, aber wir können beeinflussen, wie teuer ein unvorhergesehener Fehler wird.

Engineering-Praktiken wie automatisierte Tests, modulare Architektur, klare Grenzen, Code-Reviews, Observability und regelmäßiges Refactoring machen ein System widerstandsfähiger gegenüber Entscheidungen, die sich später als falsch herausstellen. Sie verhindern unbeabsichtigte technische Schulden nicht, können aber ihren Zinssatz senken und ihren Wirkungsradius begrenzen. Ein Fehler hinter einer klar definierten Schnittstelle lässt sich normalerweise leichter korrigieren als einer, der sich in der gesamten Codebasis ausgebreitet hat.

Das ist ein weiterer Grund, warum gute Engineering-Praktiken wichtig sind, selbst wenn sich ihr unmittelbarer geschäftlicher Nutzen nur schwer beziffern lässt: Sie eröffnen uns Handlungsmöglichkeiten, wenn sich unsere Annahmen als falsch erweisen.

Fazit

Technische Schulden sind per Definition weder gut noch schlecht. Wie finanzielle Schulden erlauben sie uns, zukünftige Ressourcen einzusetzen, um heute etwas zu erreichen. Das kann uns helfen, eine Idee zu validieren, früher in einen Markt einzutreten oder begrenzte Entwicklungskapazitäten auf das wichtigste Problem zu konzentrieren.

Doch Schulden sind nur dann ein nützliches Werkzeug, wenn wir ihre Bedingungen verstehen. Wir müssen wissen, was wir gewinnen, welche Zinsen wir zahlen, wie wahrscheinlich die Rückzahlung ist und ob die Kosten außer Kontrolle geraten können.

Das Ziel guter Softwareentwicklung besteht daher nicht darin, technische Schulden vollständig zu vermeiden. Es besteht darin, die richtigen Schulden aus dem richtigen Grund und zu Bedingungen aufzunehmen, die wir uns leisten können.