Technische Schulden: Die versteckten Kosten
Technische Schulden:
Die versteckten Kosten von "Wir machen das später richtig"
In jeder Codebasis, jeder Systemarchitektur und jedem Produktionsprozess gibt es eine Entscheidung, die unter Druck getroffen und nie wieder überprüft wurde. Eine Übergangslösung, die dauerhaft wurde. Eine temporäre Lösung, die länger überdauerte als der Projektmanager, der sie genehmigt hatte. Ein Kommentar mit dem Inhalt // TODO: Dies richtig beheben — datiert auf vor drei Jahren.
Das sind technische Schulden. Und im Gegensatz zu finanziellen Schulden tauchen sie in keiner Bilanz auf, bis die Zinszahlung fällig wird.
01. WAS TECHNISCHE SCHULDEN EIGENTLICH SIND
Der Begriff wurde 1992 vom Softwareentwickler Ward Cunningham geprägt, aber das Konzept gilt weit über Code hinaus. Technische Schulden sind die kumulierten Kosten, die entstehen, wenn man jetzt eine schnellere oder einfachere Lösung wählt, anstatt die bessere, die länger dauern würde.
Wie finanzielle Schulden haben sie eine Hauptsumme und einen Zinsbestandteil. Die Hauptsumme ist die Nacharbeit, die erforderlich ist, um die richtige Lösung zu implementieren. Die Zinsen sind die laufenden Kosten, die entstehen, wenn man mit der Abkürzung arbeitet — langsamere Entwicklung, schwierigere Wartung, anfälligere Systeme, höhere Fehlerquoten.
Der entscheidende Unterschied zu finanziellen Schulden: Technische Schulden summieren sich stillschweigend. Sie erhalten keine monatliche Abrechnung. Die Zinsen fallen unsichtbar in Form von geringerer Entwicklungsgeschwindigkeit, einer höheren Anzahl an Fehlern, längeren Onboarding-Zeiten für neue Entwickler und Systemen, die zunehmend schwieriger zu ändern sind.
02. WIE TECHNISCHE SCHULDEN ENTSTEHEN
Technische Schulden entstehen normalerweise nicht durch Faulheit oder Unfähigkeit. Sie entstehen aus rationalen Entscheidungen, die unter realen Einschränkungen getroffen wurden. Die Deadline war real. Das Budget war fest. Das MVP musste veröffentlicht werden. Die Übergangslösung war die richtige Entscheidung — damals. Das Problem ist, was danach passiert: Die Deadline ist vorbei, der Druck verlagert sich auf das nächste Feature, und niemand geht zurück, um die Abkürzung zu beheben.
03. DIE VIER ARTEN VON TECHNISCHEN SCHULDEN
Nicht alle technischen Schulden sind gleich. Martin Fowlers Quadrant der technischen Schulden identifiziert vier Arten anhand von zwei Achsen: bewusst vs. unbewusst und leichtfertig vs. umsichtig.
"Wir wissen, dass das falsch ist — wir machen es nach dem Launch richtig"
Die am besten handhabbare Form. Ein bewusster Kompromiss, der mit vollem Bewusstsein für die Kosten und einem Plan zu seiner Rückzahlung eingegangen wird. Akzeptabel, wenn die Rückzahlung tatsächlich erfolgt. Gefährlich, wenn "nach dem Launch" zu "nie" wird.
"Wir haben keine Zeit, es richtig zu entwerfen"
Abkürzungen, die ohne Anerkennung oder Planung der Konsequenzen vorgenommen werden. Oft als Pragmatismus getarnt. Sie summieren sich am schnellsten, weil es keine Absicht gibt, sie zurückzuzahlen — die Schulden werden nicht einmal als solche erkannt.
"Jetzt wissen wir, wie wir es hätten machen sollen"
Schulden, die durch echten Wissensmangel zum Zeitpunkt der Entscheidung entstanden sind. Das Team hat mit dem besten getan, was es wusste — der bessere Ansatz wurde erst durch Erfahrung klar. Häufig in sich schnell entwickelnden technischen Bereichen.
"Was meinst du mit Schichtarchitektur?"
Schulden, die entstehen, weil man nicht weiß, wie gute Praxis aussieht. Das Team hat nicht erkannt, dass es Schulden aufbaut. Die teuersten, die zu entdecken sind, weil sie oft tief verankert sind, bevor jemand sie identifiziert.
04. DIE SYMPTOME — WIE TECHNISCHE SCHULDEN IN DER PRAXIS AUSSEHEN
Technische Schulden kündigen sich selten an. Sie zeigen sich indirekt, in Symptomen, die Teams oft anderen Ursachen zuschreiben:
| Symptom | Was es eigentlich signalisiert |
|---|---|
| "Einfache" Änderungen dauern Wochen | Hohe Kopplung — alles hängt von allem anderen ab |
| Neue Entwickler brauchen Monate, um produktiv zu sein | Keine Dokumentation, inkonsistente Muster, System zu komplex, um es schnell zu lernen |
| Fehlerbehebungen führen neue Fehler ein | Fragile Architektur, fehlende Tests, Übergangslösungen, die auf Übergangslösungen aufbauen |
| Niemand will Modul X anfassen | Bereich mit hohen Schulden — jeder kennt ihn, aber niemand hat Zeit, ihn zu beheben |
| Die Geschwindigkeit sinkt jedes Quartal | Die Zinszahlungen steigen — mehr Zeit wird mit dem Kampf gegen das System als mit dem Bau von Features verbracht |
| "Wir brauchen eine vollständige Überarbeitung" | Die Hauptsumme der Schulden hat den Wert der schrittweisen Rückzahlung übertroffen — der Zinseszins hat gewonnen |
05. TECHNISCHE SCHULDEN MANAGEN — DER PRAKTISCHE ANSATZ
Das Ziel ist nicht null technische Schulden. Einige Schulden sind rational — die bewusste, umsichtige Art, die die Auslieferung beschleunigt, wenn sie planmäßig zurückgezahlt wird. Das Ziel ist managbare Schulden: sichtbar, nachverfolgt und zurückgezahlt, bevor die Zinsen den ursprünglichen Gewinn übersteigen.
Sichtbar machen
Technische Schulden, die nicht nachverfolgt werden, werden nicht zurückgezahlt. Erstellen Sie ein Schuldenregister — eine einfache Liste bekannter Abkürzungen, ihrer geschätzten Rückzahlungskosten und ihres aktuellen Zinssatzes (wie sehr sie Sie ausbremsen). Was gemessen wird, kann gemanagt werden.
Rückzahlungsfähigkeit einplanen
Eine gängige Faustregel ist, etwa 20 % der Entwicklungsfähigkeit für die Rückzahlung von Schulden zu reservieren — Refactoring, Dokumentation, Architekturverbesserungen. Teams, die dies auslassen, stellen fest, dass der Prozentsatz unwillkürlich ansteigt, da die Schuldenbedienungskosten immer mehr der Sprintkapazität entziehen.
Aufhören, Schulden anzuhäufen, bevor sie zurückgezahlt werden
Schulden abzuzahlen und gleichzeitig in derselben Rate neue anzuhäufen, ist wie auf der Stelle zu laufen. Bevor eine aggressive Rückzahlung sinnvoll ist, müssen sich die Bedingungen ändern, die die Schulden verursacht haben — unrealistische Zeitpläne, fehlende Design-Reviews, keine Definition von Fertigstellung.
Nach Zinssatz priorisieren, nicht nach Hauptsumme
Bezahlen Sie zuerst die Schulden, die Sie pro Sprint am meisten kosten, nicht die mit der größten Hauptsumme. Eine kleine architektonische Abkürzung in einem Bereich mit vielen Änderungen kostet mehr an täglichen Zinsen als ein großes Legacy-Modul, das niemand anfassen muss.
06. DAS WICHTIGSTE
Technische Schulden sind kein Versagen des Engineerings. Sie sind eine Eigenschaft des Engineerings unter realen Einschränkungen. Das Versagen besteht darin, so zu tun, als gäbe es sie nicht — darin, "Wir machen das später richtig" als vollständigen Satz zu behandeln, anstatt als den Anfang eines Plans.
Die besten Engineering-Teams haben keine Schulden von null. Sie haben Schulden, die sie sehen können, einen Zinssatz, den sie sich leisten können, und einen Rückzahlungsplan, den sie tatsächlich einhalten. Sie wissen, dass Zeitplan und Budget nicht isoliert existieren — sie überschneiden sich bei den technischen Schulden, und was auch immer an dieser Schnittmenge lebt, wird letztendlich darüber entscheiden, ob das System ein Vorteil oder eine Belastung ist.
Die Entwickler, die das verstehen, liefern nicht nur schneller aus. Sie liefern Systeme aus, die weiterhin auslieferbar bleiben.
// grabnade.com · Bekleidung
Zeitplan. Budget. Technische Schulden.
Naturgesetze.
Das Venn-Diagramm, das Ihre Stakeholdervor der nächsten Sprintplanung sehen müssen.
Tragen Sie es zum Meeting.