Technische Schulden

Tue, 31 Mar 2026 00:00:00 +0100

Einleitung
#

Jeder Entwickler kennt die Situation: Die Deadline rückt näher, der Chef sitzt einem im Nacken, der Kunde nörgelt, weil er auf sein Feature warten muss und die schöne, saubere Lösung würde zu lange dauern. Die scheinbar logische Konsequenz: Man macht es schnell und unsauber (engl. quick and dirty). Im “besten” Fall hinterlässt man noch einen TODO-Kommentar und verschiebt das saubere Lösen auf einen anderen Tag.

Das ist der Moment, wo technische Schulden entstehen und sie entstehen in nahezu jedem Projekt. Das perfide an ihnen, sie sind oft stille Begleiter, sie wachsen im Hintergrund, bis sie zu einem realen Problem werden.

Im folgenden Artikel möchte ich untersuchen, wie genau sie entstehen, woran man sie erkennt und vielleicht am wichtigsten, wie man sie kontrolliert.

Was sind technische Schulden
#

Der Begriff wurde von Ward Cunningham geprägt, einem der Mitautoren des Agilen Manifests. Die Analogie, die er gewählt hat, ist bis heute treffend: Technische Schulden funktionieren wie ein Kredit. Technische Schulden sind die Kosten, die entstehen, wenn ein Entwickler eine schnelle Lösung einer sauberen vorzieht.

Wer heute einen Kredit aufnimmt, bekommt sofort Geld, zahlt jedoch morgen mehr zurück, da Zinsen oben drauf kommen. Genauso liefert man mit einer unsauberen Lösung heute schnell ein Feature, erkauft sich damit aber zukünftigen Mehraufwand. Code wird schwerer verständlich, Änderungen riskanter oder fast unmöglich und neue Features dauern länger, weil man sich erst ganz vorsichtig durch alten, fragilen Code kämpfen muss. Das ist im Falle der technischen Schulden das Equivalent zu den Zinsen bei einem Kredit.

Was man hier allerdings nicht vergessen darf: Technische Schulden sind nicht automatisch ein Fehler, denn manchmal ist es eine bewusste, rationale Entscheidung – quasi ein Kompromiss, den man eingeht, weil der Markt nicht wartet oder die Produktion still steht.

Es wird erst zum Problem, wenn die Schulden nicht oder zu spät zurückgezahlt werden.

Wie werden sie verursacht
#

Im Folgenden möchte ich einige der häufigsten Ursachen für technische Schulden beschreiben. Ich erhebe kein Anspruch auf Vollständigkeit, aber es sind die aus meiner Sicht wichtigsten und gefährlichsten.

Zeitlicher Druck
#

Jeder Entwickler kennt das: Chef, Kunde oder externe Deadlines zwingen dazu, Abstriche bei der Codequalität zu machen. Features müssen halbfertig veröffentlicht werden, Dokumentation wird gestrichen und Tests – um die kümmert man sich später. Zeitlicher Druck ist wohl die häufigste Ursache für technische Schulden und gleichzeitig die am schwersten zu vermeidende.

Mangel an Bewusstsein für die Konsequenzen
#

Manchmal entstehen technische Schulden schlicht, weil sich niemand bewusst ist, welche Langzeitfolgen eine schnelle Entscheidung haben kann. Ein Entwickler löst ein Problem pragmatisch, ohne zu ahnen, dass genau diese Stelle in sechs Monaten das Herzstück eines neuen Features sein wird. Fehlende Erfahrung oder mangelndes Systemverständnis spielen hier oft eine Rolle.

Mangel an Tests
#

Ohne automatisierte Tests weiß niemand mit Sicherheit, ob eine Änderung am Code woanders etwas kaputt macht. Daraus ergibt sich, dass Entwickler sich nicht mehr trauen, alten Code anzufassen und er wird zur Blackbox. Technische Schulden, die durch fehlende Tests entstehen, sind sehr tückisch, weil sie kaum sichtbar sind, bis es zu spät ist.

Mangelhafte oder fehlende Dokumentation
#

Ein Sprichwort in der Softwareentwicklung besagt: Code wird viel öfter gelesen als geschrieben. Wenn niemand dokumentiert, warum eine Entscheidung so getroffen wurde, verliert sich dieses Wissen unweigerlich – spätestens wenn der ursprüngliche Entwickler das Team verlässt. Was übrig bleibt, ist Code, den niemand mehr richtig versteht und den niemand bearbeiten will.

Schlechte Kommunikation
#

Silodenken, unklare Anforderungen, zu seltene Abstimmungen oder das klassische “das hatte ich mir anders vorgestellt” sind im Arbeitsalltag fast nicht zu vermeiden. Wenn Entwickler, Designer und Product Manager nicht klar miteinander kommunizieren, entstehen Missverständnisse. Doppelt implementierte Funktionen, inkonsistente Architekturentscheidungen oder Features, die an den eigentlichen Anforderungen vorbeigehen, sind typische Folgen.

Verzögertes Refactoring
#

Refactoring ist wie Küche putzen nach dem Kochen oder Aufräumen nach einer Party: Man schiebt es vor sich her, weil es anstrengend ist und “ja auch noch später gemacht werden kann”. Doch je länger man wartet, desto verwurzelter wird schlechter Code im System und desto aufwändiger wird es, ihn zu bereinigen. Was heute vielleicht nur eine Stunde dauern würde, dauert in einem Jahr eventuell eine Woche.

Nicht Einhaltung von Entwicklungsrichtlinien
#

In den meisten Teams gibt es Coding Standards, Architekturprinzipien oder Konventionen – manchmal ungeschrieben, manchmal explizit dokumentiert. Werden diese ignoriert oder umgangen, entsteht inkonsistenter Code, der schwer zu lesen und zu warten ist. Besonders kritisch wird es, wenn neue Teammitglieder diese Abkürzungen als Standard übernehmen.

Das Fehlen von Entwicklungsrichtlinien
#

Ohne klare Entwicklungsrichtlinien entwickelt jeder Entwickler seinen eigenen Stil und das Ergebnis ist inkonsistenter Code, der schwer zu lesen und definitiv noch schwerer zu warten ist. Coding Standards, Architekturprinzipien und Konventionen sind essentiell, da sie dafür sorgen, dass sich jeder im Team im Code zurechtfindet und nicht nur derjenige, der ihn geschrieben hat.

Besonders kritisch wird es, wenn Teammitglieder diesen inkonsistenten Zustand als Normal ansehen, in ihren Alltag übernehmen und weiterführen. Es braucht Richtlinien als Korrektiv, sonst häufen sich technische Schulden still und in großer Menge an.

Unwissenheit
#

Nicht jede technische Schuld entsteht durch Faulheit oder Zeitdruck. Manchmal weiß ein Entwickler einfach nicht, dass es eine bessere Lösung gibt. Ob nun wegen fehlender Erfahrung, mangelnder Weiterbildung oder weil sich die Technologie weiterentwickelt hat, während der Code stehen blieb - es ist menschlich und doch eine mögliche Ursache für technische Schulden.

Wie erkennt man sie
#

Technische Schulden sind heimtückisch, sie schleichen sich still und heimlich ein. Oft merkt man erst, dass sie überhaupt da sind, wenn sie bereits zum echten Problem geworden sind. Es gibt allerdings einige sehr typische Warnsignale, auf die man achten sollte.

Steigende Entwicklungsgeschwindigkeit… nach unten
#

Neue Features, die früher in zwei Tagen fertig waren, brauchen plötzlich eine Woche. Das liegt nicht am schlechter werden des Teams, sondern an den Altlasten, die sie mit sich tragen. Wird das Team spürbar langsamer, ohne dass die Komplexität der Anforderungen gestiegen ist, ist das ein typisches Zeichen.

Angst vor Änderungen
#

“Fass das bloß nicht an, dann geht irgendwas kaputt”, “Hier musst du besonders vorsichtig sein, niemand weiß so genau, warum der Code überhaupt funktioniert”. Diese Sätze sind deutliche Warnsignale. Wenn Entwickler bestimmte Teile des Codes meiden wie ein Minenfeld und regelrecht Angst haben sie zu verändern, stecken dort fast immer technische Schulden dahinter.

Häufige und wiederkehrende Bugs
#

Bugs, die immer wieder auftauchen, oft an denselben Stellen, deuten stark auf strukturelle Probleme hin. Man muss die Ursachen angehen, statt die Symptome zu bekämpfen. Der eigentliche Code ist fragil oder unverständlich und kann deshalb nicht wirklich repariert werden.

Niemand versteht den Code mehr
#

Wenn ein Entwickler einen Abschnitt öffnet und erstmal zehn Minuten braucht, um zu verstehen was da passiert oder schlimmer, wenn niemand im Team mehr erklären kann, warum etwas so gebaut wurde, sind das fast sicher technische Schulden.

Einarbeitung neuer Entwickler dauert ungewöhnlich lang
#

Ein gesundes Projekt lässt sich in überschaubarer Zeit verstehen. Wenn neue Teammitglieder Wochen oder Monate brauchen, um produktiv zu werden, ist das oft ein Zeichen, dass der Code zu komplex, zu schlecht dokumentiert oder inkonsistent geworden ist.

Wie kann man sie verhindern
#

Technische Schulden vollständig zu vermeiden ist unrealistisch und wie wir gesehen haben, manchmal auch gar nicht sinnvoll. Das Ziel ist nicht null Schulden, sondern die Schulden bewusst aufnehmen und sie zeitnah und kontrolliert wieder zurückzuzahlen. Hier sind die wichtigsten Maßnahmen dafür.

Klare Entwicklungsrichtlinien etablieren
#

Ein Team braucht eine gemeinsame Basis: Coding Standards, Codeversionierung (Git), Architekturprinzipien, Konventionen für Benennung und Struktur. Das muss kein dickes Handbuch sein, aber es muss die wichtigsten Punkte enthalten, allen bekannt sein und aktiv gelebt werden.

Automatisierte Tests von Anfang an
#

Ein Testkonzept muss von Anfang existieren und Tests dürfen nicht bis zum Schluss aufgeschoben werden, denn sie sind eine Investition in die Zukunft. Wer von Beginn an testet, kann später ohne Angst refactoren, weil sofort klar wird, dass etwas bricht und wo. Der beste Zeitpunkt für Tests ist immer jetzt.

Regelmäßiges Refactoring einplanen
#

Refactoring muss zum normalen Entwicklungsalltag gehören und darf nicht auf unbestimmte Zeit verschoben werden. Kleine, regelmäßige Aufräumarbeiten verhindern, dass sich Schulden überhaupt erst gefährlich anhäufen.

Code Reviews
#

Vier Augen sehen mehr als zwei, sagt man und es ist tatsächlich so, denn man sieht seine eigenen Fehler oft nicht. Regelmäßige Code Reviews helfen dabei, schlechte Lösungen früh zu erkennen, bevor sie sich im System festsetzen. Gleichzeitig fördern sie den Wissensaustausch im Team, was ein unterschätzter Nebeneffekt ist.

Dokumentation als Teil der Arbeit verstehen
#

Dokumentation darf nicht als ein notwendiges Übel angesehen werden, sondern muss Teil der eigentlichen Arbeit sein. Wer während der Entwicklung fünf Minuten investiert um zu erklären, warum eine (schlechtere) Entscheidung so getroffen wurde, spart seinem Team in der Zukunft Zeit und Kopfzerbrechen.

Technische Schulden sichtbar machen
#

Was nicht sichtbar ist, wird nicht priorisiert oder “aus den Augen aus dem Sinn”. Technische Schulden sollten aktiv erfasst werden, sei es als Einträge im Backlog oder zum Beispiel als (TODO-) Tags im Code. Nur wenn das Team und das Management sehen, was sich angesammelt hat, können richtige Entscheidungen getroffen werden, wann und wie die Schulden zurückgezahlt werden.

Zeitdruck bewusst managen
#

Das ist leichter gesagt als getan und dennoch extrem wichtig. Wenn Deadlines auf Kosten der Qualität gehen, muss man diese Entscheidung bewusst treffen und die Konsequenzen sollten klar sein. Wer einen Kompromiss eingeht, muss ihn dokumentieren und sicherstellen, dass die Schulden auch zeitnah bezahlt werden.

Fazit
#

Technische Schulden sind (oft) kein Zeichen von schlechtem Entwicklerhandwerk, sondern in fast jedem Softwareprojekt vertreten. Manchmal entstehen sie durch Druck von außen, manchmal durch fehlende Strukturen, manchmal schlicht durch Unwissenheit.

Gefährlich werden sie dann, wenn man sie ignoriert.

Der erste und meiner Meinung nach wichtigste Schritt ist Bewusstsein. Technische Schulden wahrnehmen, sie benennen und als das behandeln, was sie sind, eine bewusste Entscheidung mit Konsequenzen. Wer das tut, kann sie kontrollieren, aktiv abbauen und verhindern, dass sie das Projekt eines Tages lahmlegen.

Sauberer Code muss immer das Ziel sein, denn mit ihm steht und fällt der langfristige Erfolg eines Projekts.

Vorschaubild
#

freepik

Testing on Devcartes

Technische Schulden

Einleitung #

Was sind technische Schulden #

Wie werden sie verursacht #

Zeitlicher Druck #

Mangel an Bewusstsein für die Konsequenzen #

Mangel an Tests #

Mangelhafte oder fehlende Dokumentation #

Schlechte Kommunikation #

Verzögertes Refactoring #

Nicht Einhaltung von Entwicklungsrichtlinien #

Das Fehlen von Entwicklungsrichtlinien #

Unwissenheit #

Wie erkennt man sie #

Steigende Entwicklungsgeschwindigkeit… nach unten #

Angst vor Änderungen #

Häufige und wiederkehrende Bugs #

Niemand versteht den Code mehr #

Einarbeitung neuer Entwickler dauert ungewöhnlich lang #

Wie kann man sie verhindern #

Klare Entwicklungsrichtlinien etablieren #

Automatisierte Tests von Anfang an #

Regelmäßiges Refactoring einplanen #

Code Reviews #

Dokumentation als Teil der Arbeit verstehen #

Technische Schulden sichtbar machen #

Zeitdruck bewusst managen #

Fazit #

Vorschaubild #