Die Zinsen von technischen Schulden

Dienstag, 9:53 Uhr. Anruf bei unserem Geschäftsführer.

„Thomas, wir wollen ein neues Feature in unser Produktionssystem einbauen. Wie lange dauert das?“

Thomas schaut sich den Code an. Dann die Datenbank. Die Dokumentation kann er sich nicht anschauen; es gibt keine.

Seine Antwort: „Das Feature selbst? 10 Tage. Es sicher zu implementieren? 3 Monate.“

Die Reaktion des Anrufers: „WIE BITTE?“

Die Reaktion ist nicht überraschend. Sie basiert auf einer Wahrnehmung, die einen zentralen Aspekt bei der Entwicklung von Software konsequent übersieht. Das neue Feature lässt sich relativ einfach implementieren, alles andere wird aber zum Problem:

• Acht Jahre gewachsener Code.
• Keine automatisierten Tests.
• Geschäftslogik verteilt in hunderten Datenbank-Prozeduren.
• Eine Änderung führt zu drei Anpassungen an anderen Stellen.

Ein neues Feature in ein solches System einzubauen, ist wie Jenga spielen: Sie ziehen einen Stein raus und hoffen, dass der Turm nicht einstürzt.

Die versteckten Kosten:

• Das Feature selbst: zehn Tage Entwicklung, rund 9000 Euro.
• Die Risikobegrenzung: Tests, Dokumentation und Review, rund zehn Wochen, etwa 45000 Euro.
• Und wenn etwas schiefgeht: Produktionsausfall, Bugfixing, Imageschaden. Viel zu viele Euro.

Dieses Szenario hat einen Namen: Technische Schulden.

Technische Schulden funktionieren wie ein Kredit, der die Softwareentwicklung beschleunigt. Doch dieser Kredit ist nicht kostenlos. Zinsen werden fällig. Und Zinsen auf die Zinsen.

Was vor drei Jahren ein Projekt von zehn Tagen gewesen wäre, dauert heute drei Monate.

Nicht, weil Entwickler langsamer geworden sind, sondern weil das System gewachsen ist und komplexer wurde. Niemand hat aufgeräumt. Niemand hat begonnen, die Zinsen zu zahlen und die Schulden zu tilgen. [1]

Dies ist ein Beitrag über die Zinsen technischer Schulden und darüber, warum es sich lohnt, sich regelmäßig mit ihnen zu beschäftigen.

Erschreckende Zahlen der Gegenwart

Technische Schulden sind kein Randthema und kein internes Ärgernis, das man mit etwas gutem Willen beheben könnte. Sie betreffen Organisationen in ihrer ganzen Breite. Und die Lage ist ernster, als viele glauben.

Eine aktuelle Capterra-Studie [2] zeigt ein Bild, das kaum düsterer ausfallen könnte. Nur 29 Prozent der Softwarekäufer in Deutschland sind mit ihrer Entscheidung zufrieden. Anders formuliert: Zwei Drittel investieren Zeit, Budget und Hoffnung in ein Produkt, das am Ende nicht liefert, was es verspricht. Software beschafft oder entwickelt man nicht, um den Tag spannender zu machen. Man tut dies, um ein Problem zu lösen. Wenn danach vor allem Ernüchterung bleibt? Autsch.

Noch deutlicher wird das Ausmaß, wenn man auf die Ursachen schaut. Die größte Quelle der Enttäuschung sind nicht fehlende Funktionen, sondern Störungen während der Einführung und im laufenden Betrieb. Sobald es hakt, bereuen 85 Prozent der betroffenen Käufer ihren Kauf. Ein Ausfall im falschen Moment, eine instabile Performance, ein Prozess, der kurz nach dem Go-live ins Stocken gerät: Schon wird aus dem erhofften Fortschritt ein Rückschritt.

Die häufigsten Gründe für diese Enttäuschung lesen sich wie ein Lehrbuch über technische Schulden. Bugs. Abstürze. Performance-Probleme. Mangelnde Zuverlässigkeit. Unzureichender Support. Nichts davon entsteht über Nacht. Alles davon ist die direkte Folge von Systemen, die über Jahre gewachsen sind, ohne dass Qualität, Tests und Wartbarkeit konsequent mitgewachsen wären.

Bemerkenswert ist, was die zufriedenen Käufer anders machen. Sie planen Einführung und Betrieb bewusster. Sie definieren Anforderungen klarer. Sie prüfen Sicherheit gründlicher. Sie verlassen sich auf echte Erfahrungswerte statt auf Marketingformulierungen. Kurz: Sie behandeln Software nicht als Produkt, das man einmal einführt, sondern als Verantwortung, die gepflegt werden muss.

Diese Zahlen zeigen keine Ausnahmen und keine Momentaufnahme. Sie zeigen ein Muster. Ein Muster, das eng mit technischen Schulden verknüpft ist und Organisationen teuer zu stehen kommt.

Warum entstehen technische Schulden?

Technische Schulden entstehen selten, weil jemand schlechten Code schreiben möchte. Niemand steht morgens auf und denkt: Heute baue ich etwas, das in drei Jahren garantiert Probleme macht. Und doch passiert genau das. Immer wieder. In fast jedem Unternehmen.

Es gibt vier zentrale Gründe, die sich hartnäckig durch nahezu alle Projekte ziehen.

Der erste Grund ist offensichtlich: fehlende Fähigkeiten im Team. Wenn Entwickler bestimmte Muster nicht kennen, wenn Architekturprinzipien unklar sind oder wenn wichtige Grundlagen fehlen, landet man schnell bei Lösungen, die kurzfristig funktionieren, aber langfristig teuer werden. Doch dieser Punkt erklärt nur einen kleinen Teil der technischen Schulden.

Der zweite Grund ist deutlich verbreiteter: Zeitdruck. Deadlines, Releases, Versprechen gegenüber Kunden. In solchen Situationen gewinnt oft die schnellste Lösung, nicht die beste. Kurzfristige Abkürzungen fühlen sich harmlos an, doch die Zinsen folgen später. Ein Patch hier, eine Kopie eines Moduls dort, eine Ausnahme im Code, die später einmal sauber gelöst werden soll. Später kommt jedoch selten. Und aus vielen kleinen Abkürzungen entsteht ein System, das niemand mehr anfassen möchte, ohne vorher tief durchzuatmen.

Der dritte Grund ist tückischer: fehlendes Verständnis für das eigentliche Problem. Wenn unklar ist, wofür ein Feature gebraucht wird oder wie ein Prozess wirklich funktioniert, wird eine Lösung gebaut, die zwar funktioniert, aber das falsche Problem löst. Das erzeugt unnötige Komplexität, erschwert Anpassungen und macht Systeme schwerer zu betreiben und zu skalieren.

Der vierte Grund ist unvermeidlich: Das Geschäft verändert sich. Selbst sauber entwickelte Software wird irgendwann zum Hindernis, wenn Anforderungen wachsen, Märkte sich verschieben oder neue regulatorische Vorgaben kommen. Eine Architektur, die gestern perfekt war, kann morgen an ihre Grenzen stoßen, weil das Unternehmen größer, schneller oder digitaler geworden ist.

Diese vier Gründe führen zu einer Erkenntnis, die viele ungern hören: Technische Schulden entstehen nicht durch Nachlässigkeit, sondern durch Realität. Durch Entscheidungen unter Unsicherheit. Durch Tempo. Durch Wachstum. Durch Komplexität. Und durch den Versuch, gleichzeitig zu entwickeln und zu betreiben.

Kurz gesagt: Technische Schulden entstehen, weil Software lebt. Und weil niemand im Alltag die perfekte Entscheidung trifft. Die Frage ist also nicht, ob technische Schulden entstehen. Sondern, was man danach mit ihnen macht.

Abbildung: Vier Gründe für technische Schulden

Technische Schulden in Zeiten von KI

Künstliche Intelligenz verändert die Art und Weise, wie Software entwickelt wird. Sie beschleunigt vieles, sie erleichtert vieles und sie eröffnet Möglichkeiten, die vor wenigen Jahren undenkbar waren. Doch mit dieser Geschwindigkeit kommt ein neues Risiko: Technische Schulden entstehen heute schneller als je zuvor.

Viele Teams erleben eine paradoxe Entwicklung. Einerseits unterstützt KI beim Schreiben von Code. Sie erzeugt Funktionen, schlägt Lösungen vor und liefert Ergebnisse in Minuten. Andererseits entsteht genau dadurch ein neues Problem. Denn Geschwindigkeit ersetzt keine Architektur. Wenn Code ohne Verständnis für Aspekte wie Separation of Concerns, Sicherheit, Skalierbarkeit oder Testbarkeit generiert wird, entsteht kein Fortschritt, sondern künftiger Aufwand.

Die Folgen sieht man bereits im Alltag vieler Organisationen. Prototypen entstehen in rasanter Geschwindigkeit, wirken vielversprechend und verleiten zur zügigen Inbetriebnahme. Oft deutlich zu früh. Code wächst in die Breite, aber nicht in die Tiefe. Tests fehlen, Dokumentation fehlt, Struktur fehlt. KI macht es leicht, in kürzester Zeit viel Software zu erzeugen. Und ebenso leicht, Zinsen in rasanter Geschwindigkeit anwachsen zu lassen.

Gleichzeitig wird eine zweite Chance übersehen. Wir überschätzen, wie schnell wir mit KI bauen können, und wir unterschätzen, wie viel besser wir mit KI bauen könnten. Denn dieselben Werkzeuge, die heute ungetesteten Code produzieren, könnten helfen, technische Schulden zu reduzieren. KI kann Tests generieren [3], Architekturentwürfe prüfen, Sicherheitslücken erkennen, Codekomplexität analysieren und Abhängigkeiten sichtbar machen.

Das größte Potenzial liegt jedoch noch vor uns. KI könnte in Zukunft große Systeme gezielt refaktorieren, dokumentieren und modernisieren. Sie könnte Entwicklern ermöglichen, unbekannte Systeme sofort zu verstehen. Und sie könnte jene Aufgaben übernehmen, die heute Monate dauern und ganze Teams blockieren.

Doch dort sind wir noch nicht. Im Moment ist KI vor allem ein Verstärker. Ein Verstärker der guten wie der schlechten Entscheidungen. Wer sauber arbeitet, erzielt mit KI schneller bessere Ergebnisse. Wer aber ohne Architekturverständnis arbeitet, erzeugt Schulden im Akkord.

KI macht technische Schulden nicht automatisch schlimmer. Aber sie erhöht die Geschwindigkeit, mit der sie entstehen. Und genau diese Beschleunigung sollte man ernst nehmen. In einer Welt, in der Software schneller geschrieben wird als je zuvor, entscheidet Qualität noch stärker darüber, ob ein Unternehmen in drei Jahren innovativ bleibt oder den Zinseszins seiner technischen Schulden begleichen muss.

Warum lassen sich technische Schulden nicht vermeiden?

Technische Schulden haben einen schlechten Ruf. Sie gelten als Fehler, als Nachlässigkeit oder als Zeichen mangelhafter Disziplin. Doch dieser Blick greift zu kurz. Technische Schulden lassen sich nicht vollständig vermeiden. Nicht in kleinen Projekten, nicht in großen Systemen und erst recht nicht in Organisationen, die wachsen, sich verändern und unter Zeitdruck stehen.

Der erste Grund dafür ist trivial, aber entscheidend: Jede Software lebt. Anforderungen ändern sich, Märkte bewegen sich, Regeln werden angepasst. Eine Architektur, die heute perfekt passt, kann morgen zum Hindernis werden. Nicht weil sie schlecht entwickelt wurde, sondern weil die Welt sich weitergedreht hat.

Der zweite Grund liegt im Alltag der Produktentwicklung. Projekte laufen nie unter idealen Bedingungen. Deadlines verschieben sich nicht, Anforderungen sind nicht immer vollständig verstanden und Teams müssen oft liefern, bevor alles endgültig geklärt ist. Kurze Wege, schnelle Lösungen und pragmatische Entscheidungen sind unvermeidlich. Sie helfen, Tempo aufzubauen, erzeugen aber zwangsläufig Schulden.

Der dritte Grund ist strategischer Natur. Manche Abkürzung ist bewusst gewählt. Wenn ein Feature dringend auf den Markt muss oder ein regulatorischer Termin nicht verschoben werden kann, entsteht ein Zielkonflikt. Die Wahl lautet dann nicht: Qualität oder keine Qualität. Sie lautet: Jetzt liefern oder später Zinsen zahlen. Wer in solchen Situationen eine schnelle Lösung einsetzt, macht nichts falsch. Er verschiebt nur den Preis nach hinten.

Der vierte Grund ist technischer Fortschritt. Neue Technologien, neue Frameworks und neue Infrastrukturen entstehen in hoher Geschwindigkeit. Was vor drei Jahren Stand der Technik war, gilt heute als schwerfällig. Systeme altern, auch wenn der Code sauber ist. Die Frage ist nicht, ob sie altern. Die Frage ist, ob man rechtzeitig investiert, damit die Software mit dem Wandel umgehen kann.

Technische Schulden sind also nicht das Ergebnis schlechter Arbeit, sondern das Ergebnis realer Entscheidungen unter realen Bedingungen. Sie entstehen automatisch, sobald Software wächst, sobald Unternehmen wachsen und sobald es mehr gibt als einen stabilen Zustand.

Entscheidend ist daher nicht die Illusion, sie vermeiden zu können. Entscheidend ist, sie sichtbar zu machen, bewusst zu managen und regelmäßig zu tilgen. Wer das tut, arbeitet nicht gegen technische Schulden an, sondern mit ihnen. Und das ist der einzige Weg, langfristig beweglich zu bleiben.

Wie man mit technischen Schulden umgehen sollte

Wenn technische Schulden unvermeidlich sind, stellt sich die nächste Frage: Wie gelingt der Umgang mit ihnen so, dass Systeme stabil bleiben, Teams handlungsfähig bleiben und Unternehmen nicht irgendwann vor einem kompletten Stillstand stehen?

Der erste Schritt ist banal und wird doch oft übersprungen: Sichtbarkeit. Technische Schulden verschwinden nicht, wenn man sie ignoriert. Sie werden nur teurer. Teams brauchen deshalb ein gemeinsames Verständnis darüber, wo Schulden liegen, wie groß sie sind und welche Folgen sie haben. Das ist keine Schönheitskorrektur. Es ist Risikomanagement.

Der zweite Schritt betrifft den Rhythmus der Arbeit. Wer Schulden kontinuierlich abbaut, bleibt beweglich. Wer wartet, bis es nicht mehr anders geht, zahlt hohe Zinsen. Es braucht feste Investitionszeiten, in denen refaktoriert, getestet, entschlackt und modernisiert wird. Nicht als Ausnahme, sondern als Arbeitsprinzip. Teams, die in jeder Iteration Raum dafür schaffen, verschenken keine Zeit. Sie kaufen sich Zukunft.

Der dritte Schritt ist Ehrlichkeit im Umgang mit Abkürzungen. Manchmal führt kein Weg daran vorbei. Ein Marktstart drängt, ein Kunde braucht etwas sofort oder eine regulatorische Vorgabe lässt sich nicht verschieben. In solchen Momenten entsteht technische Schuld bewusst. Aber dann gilt: Aufschreiben, offen kommunizieren, und unmittelbar danach aufräumen. Abkürzungen sind nur dann gefährlich, wenn man sie als dauerhafte Lösung stehen lässt.

Der vierte Schritt betrifft Entscheidungen auf Systemebene. Viele technische Schulden entstehen nicht im Code einzelner Funktionen, sondern in der Architektur. Dort reichen ein paar Stunden nicht aus, um Probleme zu lösen. Es braucht eine klare Vision, wie sich das System entwickeln soll, und eine technische Roadmap, die diese Vision schrittweise umsetzt. Große Verbesserungen entstehen nicht in einem Sprint, aber sie entstehen, wenn man sie in jeden Sprint einwebt.

Der fünfte Schritt ist Zusammenarbeit. Technische Schulden betreffen nicht nur Entwickler. Produktmanagement, Betrieb, Security und Führungskräfte tragen Verantwortung dafür, wie viel Raum Qualität bekommt. Wenn Wertschöpfung ausschließlich über neue Features definiert wird, entsteht automatisch Druck, der Schulden erzeugt. Wenn Qualität Teil der Wertschöpfung ist, entsteht Raum, Schulden abzubauen.

Der sechste Schritt ist kultureller Natur. Teams, die Software beim Arbeiten verbessern, statt sie nur zu nutzen, haben einen Vorteil. Dazu gehören einfache Regeln, wie etwa der Anspruch, dass jeder Code, den man berührt, in einem besseren Zustand zurückgelassen wird. Kleine Verbesserungen summieren sich. Und sie verhindern, dass ein System über Monate hinweg unmerklich verrottet.

Technische Schulden lassen sich nicht wegautomatisieren. Auch KI wird das Problem nur dann reduzieren, wenn Menschen Entscheidungen treffen, die Qualität erlauben. Der entscheidende Unterschied zwischen Unternehmen, die mit ihren Systemen wachsen, und Unternehmen, die an ihnen scheitern, liegt daher nicht im Code. Er liegt in der Haltung.

Wer technische Schulden als unvermeidbare Begleiter behandelt, aber nicht als Schicksal akzeptiert, hat einen klaren Vorteil. Denn der Preis für konsequente Pflege ist überschaubar. Der Preis für jahrelanges Ignorieren ist es nicht.

Fazit

Technische Schulden sind kein Ausnahmefall, sondern eine unausweichliche Begleiterscheinung lebender Systeme. Sie entstehen durch Zeitdruck, falsche Prioritäten, unvollständiges Problemverständnis und die Dynamik des Geschäfts. KI beschleunigt diese Entwicklung zusätzlich und kann Schulden schneller anwachsen lassen, als Teams sie kontrollieren können. Gleichzeitig bietet sie Chancen, Qualität, Architektur und Wartbarkeit zu stärken, wenn man sie bewusst einsetzt.

Entscheidend ist nicht, technische Schulden zu vermeiden, sondern sie sichtbar zu machen, systematisch zu managen und ihre Zinsen bewusst zu bezahlen. Wer kontinuierlich investiert, bleibt handlungsfähig. Wer jahrelang wartet, steht irgendwann vor einem System, das nur noch durch teure Modernisierung zu retten ist.

Erinnern Sie sich noch an den Anrufer vom Anfang des Beitrags? Er hat das neue Feature erst einmal auf Eis gelegt. Stattdessen investiert er jetzt drei Monate in die Modernisierung des Systems, damit sich das nächste Feature sicher in zwei Wochen implementieren lässt. Das ist die richtige Entscheidung, aber sie kommt drei Jahre zu spät. Drei Jahre, in denen die Zinsen technischer Schulden still vor sich hin gewachsen sind, bis sie niemand mehr ignorieren konnte.

Was bleibt, ist eine direkte Frage: Wie lange dauert die Implementierung eines einfachen Features in Ihrem System?

Hinweise:

[1] Die Geschichte stammt aus der Feder von Dennis Wilke und findet sich in einem LinkedIn-Posting.
[2] Capterra-Studie: Software Buying Trends 2026 – So gelingt die Softwareauswahl: 5 Erfolgsstrategien deutscher Unternehmen
[3] Unit-Tests mit KI generieren – ein Erfahrungsbericht über die Erstellung von Unit-Tests mit ChatGPT, Claude und Gemini

Das Software Engineering Institute der Carnegie Mellon University definiert übrigens 13 Arten von technischen Schulden.

Hier können Sie sich den Technische Schulden Guide kostenlos herunterladen.

Suchen Sie nach einem Team für Ihre Softwareentwicklung oder -modernisierung? Dann laden Sie sich den t2informatik Steckbrief herunter.

Wollen Sie als Multiplikatorin oder Meinungsführer über die Zinsen von technischen Schulden diskutieren? Dann teilen Sie diesen Beitrag in Ihren Netzwerken.

Michael Schenkel hat weitere Beiträge im t2informatik Blog veröffentlicht, u. a.: