Glossar
Technische Schulden
Auch: Technical Debt · Tech Debt
Der aufgeschobene Aufwand aus früheren Abkürzungen im Code oder in der Architektur. Er verschwindet nicht, er wird nur später und teurer fällig.
Das Bild von der Schuld ist deshalb gut, weil es die Zinsen mitdenkt. Die Abkürzung selbst ist meist billig, was kostet, ist jede spätere Änderung an dieser Stelle. Ein Team, das Zinsen zahlt, merkt es nicht an einer Rechnung, sondern daran, dass eine Aufgabe, die vor zwei Jahren zwei Tage dauerte, heute zwei Wochen braucht.
Nicht jede Schuld ist ein Fehler. Bewusst aufgenommene Schuld, um einen Markt früher zu erreichen, ist eine legitime Entscheidung, solange jemand sie kennt und ein Rückzahlungszeitpunkt existiert. Problematisch ist die unbewusste Schuld: entstanden aus Zeitdruck, Personalwechsel und fehlendem Wissen, ohne dass sie irgendwo steht.
Der Grund, warum das Thema selten Gehör findet, ist die fehlende Übersetzung. „Der Code ist unsauber" ist kein Argument für jemanden, der über Budgets entscheidet. „Jedes neue Feature in diesem Bereich dauert dreimal so lange wie vergleichbare an anderer Stelle" ist eins.
Messbar wird es über Stellvertreter: Durchlaufzeit von der Idee bis zur Produktion, Anteil der Zeit für Fehlerbehebung, Häufigkeit von Störungen nach einem Deployment, Anzahl der Bereiche, die nur eine Person anfassen kann. Keine dieser Zahlen misst Schuld direkt, zusammen zeichnen sie ein belastbares Bild.
Der teuerste Umgang ist der Komplettneubau als Antwort. Er verspricht, alle Schulden auf einmal zu tilgen, und übersieht, dass das alte System in der Bauzeit weiterlebt, sich verändert und neue Schulden bildet. Schrittweise Ablösung ist langsamer auf dem Papier und schneller in der Realität.
Was in der Praxis funktioniert, ist ein fester Anteil der Kapazität, der ohne Einzelfallbegründung in Instandhaltung geht. Wer Aufräumarbeit jedes Mal neu rechtfertigen muss, räumt nicht auf, weil sie gegen jedes Feature verliert.
Woran Sie es erkennen
- Schätzungen für vergleichbare Aufgaben gehen in einem Bereich deutlich auseinander.
- Nach Deployments häufen sich Störungen immer in derselben Ecke.
- Bestimmte Bereiche kann nur eine Person anfassen.
- Aufräumarbeit muss jedes Mal einzeln begründet werden.
Nicht zu verwechseln mit
- Legacy-Code
- Code ohne Tests, der Geld verdient. Technische Schulden sind der Aufwand, der darin steckt. Ein System kann Legacy sein und wenig Schulden tragen, wenn es stabil und verstanden ist.
- Schlechter Code
- Ein Qualitätsurteil. Technische Schulden sind eine ökonomische Größe: Sie kosten erst dann, wenn an der Stelle gearbeitet wird. Schlechter Code in einem Bereich, den nie jemand anfasst, ist billig.
- Refactoring
- Die Tilgung. Verändert die Struktur ohne das Verhalten. Ohne Tests davor ist es kein Refactoring, sondern eine Umschreibung mit offenem Ausgang.
Wann es trägt
- Der Bereich wird regelmäßig geändert: dort zahlen sich Zinsen wirklich aus.
- Vor einem größeren Vorhaben in derselben Ecke des Systems.
- Wenn Störungen nach Deployments sich in einem Bereich häufen.
Wann nicht
- In stabilen Bereichen, die niemand anfasst. Dort ist die Schuld zinsfrei.
- In Komponenten, die ohnehin in absehbarer Zeit abgelöst werden.
- Als Selbstzweck ohne Bezug zu einem anstehenden Vorhaben: das ist Aufräumen, kein Investment.
Wie man rangeht
- In Geschäftssprache übersetzenNicht „unsauber", sondern Durchlaufzeit, Fehlerquote, Ausfallhäufigkeit, Personenabhängigkeit. Diese Zahlen bewegen Entscheidungen, Qualitätsurteile nicht.
- Nach Änderungshäufigkeit priorisierenDie Bereiche, die am häufigsten angefasst werden, zuerst. Ein Blick in die Versionsgeschichte zeigt sie schneller als jede Analyse.
- Erst absichern, dann verändernCharacterization Tests halten fest, was das System heute tut. Ohne dieses Netz ist jede Aufräumarbeit ein Risiko ohne Rückweg.
- Festen Kapazitätsanteil verabredenZehn bis zwanzig Prozent, ohne Einzelfallbegründung. Was jedes Mal neu gerechtfertigt werden muss, findet nicht statt.
- Bewusste Schulden aufschreibenWo eine Abkürzung genommen wird, gehören Grund, Kosten und Rückzahlungszeitpunkt in eine sichtbare Liste. Unbewusste Schuld ist die teure.
- Wirkung nachmessenDieselben Kennzahlen nach drei Monaten erneut erheben. Ohne diesen Nachweis wird der Kapazitätsanteil beim nächsten Termindruck gestrichen.
Häufig gefragt
Wie erklärt man technische Schulden der Geschäftsführung?
Über Zeit und Risiko, nicht über Codequalität. „Änderungen in diesem Bereich dauern dreimal so lange wie vergleichbare an anderer Stelle, und zwei von drei Störungen der letzten Monate kamen von dort." Das ist eine Aussage, mit der sich eine Priorisierung begründen lässt.
Wie viel Kapazität sollte in die Tilgung gehen?
Zehn bis zwanzig Prozent als Dauerzustand, ohne Einzelfallbegründung. Entscheidend ist die Verstetigung: Sonderaktionen nach einem Vorfall verpuffen, weil danach wieder ausschließlich Features gebaut werden, bis der nächste Vorfall kommt.
Ist ein Neubau nicht manchmal günstiger?
Selten, und fast nie aus dem Grund, aus dem er vorgeschlagen wird. Das alte System lebt während der Bauzeit weiter, verändert sich und bildet neue Schulden, und der Neubau muss Verhalten nachbilden, das niemand vollständig kennt. Schrittweise Ablösung ist auf dem Papier langsamer und liefert ab dem ersten Monat Teile in Produktion.
Sind alle technischen Schulden schlecht?
Nein. Bewusst aufgenommene Schuld, um früher am Markt zu sein, kann die richtige Entscheidung sein. Sie unterscheidet sich von der schlechten Variante durch drei Dinge: Sie ist jemandem bekannt, sie ist aufgeschrieben, und es gibt einen Zeitpunkt, zu dem sie zurückgezahlt wird.