Technische Schulden: Was sie kosten und wann sie gefährlich werden

Was technische Schulden eigentlich sind — und was nicht

Der Begriff stammt aus dem Jahr 1992 und wurde von einem Entwickler als Metapher eingeführt: Man leiht sich Zeit. Man baut ein System schneller, als man es bei sorgfältiger Planung sollte, um früher fertig zu werden. Dafür zahlt man später — mit Zinsen.

Was das im Alltag bedeutet, merken Unternehmen meist dann, wenn sie etwas ändern wollen und feststellen, dass jede Änderung mehr kostet als erwartet. Eine neue Funktion, die in anderen Systemen wenige Tage dauert, braucht hier drei Wochen. Ein Fehler wird behoben — und zwei andere tauchen auf. Eine Anfrage, die einfach klingt, erzeugt einen Kostenvoranschlag, der sich liest wie eine Generalüberholung.

Das ist der Moment, in dem technische Schulden sichtbar werden. Nicht durch das, was nicht funktioniert — durch das, was zu langsam und zu teuer geht.

Was keine technischen Schulden sind

Der Begriff wird häufig mit Fehlern gleichgesetzt. Das ist ungenau. Ein Fehler ist etwas, das nicht funktioniert. Technische Schulden funktionieren — nur auf eine Art, die mit der Zeit teurer wird.

Und sie entstehen nicht durch Nachlässigkeit. Viele Entscheidungen sind zum Zeitpunkt, an dem sie getroffen werden, vernünftig. Ein System wird für hundert Nutzer gebaut. Zwei Jahre später sind es zehntausend. Die ursprüngliche Architektur war für hundert korrekt — für zehntausend ist sie eine Bremse. Niemand hat dabei einen Fehler gemacht.

Technische Schulden sind auch kein Zeichen dafür, dass das Entwicklungsteam schlechte Arbeit geleistet hat. Manchmal verhält es sich umgekehrt: Wer zu früh auf Perfektion baut, baut an Anforderungen vorbei, die noch nicht existieren. Die Schulden entstehen dann durch Komplexität, die niemand braucht.

Worum es wirklich geht

Technische Schulden sind aufgeschobener Aufwand. Ähnlich wie bei Instandhaltung: Ein Gebäude, das man zehn Jahre nicht streicht, ist nicht kaputt. Aber es kostet beim nächsten Anstrich mehr — weil die Oberfläche schlechter ist, mehr Vorbereitung braucht und inzwischen Schäden entstanden sind, die mit Streichen allein nicht mehr zu beheben sind.

Der Unterschied zur Instandhaltung: Bei Gebäuden sieht man, was aufgeschoben wird. Bei Software nicht. Das macht es schwerer, den Aufwand zu erklären — und leichter, ihn zu unterschätzen, bis er nicht mehr zu übersehen ist.

Was zählt dazu:

Code, der funktioniert, aber von niemandem mehr vollständig verstanden wird
Strukturen, die für kleinere Anforderungen entworfen wurden und jetzt unter größeren Lasten verformt werden
Stellen im System, an denen jede Änderung unvorhersehbare Folgen an ganz anderen Stellen hat
Abhängigkeiten von Technologien, die nicht mehr weiterentwickelt werden

Keines dieser Beispiele ist ein Fehler im eigentlichen Sinne. Alle können, wenn sie lange genug aufgeschoben werden, am Ende teurer werden als eine komplette Neuentwicklung — und das ist keine Übertreibung, sondern das, was Budgetgespräche in reifen Softwareprojekten regelmäßig zeigen.

Wie Schulden entstehen, ohne dass jemand einen Fehler macht

Die meisten technischen Schulden entstehen nicht durch Nachlässigkeit. Sie entstehen durch Entscheidungen, die zum Zeitpunkt, als sie getroffen wurden, vollkommen vernünftig waren.

Ein Unternehmen braucht Ende Oktober eine Lösung. Die Entwickler liefern sie. Sechs Monate später wächst das Unternehmen, die Anforderungen verschieben sich — und dieselbe Lösung, die damals funktioniert hat, kostet jetzt Aufwand bei jeder Änderung. Nicht weil sie schlecht gebaut war. Sondern weil sie für eine andere Situation gebaut wurde.

Drei Muster, die sich wiederholen

Das erste Muster ist Wachstum. Ein System, das für zwanzig Mitarbeiterinnen und Mitarbeiter entworfen wurde, läuft bei zweihundert anders. Die Annahmen von damals — wer was wie oft aufruft, welche Datenmenge anfällt, wer die Ausnahme ist und wer die Regel — stimmen nicht mehr. Das System selbst hat sich nicht verändert. Die Umgebung schon.

Das zweite Muster ist eine Entscheidung unter Unsicherheit. Zu Projektbeginn weiß niemand genau, wohin das Produkt führt. Man baut für das, was man versteht. Was man nicht versteht, wird ausgespart oder vereinfacht. Das ist keine Schwäche — es ist die einzige ehrliche Möglichkeit, mit unvollständigen Informationen zu arbeiten. Aber die vereinfachten Stellen muss man später anpassen, wenn die Realität klarer geworden ist. Das geschieht seltener, als es sollte.

Das dritte Muster ist ein Wechsel in der Verantwortung. Die Person, die eine Abkürzung eingebaut hat, kannte deren Grund. Sie ist nicht mehr im Unternehmen. Was bleibt, ist das Ergebnis ohne den Kontext. Nachfolgende Teams bauen weiter — ohne zu wissen, was sie besser nicht anfassen sollten und warum. Aus einer bewussten Entscheidung von damals wird eine unsichtbare Einschränkung von heute.

In allen drei Fällen hat niemand einen Fehler gemacht. Die Schulden sind trotzdem da.

Die Frage, die hilft

Wer technische Schulden für das Ergebnis schlechter Arbeit hält, sucht nach dem Schuldigen. Das lenkt ab. Die nützlichere Frage lautet: Wo hat sich unsere Situation seit dem letzten größeren Umbau verändert — und hat die Software mitgehalten?

Oft lautet die Antwort: teilweise. Das System funktioniert. Aber es kostet mehr, als es sollte — an Zeit, an Abstimmungsaufwand, an kleinen Umwegen, die sich als selbstverständlich eingeschlichen haben. Diese Kosten erscheinen in keiner Zeile der Buchhaltung. Sie zeigen sich darin, dass eine Änderung, die einfach klingen sollte, drei Wochen dauert. Oder darin, dass niemand mehr genau erklären kann, warum etwas so gebaut ist, wie es ist.

Das ist kein Versagen. Es ist der normale Verlauf eines Systems, das in einer sich verändernden Umgebung betrieben wird — ohne dass jemand regelmäßig nachfragt, ob die ursprünglichen Annahmen noch stimmen.

Wann Schulden zum Problem werden: die Kipppunkte

Technische Schulden machen sich selten mit einer Fehlermeldung bemerkbar. Meistens kündigen sie sich durch ein Gespräch an — eines, das sich mit der Zeit wiederholt. „Das dauert länger als gedacht." Drei Monate später dasselbe. Dann wieder. Wer dieses Gespräch kennt, hat vermutlich bereits einen Kipppunkt hinter sich.

Wenn jede Änderung eine neue Baustelle öffnet

Das erste Muster ist das Folgeschaden-Muster: Eine Anpassung löst etwas aus, das niemand vorhergesehen hat. Der Kalender wird geändert, plötzlich stimmt die Rechnungsstellung nicht mehr. Eine Filterlogik wird angepasst, eine andere Ansicht zeigt falsche Zahlen. Nicht weil jemand unaufmerksam war — sondern weil die einzelnen Teile der Anwendung über die Jahre so eng miteinander verwoben wurden, dass ein Zug an einer Stelle die ganze Konstruktion bewegt. Wer das System von innen kennt, weiß das. Wer es nicht kennt, lernt es bei der nächsten Änderung.

Wenn der Aufwand nicht mehr zur Aufgabe passt

Ein zweites Muster zeigt sich an der Entkopplung von Aufwand und Ergebnis. Kleine Änderungen, die inhaltlich trivial sind, kosten Wochen. Die Erklärung lautet dann sinngemäß: Das sei eigentlich eine Kleinigkeit, aber sie sitze tief und man müsse aufpassen, was sonst noch daran hängt.

Für ein Unternehmen, das auf eine veränderte Marktlage reagieren muss — auf eine neue Anforderung, einen neuen Wettbewerber, eine geänderte Rechtslage — ist das kein internes Problem. Es ist ein Problem des Handlungsspielraums. Wer nicht reagieren kann, wenn er müsste, verliert nicht an einem Fehler. Er verliert an Langsamkeit.

Wenn das Wissen aufhört, sich zu verteilen

Das stillste Muster ist das des gebundenen Wissens. Das System läuft — aber immer weniger Menschen verstehen, warum es läuft. Es gibt eine Person, manchmal zwei, die die Zusammenhänge noch überblicken. Solange sie da sind, funktioniert alles. Was passiert, wenn sie gehen, ist eine Frage, über die im Alltag selten gesprochen wird.

In kleineren Betrieben zeigt sich dieser Kipppunkt oft erst, wenn er bereits eingetreten ist: Die Entwicklerin wechselt, ihr Nachfolger braucht ein halbes Jahr, um überhaupt zu verstehen, was läuft — und womit er es nicht kaputt machen darf. Ein halbes Jahr, in dem nichts weitergebaut wird.

Wenn eine externe Anforderung Druck erzeugt

Besonders deutlich wird der Kipppunkt, wenn von außen eine Frist entsteht: eine Gesetzesänderung, ein geändertes Partnerformat, eine neue Datenschutzpflicht. Das System muss angepasst werden — aber es lässt sich nicht schnell anpassen. Die Frist ist trotzdem da.

In diesen Momenten wird aus einem latenten Problem ein sichtbares. Was jahrelang still mitgelaufen ist, bestimmt plötzlich, was ein Unternehmen tun kann — und was nicht. Das ist oft der Moment, in dem eine größere Investition nicht mehr aufgeschoben werden kann: nicht weil jemand es so entschieden hat, sondern weil der Zeitpunkt für eine ruhige Entscheidung längst verstrichen ist.

Was eine Migration wirklich kostet — und warum die erste Schätzung fast immer zu niedrig ist

Wer ein altes System ablösen will, fragt zuerst: Was kostet das neue? Das ist die falsche Frage. Die richtige lautet: Was kostet der Wechsel — und wie lange dauert er, bis das Unternehmen wieder so arbeitet wie vorher?

Die erste Schätzung erfasst fast nie beides. Sie erfasst die Entwicklungszeit für das neue System. Sie erfasst selten, dass das alte System währenddessen weiterlaufen muss. Und sie erfasst so gut wie nie die Zeit, die Menschen in der Firma brauchen, um sich umzugewöhnen — nicht weil sie es nicht wollen, sondern weil der Alltag weitergeht, während der Umstieg läuft.

Was in Schätzungen fehlt

Parallelbetrieb. Für Wochen oder Monate laufen beide Systeme gleichzeitig. Daten müssen doppelt gepflegt werden. Das kostet Arbeitszeit, jeden Tag.
Datentransfer. Bestehende Daten sind selten so strukturiert, wie das neue System sie erwartet. Was nach einem technischen Schritt klingt, ist oft wochenlange Handarbeit — und manchmal stellt sich heraus, dass ein Teil der alten Daten schlicht unvollständig oder widersprüchlich ist.
Ausnahmen und Sonderfälle. Jedes Unternehmen hat Abläufe, die irgendwann einmal so entstanden sind und die niemand mehr erklären kann — die aber trotzdem täglich gebraucht werden. Diese Fälle tauchen nicht im Lastenheft auf. Sie tauchen auf, wenn das neue System sie nicht abbildet.
Einarbeitungszeit. Menschen, die seit Jahren mit einem System arbeiten, müssen neue Wege für dieselben Aufgaben finden. Das verlangsamt zunächst. Wie lange, hängt davon ab, wie nah das neue System an den tatsächlichen Abläufen gebaut ist.

Das ist keine Kritik an Entwicklern oder an Schätzungen als solchen. Es ist ein strukturelles Problem: Zum Zeitpunkt der ersten Schätzung sind die Ausnahmen noch nicht bekannt. Sie werden erst bekannt, wenn man anfängt.

Der Punkt, an dem es kein Zurück gibt

Irgendwann in jeder Migration gibt es einen Moment, in dem das alte System abgeschaltet werden könnte — aber noch nicht muss. Das ist der teuerste Moment, weil die Entscheidung unter Druck getroffen wird: Der Parallelbetrieb kostet weiter, das Team ist erschöpft vom Doppelaufwand, und das neue System funktioniert gut genug, aber eben noch nicht vollständig.

Wer diesen Moment unterschätzt, trifft die Entscheidung zu früh. Dann zeigen sich die verbleibenden Lücken im laufenden Betrieb — und das ist teurer, als wenn man sie vorher gefunden hätte.

Migrationen sind nicht nur ein technisches Projekt. Sie sind ein Betriebsunterbrechungsprojekt mit einer technischen Komponente. Wer sie nur als Letzteres plant, wird von Ersterem überrascht.

Was Software nicht löst: die Grenze zwischen Code und Prozess

Es gibt einen Moment in fast jedem Softwareprojekt, der sich erst im Nachhinein deutlich zeigt: wenn klar wird, dass das Problem kein technisches war.

Die Anfragen stapelten sich in einem gemeinsamen E-Mail-Postfach, niemand wusste genau, wer wofür zuständig war, und manche Interessenten warteten tagelang auf eine Antwort. Die Lösung schien offensichtlich: ein neues System, eine zentrale Übersicht, klare Zuständigkeiten abgebildet in Software.

Das System wurde eingeführt. Die Anfragen kommen seither dort an. Aber wer antwortet, und wann, und in welchem Ton — das hat die Software nicht geändert. Die Verantwortungslücke, die vorher im Postfach lag, liegt jetzt im System.

Software verwaltet, was vorhanden ist. Sie kann nicht entscheiden, was vorhanden sein soll.

Wenn ein Unternehmen nicht klar geregelt hat, welche Abteilung für welchen Kunden zuständig ist, bildet jede Software diese Unklarheit ab — schneller und in größerem Maßstab. Ein gut gepflegtes System zeigt dieselben Lücken wie ein schlecht gepflegtes, nur sauberer sortiert.

Drei Grenzfälle aus der Praxis

Ein Maklerunternehmen führt eine neue Verwaltungssoftware ein. Die Frage, wer beim Eingang einer Anfrage zuerst reagiert — das Büro oder der zuständige Makler — ist weiterhin ungeklärt. Das System zeigt die Anfrage beiden. Beide warten auf den anderen.
Eine Hausverwaltung digitalisiert ihren Mieterwechselprozess: Übergabeprotokolle, Kautionsabwicklung, Schlüsselübergabe. Drei Monate später stellt sich heraus, dass die Mitarbeiterinnen die alten Abläufe weiterführen und die Software parallel befüllen — weil niemand geregelt hat, was jetzt das verbindliche Dokument ist.
Ein kleines Dienstleistungsunternehmen kauft eine Buchhaltungssoftware, weil die Steuerberaterin auf korrekte Monatsabschlüsse besteht. Was sich ändert: die Form der Übergabe. Was sich nicht ändert: dass Belege regelmäßig zu spät eingehen, weil keine Routine existiert, sie zeitnah zu erfassen.

In allen drei Fällen ist das Werkzeug nicht das Problem. Das Problem ist eine Entscheidung, die vor der Einführung des Werkzeugs hätte getroffen werden müssen.

Das ist kein Vorwurf. Prozesse sind schwieriger zu klären als Software zu beschaffen. Ein Gespräch darüber, wer künftig für was verantwortlich ist, erzeugt Konflikte, die ein System nicht erzeugt — das System hat keine Meinung. Deshalb ist die Versuchung groß, das eine durch das andere zu ersetzen.

Technische Schulden entstehen deshalb nicht nur dort, wo schlechter Code steht. Sie entstehen auch dort, wo Software Entscheidungen übernehmen soll, die Menschen treffen müssten. Solche Schulden sind teurer als die meisten — weil sie in keiner technischen Prüfung auftauchen und weil das System, das sie verdeckt, weiterhin als Erfolg gilt.