Definition
Technische Schulden sind Kompromisse in Entwurf und Programmcode, die kurzfristig helfen, spätere Änderungen an der Software aber teurer oder unmöglich machen. Die Zinsen zahlt ein Unternehmen als Mehraufwand bei jeder weiteren Änderung. Der Begriff, englisch Technical Debt, stammt von Ward Cunningham und betrifft vor allem Wartbarkeit und Weiterentwicklung.
Das Wichtigste in Kürze
- Technische Schulden sind Kompromisse in Entwurf und Code, die spätere Änderungen teurer machen. Zinsen fallen an, sobald jemand die Stelle ändert.
- In einer Messung an 39 Softwaresystemen dauerte Arbeit an Code schlechter Qualität im Mittel 124 % länger. Eine Pauschalzahl gibt es nicht.
- Der Abbau lohnt sich, wenn die eingesparten Zinsen den Aufwand innerhalb der Restlaufzeit zurückzahlen. Stellen ohne Änderungen können bleiben.
- Im Rechenbeispiel zahlt sich ein Abbau von 60 Stunden bei 12 Änderungen im Jahr nach rund 16 Monaten aus, bei 2 Änderungen in vier Jahren nicht.
- Werkzeuge schätzen vor allem den Abbauaufwand. Bei Google sagte keine einzelne von 117 Kennzahlen voraus, wo Entwickler technische Schulden melden.
Was sind technische Schulden?
Technische Schulden sind Kompromisse in Entwurf und Programmcode, die kurzfristig helfen und spätere Änderungen teurer machen. Wie bei einem Kredit zahlen Sie dafür Zinsen: Jede Änderung an der betroffenen Stelle dauert länger. Räumt jemand die Stelle auf, ist das die Tilgung.
Das Bild stammt von Ward Cunningham. In einem Erfahrungsbericht von 1992 schrieb er, etwas Schuld beschleunige die Entwicklung, solange sie bald zurückgezahlt werde. Jede Minute an nicht ganz passendem Code zähle als Zins (Cunningham, 1992). Englisch heißt der Begriff Technical Debt, oft kurz Tech Debt.
Auf einem Forschungsseminar in Schloss Dagstuhl einigten sich die Teilnehmenden 2016 auf eine Arbeitsdefinition: Technische Schulden sind Bestandteile von Entwurf oder Umsetzung, die kurzfristig zweckmäßig sind und spätere Änderungen teurer oder unmöglich machen können. Ihre Wirkung beschränkt sich danach auf die innere Qualität einer Software, vor allem auf Wartbarkeit und Weiterentwicklung (Dagstuhl-Seminar 16162, 2016).
Wie die Rechnung aussieht, zeigt ein Beispiel von Martin Fowler. Eine neue Funktion dauert in einem klar gegliederten Modul vier Tage, in einem unübersichtlichen sechs. Die zwei Tage Unterschied sind die Zinsen. Fünf Tage Aufräumen wären die Tilgung (Fowler, Technical Debt, 2019). Anders als bei einem Bankkredit fallen die Zinsen nur an, wenn jemand die Stelle ändert. An einer SaaS wird meist laufend gearbeitet, deshalb fallen sie dort oft an. Wie eine SaaS funktioniert, erklärt unser Leitfaden Was ist SaaS?
Sind technische Schulden immer schlecht?
Nein. Eine bewusst aufgenommene Schuld kann richtig sein, etwa um einen Termin zu halten, wenn das Team die Rückzahlung einplant. Riskant wird sie, wenn niemand sie festhält oder sie unbemerkt entsteht. Schuldenfreie Software ist kein sinnvolles Ziel.
Martin Fowler teilt technische Schulden nach zwei Fragen ein: Wurde die Schuld bewusst aufgenommen, und war das umsichtig oder leichtsinnig (Fowler, Quadrant, 2009)?
- Bewusst und umsichtig: Das Team kennt den Kompromiss und wägt ab, ob ein früherer Start die späteren Kosten wert ist.
- Bewusst und leichtsinnig: Das Team kennt gute Praxis, verzichtet aber aus Zeitmangel darauf. Fowler hält das meist für eine Fehleinschätzung, weil sauberer Entwurf die Arbeit beschleunigt.
- Unbewusst und leichtsinnig: Dem Team fehlt das Wissen über guten Entwurf. Es merkt nicht, wie viel Schuld es aufnimmt.
- Unbewusst und umsichtig: Ein gutes Team erkennt erst während der Arbeit, wie der Entwurf hätte aussehen sollen. Das lässt sich laut Fowler kaum vermeiden.
Laut Googles Forschungsteam für Entwicklerproduktivität kann es eine richtige Entscheidung sein, eine Schuld umsichtig und bewusst aufzunehmen. Cunningham wollte den Begriff laut demselben Beitrag aber nicht als Entschuldigung für schlechten Code verstanden wissen (Google, IEEE Software, 2023). Frank Buschmann von Siemens fasste es auf dem Dagstuhl-Seminar so zusammen: Ziel sei ein wettbewerbsfähiges System, schuldenfrei müsse es dafür nicht sein.
In einer Umfragereihe mit 653 gültigen Antworten aus sechs Ländern nannten Fachleute Termindruck am häufigsten als Ursache technischer Schulden. Die häufigsten Folgen waren Lieferverzug, schlechte Wartbarkeit und Nacharbeit (Ramač u. a., 2022).
Woran erkennen Sie technische Schulden, ohne den Code zu lesen?
An den Folgen im Alltag: Kleine Änderungen dauern immer länger, Terminzusagen stimmen seltener, und an manche Teile der Software traut sich nur noch eine Person heran. Für kleine Unternehmen wird das wichtig, sobald an einer Software laufend gearbeitet wird.
Google ließ seine Entwickler die Ursachen ihrer Schulden benennen und kam auf zehn Kategorien. Die Rangfolge hängt vom Unternehmen ab, die Liste selbst halten die Autoren für übertragbar (Google, IEEE Software, 2023). Die Tabelle übersetzt alle zehn in das, was Sie als Auftraggeber bemerken. Die linke Spalte ist unsere Einordnung.
| Das fällt Ihnen auf | Kategorien bei Google |
|---|---|
| Kleine Änderungen werden immer teurer, Schätzungen immer ungenauer | Codequalität; Verfall des Codes |
| Nach Änderungen geht anderes kaputt, Veröffentlichungen werden verschoben | Tests; Release-Prozess |
| Nur eine Person kennt bestimmte Teile, neue Leute brauchen lange | Team ohne nötiges Fachwissen; Dokumentation |
| Ein Versionswechsel wird immer wieder verschoben, Bausteine machen bei Updates Ärger | Migration nötig oder im Gang; Abhängigkeiten |
| Alte und neue Lösung laufen dauerhaft nebeneinander | Migration schlecht ausgeführt oder abgebrochen |
| Funktionen stehen weiter im System, obwohl sie ersetzt wurden | Toter oder verlassener Code |
Kleine Unternehmen sollten besonders auf die dritte Zeile achten, weil in kleinen Teams das Wissen oft an wenigen Menschen hängt. Wie Sie das prüfen, zeigt unser Ratgeber Abhängig vom Entwickler? Läuft ein kleines internes Werkzeug dagegen stabil und ändert sich selten, zahlen Sie kaum Zinsen, und das Thema kann warten.
Was kosten technische Schulden?
Eine seriöse Pauschalzahl gibt es nicht. In einer Messung an 39 Softwaresystemen dauerte Arbeit an Code der schlechtesten Qualitätsstufe im Mittel 124 % länger als an gesundem Code. In einer Studie mit wiederholter Selbstauskunft gaben Entwickler durchschnittlich 23 % ihrer Arbeitszeit als Verlust durch technische Schulden an. Für Ihre Software gelten diese Werte nicht automatisch.
Die Tabelle ordnet bekannte Zahlen danach ein, wie sie entstanden sind. Die Zahlen in der Spalte „Quelle“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Zahl | Art der Daten | Was sie aussagt und was nicht | Quelle |
|---|---|---|---|
| 124 % längere Bearbeitung und 15-mal mehr Fehler in Code der schlechtesten Stufe gegenüber gesundem Code; in der mittleren Stufe 78 % länger | Messung: 39 Softwaresysteme, 30.737 Dateien, Daten aus Code und Ticketsystem, 2022 | Ein starker Zusammenhang, keine nachgewiesene Ursache. Alle Systeme stammen von Nutzern des Messwerkzeugs, der Erstautor arbeitet beim Hersteller. | 7 |
| 23 % der Arbeitszeit gehen verloren, im Median 17 %; in der Wiederholung 29 %, im Median 20 % | Selbstauskunft: 43 Entwickler aus sechs Firmen, sieben Wochen lang zweimal wöchentlich, dazu 47 Entwickler einer Firma in Deutschland, 2019 | Wenige Teilnehmende, starke Streuung. Die Autoren raten selbst zur Vorsicht. | 8 |
| 10–20 % des Budgets für neue Produkte fließen in Schuldenprobleme; die Schulden entsprechen 20–40 % des Werts des Technikbestands | Schätzung von 50 IT-Leitungen großer Finanz- und Technologiefirmen, Juli 2020 | Aussage über Konzerne mit mehr als 1 Mrd. US-Dollar Umsatz. Der zweite Wert bezieht sich auf den Bestand, das Budget ist etwas anderes. | 9 |
| 13,5 von 41,1 Wochenstunden für technische Schulden | Einschätzung von Entwicklern, 2018; befragt wurden über 1.000 Entwickler und über 1.000 Führungskräfte in fünf Ländern | Gefragt wurde nach dem Eindruck, gemessen wurde nichts. | 10 |
| 1,52 Billionen US-Dollar aufgelaufene technische Schulden in den USA | Schätzung eines Branchenkonsortiums, 2022 | Größenordnung für eine ganze Volkswirtschaft, für einen einzelnen Betrieb ohne Aussage. | 11 |
Für kleine Unternehmen haben wir keine belastbaren Werte gefunden. Auch der Abbau wirkt nicht von selbst: In zehn Open-Source-Projekten der Apache Software Foundation senkte die Mehrheit von 4.166 Refactorings, also Umbauten am Code ohne neue Funktion, die gemessenen Zinsen. Im Durchschnitt aller Fälle ließ sich aber keine Wirkung nachweisen (Nikolaidis u. a., 2022). Bei Microsoft sahen Entwickler im Refactoring erhebliche Kosten und Risiken (Kim u. a., 2014). Es kommt also darauf an, welche Stelle Sie angehen.
Wann lohnt sich der Abbau von technischen Schulden?
Der Abbau lohnt sich, wenn die eingesparten Zinsen den Aufwand innerhalb der Restlaufzeit der Software zurückzahlen. Rechnen Sie je Stelle: Änderungen im Jahr mal Mehraufwand je Änderung plus Fehlerkosten. Stellen, die niemand ändert, können bleiben, solange sie kein Sicherheitsrisiko sind.
Für die Rangfolge zählt, wo tatsächlich gearbeitet wird. Schulden in Code, der für die nächste Version erweitert wird, wiegen laut dem Dagstuhl-Bericht schwerer als Schulden in unberührten Bereichen. Fowler lässt stabile Stellen ebenfalls in Ruhe. Eine Studie von 2024 empfiehlt, neue Mängel vor allem in häufig geänderten Dateien zu verhindern (Borg u. a., 2024).
Mit diesen Fragen bewerten Sie eine Stelle. Das Raster haben wir aus diesen Quellen zusammengestellt, den Puffer und die Schwellen setzen wir nach eigener Einschätzung.
| Frage | So ermitteln Sie den Wert |
|---|---|
| Wie oft wurde die Stelle in den letzten 12 Monaten geändert? | Versionsverwaltung und Tickets auswerten |
| Wie viel länger dauert eine Änderung dadurch? | Das Team fragen: Wie lange ginge es an einer sauberen Stelle? |
| Wie viele Fehler gehen auf die Stelle zurück, und wie lange dauert die Behebung? | Tickets der letzten 12 Monate auswerten |
| Wie lange dauert der Abbau? | Schätzung des Teams plus 50 % Puffer |
| Wie lange wird die Software noch gebraucht? | Ihre Geschäftsplanung |
Daraus ergeben sich zwei Werte:
- Zinsen je Jahr: Änderungen im Jahr mal Mehraufwand je Änderung, dazu Fehler im Jahr mal Aufwand je Fehler.
- Rückzahlungsdauer: Abbauaufwand geteilt durch die Zinsen je Jahr.
| Ergebnis | Entscheidung |
|---|---|
| Die Stelle wird bald ersetzt oder abgeschaltet | Nicht abbauen, nur festhalten |
| Bekannte Sicherheitslücke, Supportende oder Wissen bei nur einer Person | Abbau terminieren, auch wenn die Rechnung nicht trägt |
| Rückzahlungsdauer unter der halben Restlaufzeit | Abbauen und einplanen |
| Rückzahlungsdauer zwischen halber und voller Restlaufzeit | Beim nächsten Umbau der Stelle mitnehmen |
| Rückzahlungsdauer länger als die Restlaufzeit | Stehen lassen und in der Liste vermerken |
Wann Bausteine ihr Supportende erreichen, zeigt der Abschnitt Wann werden Versionswechsel fällig?
Wie sieht ein Rechenbeispiel für den Abbau aus?
Im Beispiel kostet der Abbau einer Stelle einmalig 60 Stunden. Bei 12 Änderungen und 4 Fehlern im Jahr spart er 44 Stunden jährlich und zahlt sich nach rund 16 Monaten aus. Bei 2 Änderungen und 1 Fehler im Jahr rechnet er sich in vier Jahren nicht. Alle Werte sind Annahmen, die Sie durch Ihre eigenen ersetzen.
| Fall | Änderungen und Fehler im Jahr | Zinsen je Jahr | Zahlt sich aus nach | Saldo nach vier Jahren |
|---|---|---|---|---|
| A: häufig geändert | 12 Änderungen, 4 Fehler | 44 Stunden, 5.500 € | rund 16 Monaten | 116 Stunden gewonnen, 14.500 € |
| B: gelegentlich geändert | 6 Änderungen, 2 Fehler | 22 Stunden, 2.750 € | rund 33 Monaten | 28 Stunden gewonnen, 3.500 € |
| C: selten geändert | 2 Änderungen, 1 Fehler | 8 Stunden, 1.000 € | 90 Monaten | 28 Stunden verloren, 3.500 € |
So haben wir gerechnet:
- Abbau: 40 Stunden geschätzt, mit 50 % Puffer 60 Stunden, einmalig und zu Beginn. Bei 125 € je Stunde sind das 7.500 €.
- Zinsen je Änderung: 3 Stunden, die Arbeit dauert also 7 statt 4 Stunden. Das sind 75 % Mehraufwand; die mittlere Stufe der Messung oben lag bei 78 %.
- Zinsen je Fehler: 2 Stunden zusätzlich.
- Stundensatz: 125 €, der Median der Sätze nach Aufwand aus unserer Erhebung zur Software-Wartung.
- Restlaufzeit: vier Jahre.
- Zinsen in vier Jahren: 176 Stunden in Fall A, 88 in Fall B und 32 in Fall C, also die Zinsen je Jahr mal vier. Diese Werte zeigt die Grafik.
- Vereinfachungen: gleichbleibende Zinsen, keine Abzinsung, keine Kosten durch Ausfälle. Es sind keine Preise von Datafalke und keine Angebote.
Nach dem Raster heißt das: Fall A abbauen, Fall B beim nächsten Umbau mitnehmen, Fall C stehen lassen. Rechnen Sie zur Probe mit einem Drittel weniger Änderungen. Fall A zahlte sich dann nach rund 23 Monaten aus und bliebe unter der halben Restlaufzeit. Fall B läge bei 45 Monaten und damit nur knapp innerhalb der vier Jahre.
Wie bauen Sie technische Schulden ab, ohne alles neu zu schreiben?
Bauen Sie technische Schulden in kleinen Schritten ab, zuerst dort, wo die Zinsen am höchsten sind. Halten Sie jede Schuld in einer Liste fest, sichern Sie das Verhalten vor dem Umbau mit Tests ab und verbinden Sie den Abbau mit ohnehin geplanten Änderungen. Ein kompletter Neubau bleibt die letzte Wahl.
- Eine Liste führen: Die Architekturvorlage arc42 sieht dafür ein eigenes Kapitel vor, mit Risiken und technischen Schulden nach Priorität (arc42, Abschnitt 11). Je Eintrag reichen Stelle, Zinsen, Abbauaufwand, Entscheidung und Datum.
- Erst absichern, dann umbauen: Automatische Tests halten fest, was die Stelle heute tut. So fällt auf, wenn der Umbau etwas verändert.
- Beim Anfassen mitnehmen: Bauen Sie eine Stelle um, wenn ohnehin eine Änderung ansteht. Dort werden die Zinsen fällig.
- Neue Schulden bewusst aufnehmen: Eine Abkürzung ist erlaubt, wenn sie in der Liste steht und einen Termin für die Rückzahlung hat.
- Nicht alles neu schreiben: Ein kompletter Ersatz klingt einfach. Fowler hat aber erlebt, dass dieser Plan meist scheitert, unter anderem weil das bestehende Verhalten schwer zu erfassen ist. Er empfiehlt, ein Altsystem schrittweise abzulösen (Fowler, Strangler Fig, 2024).
Manchmal ist Standardsoftware die bessere Ablösung. Das klärt unser Vergleich Individual- oder Standardsoftware.
Was unterscheidet technische Schulden von Fehlern und Altsystemen?
Ein Fehler zeigt sich im Verhalten der Software. Technische Schulden bleiben für Nutzer oft unsichtbar und verteuern spätere Änderungen. Ein Altsystem ist alt, aber nicht zwangsläufig verschuldet, und junge Software kann hoch verschuldet sein. Wartung ist die laufende Arbeit an der Software, Refactoring ein Mittel zur Tilgung.
Die Zahlen in der Spalte „Quelle“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Begriff | Bedeutung | Verhältnis zu technischen Schulden | Quelle |
|---|---|---|---|
| Fehler (Bug) | Die Software verhält sich falsch. | Betrifft das Verhalten. Technische Schulden wirken laut Definition auf die innere Qualität. In der Messung oben ging schlechte Codequalität mit mehr Fehlern einher. | 2, 7 |
| Altsystem (Legacy) | Ältere Software, die weiter in Betrieb ist. | Alter allein ist keine Schuld. Code in Python 2 wird laut Google erst zur Schuld, wenn eine Umstellung nötig wird. | 5 |
| Wartung | Arbeit an der Software nach der Auslieferung. | Der Abbau kann Teil der Wartung sein oder als eigenes Projekt laufen. Das legt Ihr Vertrag fest. | – |
| Refactoring | Umbau von Code, ohne sein Verhalten zu ändern. | Das direkteste Mittel der Tilgung. In der Praxis verstehen Entwickler darunter oft mehr als die strenge Definition. | 12, 13 |
Was zur Wartung gehört und was sie kostet, steht in unserem Ratgeber Was kostet Software-Wartung?
Aus der Praxis: Eine bewusste Schuld auf dieser Website
Auch diese Website hat eine technische Schuld aufgenommen. Am 08.11.2026 um 16:27 Uhr haben wir neue Seiten hochgeladen, obwohl der vollständige Browsertest für den letzten Stand fehlte. Nach dem letzten ganzen Lauf hatten sich noch drei Stellen geändert, die wir nur gezielt geprüft haben. Dabei blieben 17 von 399 Prüffällen der Navigation rot, alle in Firefox, 15 davon ohne sichtbare Fokusanzeige bei offen gehaltenem Menü. Andere Browser und Seiten ohne offenes Menü waren nicht betroffen.
Die 17 Fälle waren Mängel im Verhalten. Die Schuld war die fehlende Gesamtprüfung, denn ohne sie wäre jede weitere Änderung riskanter gewesen. Schwächen beim Testen, etwa fehlende Tests, führt auch Google als eigene Kategorie technischer Schulden. Wir haben den Stand festgehalten und die Behebung einem eigenen Arbeitspaket zugeteilt. Das Paket war noch am selben Abend fertig. Der ganze Testlauf bestand danach mit 18.607 Browser-Tests, online ging die Korrektur am 09.11.2026 um 00:40 Uhr. Die Schuld bestand also gut acht Stunden.
Eine Rechnung nach dem Raster oben brauchten wir dafür nicht: Die Lücke war benannt, eng begrenzt und schon einem Arbeitspaket zugeteilt. Damit eine Schuld nicht unbemerkt wächst, gelten vor jeder Veröffentlichung feste Grenzen. Ein HTML-Dokument darf komprimiert höchstens 30.720 Byte groß sein. Als der Leitfaden zum technischen SEO zu groß wurde, haben wir ihn gekürzt.
Häufige Fragen
Kann ein Werkzeug technische Schulden messen?
Nur zum Teil. SonarQube etwa zählt den Aufwand, um alle Mängel an der Wartbarkeit zu beheben, und setzt ihn ins Verhältnis zu den Entwicklungskosten (Sonar, Kennzahlen). Das ist eine Schätzung der Tilgung, über die Zinsen sagt sie nichts. Google prüfte für drei Schuldenarten 117 Kennzahlen, und keine einzelne sagte voraus, wo Entwickler technische Schulden melden. Die einfachen Modelle erklärten weniger als 1 % der Unterschiede, kombinierte Modelle übersahen viele betroffene Stellen. Nutzen Sie Werkzeuge als Hinweis und fragen Sie Ihr Team.
Wie viel Entwicklungszeit sollte für den Abbau eingeplant werden?
Eine Studie, die eine feste Quote belegt, haben wir nicht gefunden. Manche Ratgeber nennen 20 % der Entwicklungszeit als Faustregel. Planen Sie deshalb Stelle für Stelle nach der Rechnung oben und legen Sie fest, wer darüber entscheidet. Es hilft, den Abbau mit geplanten Änderungen zu verbinden, weil die Stelle dann ohnehin geöffnet ist.
Macht KI-generierter Code mehr technische Schulden?
Eine große Studie spricht dafür. In 806 Open-Source-Projekten stiegen nach Einführung eines KI-Editors die Warnmeldungen der statischen Codeanalyse laut Hauptschätzung um 30 % und die Komplexität um 41 %, verglichen mit ähnlichen Projekten ohne dieses Werkzeug. Beides blieb, der Tempogewinn war nach zwei Monaten verschwunden (He u. a., 2026). Ob das auch bei sorgfältiger Prüfung gilt, beantwortet die Studie nicht. Code, den niemand im Team versteht, ist eine unbewusste Schuld: Er läuft, aber die nächste Änderung wird teuer. Solcher Code entsteht etwa beim Vibe Coding, bei dem eine KI den Code schreibt und niemand ihn liest (Willison, 2025).
Was sollte ich meinen Softwaredienstleister fragen?
Fragen Sie, ob es eine Liste der bekannten technischen Schulden gibt und wer sie pflegt. Lassen Sie sich die fünf Stellen mit dem höchsten Mehraufwand nennen und was ihr Abbau kosten würde. Fragen Sie, welche Bausteine in den nächsten zwölf Monaten ihr Supportende erreichen und wie viele Personen die Software ändern können. Wenn es keine Antworten gibt, ist das selbst ein Befund. Was bei uns zur Abnahme gehört, beschreibt die Seite Softwareentwicklung.