Technische Abteilung: Die versteckten Kosten
Teilen
Technische Schuld:
Die versteckten Kosten von "Wir werden es später beheben"
Irgendwo in jedem Code, jeder Systemarchitektur und jedem Produktionsprozess gibt es eine Entscheidung, die unter Druck getroffen wurde und nie wieder überprüft wurde. Ein Workaround, der dauerhaft wurde. Eine vorübergehende Lösung, die länger überdauert hat als der Projektmanager, der sie genehmigt hat. Ein Kommentar, der lautet // TODO: das richtig beheben — datiert vor drei Jahren.
Das ist technische Schuld. Und im Gegensatz zu finanzieller Schuld erscheint sie nicht in einer Bilanz, bis die Zinszahlung fällig wird.
## 01. WAS TECHNISCHE SCHULD WIRKLICH IST
Der Begriff wurde 1992 von dem Software-Ingenieur Ward Cunningham geprägt, aber das Konzept gilt weit über Code hinaus. Technische Schuld ist die kumulierte Kosten für die Wahl einer schnelleren oder einfacheren Lösung jetzt anstelle der besseren Lösung, die länger dauern würde.
Wie finanzielle Schulden hat sie einen Haupt- und einen Zinsanteil. Der Hauptbetrag ist die Nacharbeit, die erforderlich ist, um die richtige Lösung umzusetzen. Die Zinsen sind die laufenden Kosten, um den Workaround zu umgehen — langsamere Entwicklung, schwierigere Wartung, fragilere Systeme, höhere Fehlerquoten.
Der entscheidende Unterschied zur finanziellen Schuld: technische Schuld kumuliert stillschweigend. Sie erhalten keine monatliche Abrechnung. Die Zinsen sammeln sich unsichtbar in Form von verlangsamter Geschwindigkeit, erhöhten Fehlerzahlen, längeren Einarbeitungszeiten für neue Ingenieure und Systemen, die zunehmend schwieriger zu ändern sind.
## 02. WIE TECHNISCHE SCHULD ANSTEIGT
Technische Schuld resultiert normalerweise nicht aus Faulheit oder Inkompetenz. Sie resultiert aus rationalen Entscheidungen, die unter realen Einschränkungen getroffen wurden. Die Frist war real. Das Budget war festgelegt. Das MVP musste ausgeliefert werden. Der Workaround war die richtige Entscheidung — zu diesem Zeitpunkt. Das Problem ist, was danach passiert: Die Frist verstreicht, 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 TECHNISCHER SCHULD
Nicht alle technischen Schulden sind gleich geschaffen. Martin Fowlers Technische Schulden-Quadrant identifiziert vier Typen basierend auf zwei Achsen: absichtlich vs. unabsichtlich und leichtsinnig vs. umsichtig.
"Wir wissen, dass das falsch ist — wir werden es nach dem Start beheben"
Die am besten handhabbare Form. Ein bewusster Kompromiss, der mit vollem Bewusstsein der Kosten und einem Plan zur Rückzahlung getroffen wurde. Akzeptabel, wenn die Rückzahlung tatsächlich erfolgt. Gefährlich, wenn "nach dem Start" zu "nie" wird.
"Wir haben keine Zeit, es richtig zu entwerfen"
Abkürzungen, die genommen wurden, ohne die Konsequenzen anzuerkennen oder zu planen. Oft als Pragmatismus getarnt. Ansammelt sich am schnellsten, weil es keine Absicht zur Rückzahlung gibt — die Schulden werden nicht einmal als Schulden erkannt.
"Jetzt wissen wir, wie wir es hätten machen sollen"
Schulden, die durch echten Mangel an Wissen zum Zeitpunkt der Entscheidung entstanden sind. Das Team hat sein Bestes mit dem gegebenen Wissen getan — der bessere Ansatz wurde erst durch Erfahrung klar. Häufig in sich schnell entwickelnden technischen Bereichen.
"Was meinst du mit geschichteter Architektur?"
Schulden, die aus dem Unwissen darüber entstehen, wie gute Praktiken aussehen. Das Team hat nicht erkannt, dass sie Schulden schaffen. Am teuersten zu entdecken, weil es oft tief verwurzelt ist, bevor es jemand 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 tatsächlich signalisiert |
|---|---|
| "Einfache" Änderungen dauern Wochen | Hohe Kopplung — alles hängt von allem anderen ab |
| Neue Ingenieure brauchen Monate, um produktiv zu sein | Keine Dokumentation, inkonsistente Muster, System zu komplex, um schnell gelernt zu werden |
| Fehlerbehebungen führen zu neuen Fehlern | Fragile Architektur, fehlende Tests, Workarounds, die auf Workarounds basieren |
| Niemand möchte Modul X anfassen | Hochverschuldeter Bereich — jeder weiß es, aber niemand hat Zeit, es zu beheben |
| Die Geschwindigkeit sinkt jedes Quartal | Zinszahlungen steigen — mehr Zeit mit dem Kämpfen gegen das System als mit dem Erstellen von Funktionen |
| "Wir brauchen eine vollständige Neuschreibung" | Die Schuldenhöhe hat den Wert der inkrementellen Rückzahlung überschritten — Zinseszinsen haben gewonnen |
## 05. MANAGEMENT TECHNISCHER SCHULDEN — DER PRAKTISCHE ANSATZ
Das Ziel ist nicht null technische Schulden. Einige Schulden sind rational — die absichtliche, umsichtige Art, die die Lieferung beschleunigt, wenn sie planmäßig zurückgezahlt wird. Das Ziel ist verwaltete Schulden: sichtbar, nachverfolgt und zurückgezahlt, bevor die Zinsen den ursprünglichen Gewinn übersteigen.
Machen Sie es sichtbar
Technische Schulden, die nicht verfolgt 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 verlangsamen). Was gemessen wird, wird verwaltet.
Weisen Sie Rückzahlungskapazität zu
Die Standardempfehlung ist, 20% der Ingenieurkapazität für die Rückzahlung von Schulden zu reservieren — Refactoring, Dokumentation, Architekturverbesserungen. Teams, die dies überspringen, stellen fest, dass der Prozentsatz unwillkürlich ansteigt, während die Kosten für den Schuldendienst immer mehr Sprintkapazität verbrauchen.
Hören Sie auf, Schulden anzuhäufen, bevor Sie zurückzahlen
Die Rückzahlung von Schulden, während man weiterhin in demselben Tempo Schulden anhäuft, ist Stillstand. Bevor eine aggressive Rückzahlung sinnvoll ist, müssen sich die Bedingungen, die die Schulden verursacht haben — unrealistische Zeitpläne, fehlende Designüberprüfungen, keine Definition von "fertig" — ändern.
Priorisieren Sie nach Zinssatz, nicht nach Hauptsumme
Zahlen Sie zuerst die Schulden zurück, die Sie pro Sprint am meisten kosten, nicht die größte Hauptsumme. Eine kleine architektonische Abkürzung in einem Bereich mit hohen Änderungen kostet mehr an täglichen Zinsen als ein großes Legacy-Modul, das niemand anfasst.
## 06. DAS FAZIT
Technische Schulden sind kein Versagen der Ingenieurwissenschaft. Es ist ein Merkmal der Ingenieurwissenschaft unter realen Bedingungen. Das Versagen liegt darin, so zu tun, als ob sie nicht existieren — darin, "wir werden es später beheben" als vollständigen Satz zu behandeln, anstatt als den Anfang eines Plans.
Die besten Ingenieurteams haben keine null Schulden. Sie haben Schulden, die sie sehen können, eine Rate, die sie sich leisten können, und einen Rückzahlungsplan, den sie tatsächlich einhalten. Sie wissen, dass Zeitplan und Budget nicht isoliert existieren — sie schneiden sich bei den technischen Schulden, und was auch immer an dieser Schnittstelle lebt, wird letztendlich bestimmen, ob das System ein Vermögenswert oder eine Verbindlichkeit ist.
Die Ingenieure, die das verstehen, liefern nicht nur schneller. Sie liefern Systeme, die lieferbar bleiben.
// grabnade.com · Bekleidung
Zeitplan. Budget. Technische Schulden.
Gesetze der Physik.
Das Venn-Diagramm Ihrer Stakeholdermüssen Sie vor der nächsten Sprintplanung sehen.
Tragen Sie es zur Besprechung.
