Technische Schulden: Ursachen, Kosten, Abbau
· DigifyNow
Technische Schulden entstehen, wenn Software über eine Abkürzung gebaut wird, etwa ohne Tests, mit fest verdrahteten Schnittstellen oder mit veralteten Bibliotheken. Die Abkürzung spart heute Zeit. Dafür kostet jede spätere Änderung Mehraufwand, und das sind die Zinsen. Tilgen heißt: die betroffenen Stellen gezielt umbauen, zuerst dort, wo oft geändert wird und Fehler auftreten, und vorher mit Tests absichern. Schulden in Code, der nie angefasst wird, dürfen stehen bleiben.
Was sind technische Schulden?
Technische Schulden sind eine Metapher aus der Softwareentwicklung. Gemeint ist der Mehraufwand, der später anfällt, weil heute eine schnelle statt einer sauberen Lösung gewählt wurde. Laut dem Wikipedia-Artikel zum Stichwort geht der Begriff auf den Softwareentwickler Ward Cunningham zurück. Das Bild passt gut, denn es hat zwei Teile. Die Tilgung ist der Aufwand, die Abkürzung später ordentlich umzubauen. Die Zinsen sind der laufende Mehraufwand, solange das nicht passiert: Jede neue Funktion dauert länger, weil das Team um die Abkürzung herumbauen muss, und jeder Fehler ist schwerer zu finden.
Für Sie als Geschäftsführer heißt das: Technische Schulden tauchen in keiner Bilanz auf. Bemerkbar machen sie sich erst über Umwege, zum Beispiel wenn eine kleine Änderung plötzlich Wochen dauert oder ein Update der Software etwas an einer ganz anderen Stelle kaputt macht. Schlecht sind Schulden nicht automatisch. Wenn ein Team sich bewusst verschuldet, um früher am Markt zu sein, und die Schuld aufschreibt, kann das eine vernünftige Entscheidung sein. Teuer wird es bei Schulden, die niemand bemerkt und die deshalb auch niemand einplant.
Ein Beispiel: die schnelle Anbindung an die Warenwirtschaft
Ein Händler will Bestellungen aus seinem Onlineshop automatisch in die Warenwirtschaft übertragen. Weil es schnell gehen muss, schreibt ein Entwickler ein Skript. Darin stehen Zugangsdaten, Feldnamen und die Logik für Versandarten direkt im Code. Es gibt keine Tests und keine Protokollierung, und Fehler werden stillschweigend übersprungen. Das Skript funktioniert und spart erst einmal Zeit.
Ein Jahr später kommt eine neue Versandart dazu. Wer das Skript ändert, findet die Logik an mehreren Stellen und kann nicht prüfen, ob danach noch alles stimmt. Ändert die Warenwirtschaft ein Feld, kommen Bestellungen nicht mehr an, und weil Fehler übersprungen werden, fällt das erst bei einer Kundenbeschwerde auf. Jede dieser Stunden ist ein Zins. Getilgt wird so: Konfiguration aus dem Code herausziehen, einen Test je Versandart schreiben und Fehler protokollieren, statt sie zu verschlucken. Wie Schnittstellen sauber aufgebaut werden, erklärt unser Artikel API Schnittstelle: Definition, Beispiel, Praxis.
Welche Arten technischer Schulden gibt es?
Technische Schulden stecken nicht nur im Code. Mindestens die folgenden sechs Arten lassen sich unterscheiden, und jede zeigt sich an anderen Symptomen. Quer dazu liegt eine zweite Frage, die der Softwareautor Martin Fowler in seinem sogenannten Quadranten beschreibt: Wurde die Schuld bewusst oder versehentlich aufgenommen, umsichtig oder leichtfertig? Eine bewusste, aufgeschriebene Abkürzung ist planbar. Bei einer versehentlichen weiß niemand, wo sie steckt.
| Art | Wie sie entsteht | Woran man sie merkt |
|---|---|---|
| Code | Kopierte Logik, unklare Namen, sehr lange Funktionen | Kleine Änderungen brauchen unerwartet lange |
| Architektur | Module greifen direkt auf die Daten anderer Module zu | Eine Änderung zieht Fehler an fremden Stellen nach sich |
| Abhängigkeiten und Infrastruktur | Bibliotheken, Frameworks oder Server werden nicht aktualisiert | Sicherheitsupdates lassen sich nicht einspielen, ohne dass etwas bricht |
| Tests | Automatische Tests fehlen oder werden übersprungen | Vor jedem Release wird manuell geklickt, Fehler kommen trotzdem durch |
| Dokumentation und Wissen | Nur eine Person kennt das System | Urlaub oder Kündigung dieser Person blockiert Änderungen |
| Daten | Freitextfelder statt Auswahlwerten, Dubletten, kein Pflichtfeld | Auswertungen widersprechen sich, Migrationen werden aufwendig |
Woran erkennen Sie technische Schulden, ohne Code zu lesen?
Als Entscheider müssen Sie den Code nicht lesen, um technische Schulden zu bemerken. Es reicht, auf bestimmte Muster im Alltag zu achten. Jedes der folgenden Signale ist für sich genommen kein Beweis. Kommen mehrere zusammen, lohnt sich ein genauer Blick:
- Schätzungen für ähnlich große Änderungen werden von Mal zu Mal länger, obwohl das Team gleich bleibt.
- Ein Bereich der Software gilt als „besser nicht anfassen“. Dort sammeln sich dann Umgehungslösungen.
- Nach Releases tauchen Fehler in Funktionen auf, die gar nicht geändert wurden.
- Updates des Betriebssystems, des Frameworks oder der Datenbank werden aufgeschoben, weil niemand die Folgen abschätzen kann.
- Neue Entwickler brauchen auffällig lange, bis sie eigenständig etwas ändern können.
- Fragen nach Datenstand oder Ablauf kann nur eine bestimmte Person beantworten.
Fragen Sie Ihr Team oder Ihren Dienstleister ruhig direkt, wo die größten Schulden liegen. Wer darauf sofort konkrete Stellen nennt, hat den Überblick. Lautet die Antwort „keine“, ist das selten ein gutes Zeichen.
Was kosten technische Schulden?
Pauschal lässt sich das nicht beziffern, denn die Kosten hängen am Mechanismus und nicht an der Menge unsauberen Codes. Die Zinsen fallen nur an, wenn jemand eine Stelle anfasst. Ein unschönes Modul, das seit Jahren unverändert läuft, kostet praktisch nichts. Eine verschuldete Kernfunktion, die jeden Monat erweitert wird, kostet bei jeder Erweiterung erneut. Den Ausschlag geben vier Dinge: wie oft der betroffene Bereich geändert wird, wie viele Schnittstellen an ihm hängen, wie viele Daten sich bei einem Umbau mitbewegen müssen und ob es Tests gibt, die einen Umbau absichern.
Daneben gibt es Kosten, die keine Stundenzettel zeigen: aufgeschobene Sicherheitsupdates, Abhängigkeit von einzelnen Personen und Funktionen, die gar nicht erst gebaut werden, weil sie zu aufwendig erscheinen. Eine belastbare Zahl entsteht erst, wenn jemand die konkreten Stellen ansieht und Tilgung und Zinsen getrennt schätzt. Welche Faktoren Entwicklungsaufwand allgemein treiben, beschreibt der Artikel Kosten für Softwareentwicklung: Was sie treibt.
Wie baut man technische Schulden ab?
Abbauen klappt am besten nebenbei und in kleinen Schritten, nicht als großes Projekt. Ein Vorgehen, das auch ohne eigene IT-Abteilung funktioniert:
- Schuldenregister anlegen: Jede bekannte Abkürzung kommt mit Ort, Ursache und Symptom auf eine Liste, die im selben System liegt wie die übrigen Aufgaben.
- Priorisieren nach Änderungshäufigkeit und Schmerz: Zuerst kommen Stellen, die oft geändert werden und dabei Fehler verursachen. Selten berührter Code wartet.
- Vor dem Umbau absichern: Automatische Tests halten fest, wie sich die betroffene Funktion heute verhält. Ohne sie lässt sich nicht prüfen, ob der Umbau etwas kaputt gemacht hat.
- In kleinen Schritten umbauen (Refactoring): Das Verhalten bleibt gleich, nur die Struktur ändert sich. Jeder Schritt wird einzeln getestet und ausgeliefert.
- Kapazität fest einplanen: In jedem Entwicklungszyklus ist ein fester Anteil für Tilgung reserviert, statt auf eine ruhige Phase zu warten, die nie kommt.
- Abhängigkeiten laufend aktualisieren: Werkzeuge wie Dependabot auf GitHub legen für veraltete Pakete automatisch Änderungsvorschläge an, die das Team dann prüft.
- Neue Schulden sichtbar machen: Wer bewusst eine Abkürzung nimmt, trägt sie sofort ins Register ein.
Wie Dependabot konfiguriert wird, steht in der GitHub-Dokumentation unter https://docs.github.com. Auch KI-Werkzeuge können beim Umbau helfen. Sie erzeugen allerdings selbst neue Schulden, wenn ihr Code ohne Prüfung übernommen wird. Mehr dazu im Artikel KI-Softwareentwicklung: Was KI am Code leistet.
Wann lohnt sich Abbauen nicht, und wann ein Neubau?
Nicht jede Schuld muss getilgt werden. Wird ein System in absehbarer Zeit abgelöst, wäre Umbauen verschwendete Arbeit. Dann reicht es, die Sicherheit zu erhalten und bis zur Ablösung keine neuen Funktionen mehr anzubauen. Auch bei einem Prototyp, der nur eine Frage beantworten soll, sind Abkürzungen in Ordnung, solange er danach nicht stillschweigend zum Produktivsystem wird. Genau das passiert in der Praxis allerdings oft.
Häufig wird der komplette Neubau als Ausweg vorgeschlagen, und genau der scheitert besonders oft. Das alte System enthält jahrelang gesammeltes Wissen über Sonderfälle, das nirgends aufgeschrieben ist. Während der Neubau läuft, muss das Altsystem weiter gepflegt werden, und beide entwickeln sich auseinander. Sinnvoller ist meist eine schrittweise Ablösung: Ein Bereich nach dem anderen wird neu gebaut und hinter einer Schnittstelle umgeschaltet, das Altsystem schrumpft Stück für Stück. Ein Neubau lohnt sich eher, wenn die Plattform selbst nicht mehr unterstützt wird oder das Datenmodell grundlegend nicht zum Geschäft passt. Dann gehört auch eine geplante Datenmigration dazu.
Technische Schulden im MVP: bewusst aufnehmen, sichtbar halten
Ein MVP ist absichtlich klein und schnell gebaut. Da liegt der Gedanke nahe, Qualität ganz wegzulassen. Hier lohnt eine Unterscheidung: Bei Oberfläche, Komfortfunktionen oder Automatisierungen, die anfangs auch manuell laufen können, darf man sparen. Am Datenmodell, an der Rechteverwaltung und an Tests für die Kernfunktion sollte man dagegen nicht sparen. Diese Teile später zu korrigieren ist besonders teuer, weil alles andere auf ihnen aufbaut und echte Daten mitwandern müssen. Wie DigifyNow ein MVP in vier bis acht Wochen zuschneidet, beschreibt der Artikel MVP entwickeln lassen: Kosten und Dauer.
DigifyNow entwickelt individuelle Apps, Web-Apps und Software für kleine und mittlere Unternehmen und betreut sie auch im laufenden Betrieb. Dazu gehört, Abkürzungen im MVP offen zu benennen und ihren Abbau in die Planung der folgenden Ausbaustufen aufzunehmen. Einen Überblick gibt die Seite mit den Leistungen von DigifyNow in Softwareentwicklung und KI.
Wann sich Unterstützung lohnt
Hilfe von außen ist sinnvoll, wenn Sie Signale wie längere Änderungszeiten oder aufgeschobene Updates bemerken, intern aber niemand die Ursache benennen kann. Das gilt auch, wenn die einzige Person, die das System kennt, nicht mehr verfügbar ist, oder wenn Sie zwischen Umbau und Ablösung entscheiden müssen. Bereithalten sollten Sie Zugang zum Quellcode und zum Hosting, eine Liste der angebundenen Systeme, die letzten bekannten Fehler und die Änderungen, die als Nächstes anstehen. Über das Kontaktformular für eine kostenlose Einschätzung Ihres Systems schildern Sie die Lage, und DigifyNow meldet sich mit einer ersten Einschätzung, welche Stellen genauer geprüft werden sollten.
Häufige Fragen
Wie heißt „technische Schulden“ auf Englisch?
Der englische Begriff lautet „technical debt“, im Deutschen sagt man auch „technische Schuld“. Gemeint ist in beiden Sprachen dasselbe: der spätere Mehraufwand, der entsteht, weil in der Softwareentwicklung eine schnelle statt einer sauberen Lösung gewählt wurde. In deutschen Teams fallen oft beide Begriffe, auch im selben Satz.
Was bedeutet „debt“ auf Deutsch?
„Debt“ heißt auf Deutsch Schuld oder Schulden, also eine Verbindlichkeit, die zurückgezahlt werden muss. Im Ausdruck „technical debt“ wird die finanzielle Bedeutung bildlich übertragen: Die Abkürzung entspricht dem Kredit, der spätere Mehraufwand bei Änderungen den Zinsen und der saubere Umbau der Tilgung.
Was ist mit dem Begriff „Schulden“ gemeint?
Schulden sind Verpflichtungen, die man heute eingeht und später begleichen muss, meist mit Zinsen. Bei technischen Schulden besteht die Verpflichtung nicht aus Geld, sondern aus Arbeit: Jede Abkürzung im Code muss später entweder umgebaut werden, das ist die Tilgung, oder sie verursacht bei jeder Änderung Mehraufwand, das sind die Zinsen.
Sind technische Schulden immer schlecht?
Nein. Eine bewusst aufgenommene und dokumentierte Schuld kann sinnvoll sein, etwa um ein MVP früher zu testen. Problematisch sind unbemerkte Schulden und solche in Bereichen, die oft geändert werden, denn dort fallen die Zinsen bei jeder Änderung an. In Code, der nie angefasst wird, kostet eine Schuld praktisch nichts.