Was technische Schulden sind
Der Abstand zwischen dem, was da ist, und dem, was nötig wäre, damit es wartbar bleibt. Kopieren statt eine Funktion zu bauen, der nie geschriebene Test, die alte Version einer Abhängigkeit, der Name, der nicht mehr sagt, was er tut. Jede Abkürzung zahlt später der, der danach kommt.
Nicht jede Schuld ist schlecht. Bewusst aufgenommene und notierte Schuld wird zurückgezahlt; die, die niemand notiert hat, entdeckt man an dem Tag, an dem etwas bricht und keiner weiß warum.
Arten technischer Schulden
Die meistzitierte Einteilung stammt von Martin Fowler und kreuzt zwei Fragen: wurde die Schuld bewusst oder unbemerkt aufgenommen, und war sie umsichtig oder leichtsinnig. Die bewusste und umsichtige ist eine notierte Abkürzung, die man zurückzahlt; die unbemerkte und leichtsinnige entsteht, wenn niemand wusste, dass es auch anders ging.
Nach ihrem Ort zeigt sie sich im Code (Duplikate, riesige Funktionen), in der Architektur (Teile, die zu stark voneinander abhängen), in fehlenden Tests, in alten Abhängigkeiten, in der Dokumentation und in der Infrastruktur, etwa dem Server, den niemand neu aufsetzen kann.
Beispiele für technische Schulden
Dieselbe Geschäftsregel an drei Stellen kopiert, an zwei geändert und an der dritten vergessen. Eine Bibliothek mit bekannter Schwachstelle, die nicht aktualisiert wird, weil das Update etwas kaputt macht. Eine Abfrage, die mit tausend Zeilen läuft und mit einer Million Sekunden braucht. Ein Passwort im Code, weil es nur ein Test war.
Und die teuerste, die man nicht sieht: ein Prozess, der ohne Hinweis scheitert und Daten halb geschrieben zurücklässt. Man baut sie ab wie jede Schuld: erst messen, dann zurückzahlen, was die meisten Zinsen kostet, und keine neue Schuld mehr aufnehmen, ohne sie zu notieren.
Warum sie mit KI schneller wachsen
Die KI schreibt viel Code in kurzer Zeit, und dieser Code kommt ohne den Kontext, warum er so ist. Vorhandenes wird dupliziert, für dasselbe entstehen verschiedene Muster, und es kommen Abhängigkeiten dazu, die niemand gewählt hat. Im Labor hatte 45% des von KI erzeugten Codes bekannte Schwachstellen, wenn keine Sicherheitsvorgaben gegeben wurden.
In der ersten Woche merkt man nichts: man merkt es, wenn etwas geändert werden muss und jede Änderung fünf Stellen berührt.
Wie man sie misst und wo man anfängt
Man misst sie mit dem Code vor sich: Duplikate, veraltete Abhängigkeiten mit bekannten Schwachstellen, fehlende Tests, ungeschützte Routen, Abfragen, die das echte Volumen nicht halten, und Stellen, an denen das System ohne Hinweis scheitert. Jede mit Beleg, nicht mit Meinung.
Und man ordnet nach dem, was es kostet, wenn es bricht, nicht nach dem, was beim Lesen stört. Wir liefern diese Liste und die Reihenfolge; die Reparatur ist eine zweite Stufe: Ihr Team setzt sie um, oder wir, wenn Sie uns damit beauftragen.