Technische Schulden erklärt für Geschäftsführer
Technische Schulden sind Abkürzungen in einer Software, die beim Bau Zeit sparen und danach bei jeder Änderung Zeit kosten. Geschäftsführer erkennen sie ohne einen Blick in den Code: Ähnliche Änderungen dauern von Mal zu Mal länger, behobene Fehler kehren zurück, und das Team meidet bestimmte Teile der Anwendung.
Für eine Geschäftsführung zeigen sich technische Schulden selten als Fehlermeldung. Sie zeigen sich im Angebot für eine kleine Änderung, das plötzlich drei statt einen Personentag nennt, oder in der Antwort „das fassen wir lieber nicht an“. Hinter beidem steht dieselbe Ursache: Teile der Software wurden so gebaut, dass sie damals funktionierten, sich aber schwer ändern lassen.
Dieser Beitrag erklärt den Begriff, die Warnzeichen und eine Rechnung, mit der Sie entscheiden, ob sich Abbau gegen Weitermachen rechnet. Eine vollständige Bestandsaufnahme mit Inventur und Risiko-Matrix ist Arbeit für Fachleute. Hier bleibt es bei dem, was Sie ohne Code-Kenntnis beurteilen und entscheiden können.
Herkunft des Begriffs
Die Metapher und ihre Grenzen
Der Begriff stammt von Ward Cunningham. In seinem Erfahrungsbericht zur Konferenz OOPSLA 1992 über das Finanzsystem WyCash schrieb er sinngemäß: Code zum ersten Mal auszuliefern ist, als ginge man Schulden ein. Ein wenig Schuld beschleunige die Entwicklung, solange sie zügig durch Überarbeitung zurückgezahlt werde. Gefährlich werde es, wenn das ausbleibe, denn jede Minute, die man mit nicht ganz passendem Code verbringe, zähle als Zins auf diese Schuld.
Die Metapher trägt, weil sie zwei Dinge trennt, die im Alltag verschwimmen: den Betrag, also den Aufwand, um eine Stelle sauber umzubauen, und die Zinsen, also den Mehraufwand, den jede Änderung an dieser Stelle verursacht, solange sie nicht umgebaut ist.
An drei Punkten hinkt der Vergleich mit einem Kredit:
Es gibt keinen Kontoauszug. Niemand schickt Ihnen eine Aufstellung, die Höhe muss geschätzt werden.
Zinsen fallen nur an, wo jemand den Code ändert. Ein unschöner Teil, den seit Jahren niemand anfasst, kostet nichts, solange er fehlerfrei läuft.
Nicht jede Schuld muss zurückgezahlt werden. Manche Stellen bleiben besser unangetastet, weil der Umbau teurer wäre als der Nutzen.
Woran Sie es merken
Symptome im Alltag: Dauer, Fehler, Angst vor Änderungen
Technische Schulden lassen sich an Zahlen erkennen, die Sie ohnehin haben: Angebote, Tickets, Release-Termine. Achten Sie auf diese Zeichen:
Dauer: Vergleichbare Änderungen werden über die Monate teurer. Ein zusätzliches Feld im Bestellformular kostete vor einem Jahr einen halben Personentag, das neue Angebot nennt zwei.
Fehler: Behobene Fehler kehren zurück, oder eine Änderung an einer Stelle löst einen Fehler an einer ganz anderen aus.
Angst vor Änderungen: Das Team rät von Änderungen an bestimmten Modulen ab, plant für sie Sicherheitspuffer ein oder liefert nur noch selten aus.
Aufgeschobene Updates: Framework- und PHP-Versionen bleiben stehen, weil ein Update „zu viel kaputt machen könnte“. Warum kleine, regelmäßige Updates günstiger sind als seltene große, begründet der Beitrag über Patch-Disziplin.
Wissen bei einer Person: Fragen zu einem Teil der Anwendung beantwortet immer dieselbe Person. Was das bei Krankheit oder Kündigung bedeutet, steht unter dem Stichwort Bus-Faktor.
Ein einzelnes Zeichen beweist noch nichts. Treffen drei oder mehr auf dasselbe Modul zu, verdient genau dieses Modul einen genauen Blick.
Zwei Arten
Bewusste und unbewusste Schulden
Martin Fowler hat die Metapher 2009 um ein Raster erweitert. Er unterscheidet, ob ein Team eine Schuld bewusst oder unbewusst eingeht und ob es dabei umsichtig oder leichtsinnig handelt.
Bewusst und umsichtig: Das Team weiß, dass eine Lösung nicht ideal ist, und nimmt das für einen Termin in Kauf, etwa den Start vor einer Messe. Solche Schulden sind eine unternehmerische Entscheidung und gehören notiert, mit dem Datum, an dem sie wieder auf den Tisch kommen.
Bewusst und leichtsinnig: „Für sauberen Code haben wir keine Zeit.“ Hier wird der Zins dauerhaft in Kauf genommen, ohne dass jemand ihn beziffert hat.
Unbewusst und leichtsinnig: Das Team kennt bessere Bauweisen nicht und bemerkt die Schuld erst, wenn die Zinsen spürbar werden.
Unbewusst und umsichtig: Auch gute Teams verstehen ein Problem oft erst beim Bauen. Hinterher sehen sie, wie es besser gegangen wäre. Diese Schuld lässt sich laut Fowler nicht vermeiden.
Gegen leichtsinnige Schulden hilft eine Planung, die Wartbarkeit von Beginn an mitdenkt. Bei der Website von GADGETTO Manufacturing haben wir die Designsprache der Marke deshalb in eine Tailwind-Architektur überführt, die sich Schritt für Schritt erweitern lässt, ohne dass das Gerüst bei jeder Erweiterung umgebaut werden muss.
Rechnung mit Annahmen
Was Abbau kostet und was Nichtstun kostet
Ob sich ein Umbau rechnet, entscheiden zwei Zahlen: der Zins pro Jahr und der Betrag des Umbaus. Die folgende Beispielrechnung arbeitet mit Annahmen. Alle Annahmen sind als solche gekennzeichnet und werden für Ihr Projekt durch eigene Werte ersetzt.
Annahme 1: Ein Modul, etwa die Preisberechnung, wird zwölfmal im Jahr geändert.
Annahme 2: Jede Änderung kostet in diesem Modul drei Personentage. Nach einem Umbau wären es zwei. Der Zins beträgt also einen Personentag pro Änderung.
Annahme 3: Der Umbau selbst, einschließlich der Tests, die das bisherige Verhalten vorher festhalten, kostet 15 Personentage.
Damit ergibt sich in Personentagen:
Zins pro Jahr: 12 Änderungen × 1 Personentag = 12 Personentage.
Betrag des Umbaus: 15 Personentage.
Nach 15 ÷ 12 = 1,25 Jahren, also nach 15 Monaten, hat der Umbau seinen Aufwand eingespielt.
Über drei Jahre gerechnet:
Nichtstun: 3 Jahre × 12 Personentage = 36 Personentage Zinsen.
Umbau: 15 Personentage, danach entfallen die Zinsen nach Annahme 2. Ersparnis: 36 − 15 = 21 Personentage.
Dieselbe Rechnung fällt anders aus, wenn das Modul nur zweimal im Jahr geändert wird. Der Zins sinkt auf 2 Personentage pro Jahr, und der Umbau bräuchte 15 ÷ 2 = 7,5 Jahre, bis er seinen Aufwand eingespielt hat. Ein solches Modul bleibt besser, wie es ist.
Für einen Betrag in Euro multiplizieren Sie die Personentage mit den Kosten eines Tages Ihres eigenen Teams oder mit dem Satz Ihres Dienstleisters. Mit unserem Standard-Tagessatz von 1.500 Euro netto gerechnet wären die 21 eingesparten Personentage 21 × 1.500 = 31.500 Euro netto. An der Richtung der Entscheidung ändert der Satz nichts, denn er steckt in Zins und Umbau gleichermaßen.
Nicht in der Rechnung stehen Ausfälle, Sicherheitslücken in veralteten Abhängigkeiten und Mitarbeiter, die wegen des Codes kündigen. Sie sprechen zusätzlich für den Umbau, lassen sich aber selten vorab beziffern. Die Tests, die einen solchen Umbau absichern, lassen sich auch in Legacy-Code nachrüsten.
Für das nächste Gespräch
Fragen an Ihr Entwicklerteam
Die folgenden Fragen liefern die Werte für die Rechnung oben und zeigen, wie gut das Team seine eigenen Schulden kennt. Gute Antworten nennen Module, Zahlen und Gründe.
Welche drei Module würden Sie umbauen, wenn Sie einen Monat frei hätten, und warum genau diese?
Wie oft wurde jedes dieser Module in den letzten zwölf Monaten geändert?
Wie viel länger dauert eine Änderung dort als in einem sauberen Teil der Anwendung?
Welche Fehler sind nach einer Behebung wiedergekommen, und in welchem Modul?
Welche Abhängigkeiten oder Versionen sind veraltet, und was hält das Update auf?
Welche Abkürzungen haben wir bewusst genommen, und wo sind sie notiert?
Wer außer Ihnen kann eine Änderung an diesen Modulen ausliefern?
Welche Teile sollten wir bewusst nicht anfassen, weil der Umbau sich nicht rechnet?
Kann das Team bei Frage 6 eine Liste vorlegen, sind die bewussten Schulden dokumentiert. Bleiben die Antworten vage, oder wollen Sie die Einschätzung des eigenen Teams gegenprüfen lassen, hilft eine Analyse von außen, die Code, Abhängigkeiten und Abläufe mit einem schriftlichen Befund bewertet.
Kurz beantwortet
Häufige Fragen
-
Nein. Eine bewusst eingegangene Abkürzung kann einen wichtigen Termin retten, wenn sie notiert und später geplant behoben wird. Schädlich werden Schulden, wenn niemand sie kennt und die Zinsen still in jedem Angebot stecken.
-
Eine einzelne Kennzahl gibt es nicht. Brauchbar sind die Dauer vergleichbarer Änderungen über die Zeit, wiederkehrende Fehler je Modul und die Häufigkeit, mit der ein Modul geändert wird. Werkzeuge zur statischen Codeanalyse liefern Hinweise, ersetzen aber nicht die Einschätzung, wo Änderungen anstehen.
-
Das Entwicklerteam ist dafür verantwortlich, Schulden sichtbar zu machen und den Aufwand zu schätzen. Die Entscheidung, ob ein Umbau Budget bekommt, trifft die Geschäftsführung, weil sie Termine, Kosten und Risiko gegeneinander abwägt. Bei einem externen Dienstleister gehört eine solche Liste zur regelmäßigen Abstimmung.
Von der Liste zum Umbauplan
Mit den Antworten auf die acht Fragen haben Sie die Rohdaten. Unser Tech-Debt-Audit-Spielbuch (PDF, 2.490 Euro netto zzgl. Umsatzsteuer) beschreibt, wie daraus in zwei Wochen eine Risiko-Matrix und eine Roadmap mit drei priorisierten Schritten entsteht.
Nachweise
Quellen und Stand
Stand: 25.06.2026. Die Beispielrechnung beruht auf angenommenen Werten.
Artikel teilen