Technische Schulden werden meistens wie ein moralisches Versagen behandelt: Wer welche hat, hat unsauber gearbeitet. Das ist nicht nur falsch, es ist schädlich — weil es dazu führt, dass Abkürzungen heimlich genommen und nie ausgesprochen werden. Und eine Schuld, über die niemand spricht, wird garantiert nie zurückgezahlt.
Die Metapher aus der Finanzwelt trägt weiter, als man denkt: Es gibt Kredite, die einen Betrieb überhaupt erst ermöglichen, und es gibt Konsumschulden aus Bequemlichkeit. Beides heißt Schulden, aber nur eines davon ist eine Entscheidung.
Die vier Sorten, und nur zwei sind okay
Es hilft, zwei Achsen zu unterscheiden: War die Abkürzung absichtlich oder unabsichtlich, und war sie klug oder leichtsinnig.
Absichtlich und klug ist der Idealfall: “Wir wissen, dass diese Lösung nicht skaliert, aber wir brauchen sie in zwei Wochen und wollen erst wissen, ob überhaupt jemand das Feature nutzt.” Das ist keine Schlamperei, sondern eine korrekte betriebswirtschaftliche Abwägung. Ein perfekt gebautes Feature, das niemand braucht, ist teurer als eine schlampige Version, die die Frage beantwortet.
Unabsichtlich und klug ist der unvermeidliche Fall: Man hat es so gut gemacht, wie man es damals verstanden hat, und weiß es heute besser. Das ist kein Fehler, sondern Lernen. Jede Codebasis, die älter als ein Jahr ist, enthält davon reichlich.
Absichtlich und leichtsinnig ist der teure Fall: die Abkürzung aus Bequemlichkeit, ohne Not, ohne Notiz. “Ist schneller so” ohne den zweiten Halbsatz, wann und wie es geradegezogen wird.
Unabsichtlich und leichtsinnig ist der Fall, den man mit Lernen behebt, nicht mit Refactoring: Man wusste nicht, dass es einen besseren Weg gibt, und hat auch nicht gefragt.
Der praktische Nutzen dieser Unterscheidung: Sie ändert das Gespräch. Statt “der Code ist schlecht” — was niemanden zum Handeln bringt — sagst du “wir haben hier bewusst abgekürzt, weil X, und der Preis dafür wird jetzt fällig”.
Was Schulden wirklich kosten
Der Grund, warum technische Schulden gefährlich sind, ist nicht der hässliche Code. Es sind die Zinsen: Jede zukünftige Änderung in diesem Bereich kostet mehr Zeit als nötig.
Daraus folgt die einzig sinnvolle Priorisierungsregel: Schulden in Code, den niemand mehr anfasst, kosten dich nichts. Ein hässliches Modul, das seit zwei Jahren unverändert läuft und funktioniert, ist wirtschaftlich kein Problem — egal wie sehr es beim Lesen weh tut. Schulden in Code, den du jede Woche anfasst, kosten dich jede Woche.
Wenn du also entscheiden musst, was du aufräumst, schau nicht auf die Qualität, sondern auf die Änderungshäufigkeit. Der Versionsverlauf deines Projekts sagt dir, welche Dateien am häufigsten geändert werden. Die Schnittmenge aus “wird ständig angefasst” und “tut beim Anfassen weh” ist deine Aufräumliste. Alles andere ist Geschmacksfrage.
Ein zweiter Kostenfaktor wird oft übersehen: Schulden, die andere Entscheidungen blockieren. Eine Abkürzung, die dich daran hindert, ein Feature zu bauen, das ein Kunde bezahlen würde, ist teuer, auch wenn sie selten angefasst wird.
Sichtbar machen, sonst existiert es nicht
Der wirksamste Einzelschritt ist unspektakulär: Schreib die Schuld auf, wenn du sie aufnimmst. Nicht “TODO: aufräumen”, sondern eine Notiz, die drei Dinge festhält — was hier abgekürzt wurde, warum, und woran man merkt, dass es jetzt geradegezogen werden muss.
Der dritte Punkt ist der entscheidende und wird fast immer weggelassen. “Später aufräumen” hat keinen Auslöser und passiert deshalb nie. “Solange wir unter tausend Datensätzen bleiben, reicht das; darüber müssen wir paginieren” hat einen — und du kannst dir sogar einen Alarm darauf bauen.
In Kundenprojekten hat das noch einen zweiten Nutzen: Wenn eine Abkürzung auf Kundenwunsch entstanden ist — weil der Termin oder das Budget so war — gehört das dokumentiert und im Statusbericht erwähnt. Sonst ist es in einem Jahr deine Schlamperei und nicht die gemeinsame Entscheidung, die es war.
Wann Refactoring die falsche Antwort ist
Der Gegenimpuls zum Verdrängen ist das große Aufräumprojekt, und das ist genauso oft falsch.
Ein Umbau, der Wochen dauert und dabei kein einziges Nutzerproblem löst, ist schwer zu rechtfertigen und noch schwerer durchzuhalten — er wird typischerweise zu zwei Dritteln fertig, dann kommt etwas Dringendes dazwischen, und du hast jetzt zwei halbe Systeme statt einem ganzen schlechten. Das ist der schlechteste erreichbare Zustand.
Die Alternative ist unbefriedigend, aber sie funktioniert: Aufräumen entlang der Arbeit, die ohnehin ansteht. Wenn du ein Feature in einem verwahrlosten Modul baust, räumst du genau den Teil auf, den du anfassen musst, und lieferst beides zusammen. So wird der Code genau dort besser, wo Aktivität ist — und das ist per Definition dort, wo die Zinsen anfallen.
Und sei ehrlich mit dir selbst bei der Frage nach dem Motiv. Refactoring ist die angenehmste Form der Prokrastination, die es für Entwickler gibt: Es fühlt sich nach Arbeit an, es ist intellektuell befriedigend, und es verschiebt das unangenehme Gespräch mit dem Kunden oder die schwierige Produktentscheidung um ein paar Tage. Wenn du gerade großen Drang zum Umbau verspürst, während eine unbeantwortete Kundenmail im Postfach liegt, ist die Frage berechtigt, was du hier eigentlich vermeidest.
Der Satz, der die Diskussion ändert
Wenn du mit Nichttechnikern über technische Schulden sprichst — Kunden, Vorgesetzten, Mitgründern — funktioniert das Wort “Qualität” schlecht, weil es nach Perfektionismus klingt. Was funktioniert, ist Geschwindigkeit: “Änderungen in diesem Bereich dauern derzeit dreimal so lang wie nötig, und das wird schlimmer. Wir können das in zwei Tagen ändern.”
Damit ist die Diskussion nicht mehr moralisch, sondern eine Investitionsrechnung — und die kann dein Gegenüber führen, du auch, und ihr könnt euch am Ende sogar bewusst dagegen entscheiden. Ein “nein, das lohnt sich für uns gerade nicht” ist ein völlig akzeptables Ergebnis. Es ist immer noch unendlich viel besser als eine Schuld, die niemand kennt.
Wenn du deine eigene Liste sortieren willst und Sparring brauchst: Im Discord der Community läuft diese Diskussion in irgendeiner Form eigentlich immer.