Technische Schulden erkennen, messen und abbauen

Was technische Schulden wirklich sind

Der Begriff stammt von Ward Cunningham, einem der Erfinder agiler Methoden. Seine Idee: Wenn du Code ausliefern willst, bevor du ihn vollständig verstanden hast, leihst du dir Zeit. Das ist legitim, wie ein Kredit legitim ist. Aber wie bei jedem Kredit zahlst du Zinsen, und die Zinsen heissen hier: Jede Änderung am unsauberen Code dauert länger als sie müsste.

Wichtig ist die Unterscheidung, die in der Praxis oft verschwimmt. Technische Schuld ist eine bewusste oder zumindest nachvollziehbare Verkürzung, nicht einfach schlechter Code. Eine schnell hingeworfene Funktion für einen Pilotkunden, mit der Notiz später sauber bauen, wenn wir wissen ob es trägt, ist eine Schuld. Code, der nie verstanden wurde und nie hätte so gebaut werden dürfen, ist kein Kredit, sondern ein Defekt. Beide verlangsamen dich, aber du gehst unterschiedlich mit ihnen um. Schulden tilgst du planvoll, Defekte reparierst du.

Es gibt zwei Quellen, die in jedem Produkt zusammenkommen. Die eine ist Tempo: Du hast unter Termindruck eine Abkürzung genommen. Die andere ist Erkenntnis: Du hast vor zwei Jahren etwas gebaut, das damals richtig war, und heute weisst du es besser, weil das Produkt und die Anforderungen gewachsen sind. Die zweite Sorte lässt sich nicht vermeiden. Sie entsteht automatisch, weil ein lebendiges System sich von der Architektur entfernt, die einmal für es gedacht war.

Woran du sie im Alltag merkst

Du spürst technische Schulden lange bevor du sie benennen kannst. Sie zeigen sich als Gefühl, und das Gefühl heisst: Es wird zäh.

Das erste verlässliche Signal ist die sinkende Liefergeschwindigkeit bei gleichbleibendem Team. Vor einem Jahr war eine neue Ansicht eine Sache von Tagen. Heute zieht sich dasselbe über Wochen, und niemand kann genau sagen warum. Die Antwort steckt meistens darin, dass jede Änderung an drei anderen Stellen vorsichtig nachgezogen werden muss, weil alles mit allem verwoben ist.

Das zweite Signal sind Fehler, die in Wellen zurückkommen. Du behebst einen Bug, und zwei Wochen später taucht in einem scheinbar fremden Teil der Anwendung ein neuer auf, weil beide an derselben morschen Stelle hingen. Wenn dein Team anfängt, Sätze zu sagen wie Da fasse ich lieber nichts an oder Das traut sich keiner mehr zu ändern, dann hast du eine sehr konkrete Form von Schuld vor dir: Angst-Code. Niemand versteht ihn noch ganz, also lässt man ihn in Ruhe und baut drumherum. Mit jeder Umgehung wird er teurer.

Weitere Anzeichen, die sich oft zusammen zeigen:

• Onboarding neuer Entwickler dauert auffällig lange, weil das System nur in den Köpfen weniger Leute vollständig existiert.
• Schätzungen werden unzuverlässig, weil niemand mehr vorhersagen kann, was eine Änderung auslöst.
• Einfache Anpassungen brauchen unverhältnismässig viele Tests von Hand, weil automatisierte Tests fehlen oder unzuverlässig sind.
• Das Deployment ist ein Ereignis mit Anspannung statt ein Routinevorgang.

Keines dieser Signale ist für sich ein Beweis. Zusammen ergeben sie ein Bild, und dieses Bild ist meistens ziemlich präzise.

Wie du Schulden sichtbar und messbar machst

Solange technische Schuld nur ein Bauchgefühl ist, verliert sie jede Priorisierung gegen Features, die man sehen kann. Der erste echte Schritt ist deshalb, sie aus den Köpfen aufs Papier zu holen.

Der pragmatische Anfang ist ein Schuldenregister. Eine schlichte Liste, in der jeder Eintrag drei Dinge festhält: Wo sitzt die Schuld, was kostet sie uns gerade (welche Arbeit wird dadurch langsamer oder riskanter), und was würde sie kosten, sie zu tilgen. Diese Liste lebt dort, wo auch eure Aufgaben leben, nicht in einem vergessenen Dokument. Sobald jemand beim Arbeiten auf eine Stelle stösst, an der er sich ärgert, kommt ein Eintrag dazu. So wird aus diffusem Unbehagen eine handhabbare Menge.

Darüber hinaus helfen ein paar Kennzahlen, die du ohnehin haben solltest. Ich nenne bewusst keine Zielwerte, weil die je nach Produkt stark schwanken. Worauf es ankommt, ist der Trend über die Zeit:

• Durchlaufzeit einer Änderung, von angefangen bis live. Steigt sie über Monate, ohne dass die Aufgaben grösser werden, zahlst du Zinsen.
• Fehlerrate nach Auslieferung, also wie oft eine Änderung kurz darauf nachgebessert werden muss. Eine steigende Rate deutet auf brüchiges Fundament.
• Testabdeckung in den kritischen Pfaden. Nicht als Selbstzweck, sondern als Mass dafür, wie sicher du etwas ändern kannst, ohne blind zu fliegen.

Werkzeuge zur statischen Codeanalyse können diese Sicht ergänzen und dir zeigen, wo Komplexität und Verflechtung sich ballen. Sie ersetzen aber nicht das Urteil von Leuten, die im Code arbeiten. Eine Metrik sagt dir, wo es eng aussieht. Ob es wirklich eng ist und ob es weh tut, weiss das Team.

Dieser Mess- und Betriebsblick ist kein Nebenschauplatz, sondern Kern eines belastbaren Produkt-Betriebs. Wer ein Produkt nicht nur baut, sondern selbst betreibt, sieht die Schulden im Logfile, im Pager und in der Stundenzahl pro Feature. Bei Wortfreunde und Reazon ist genau das der Grund, warum wir Schuldenabbau nicht als Sonderprojekt führen, sondern als Teil des normalen Betriebs.

Warum der grosse Rewrite fast immer die falsche Antwort ist

Irgendwann kommt in jedem belasteten System der Wunsch auf, alles neu zu schreiben. Das alte ist hässlich, das neue wird sauber, diesmal machen wir es richtig. Der Reiz ist verständlich, und genau deshalb ist er gefährlich.

Ein Rewrite hat drei strukturelle Probleme. Erstens steht das Geschäft nicht still, während du neu baust. Das alte System muss weiter gepflegt werden, du betreibst also zwei Baustellen parallel. Zweitens steckt im alten Code viel unsichtbares Wissen, all die Sonderfälle und Korrekturen, die über Jahre eingeflossen sind. Ein Neubau wirft dieses Wissen weg und entdeckt dieselben Sonderfälle mühsam noch einmal. Drittens lieferst du während des Rewrites monatelang keinen sichtbaren Wert, und das ist für Kunden wie für die eigene Geduld eine harte Strecke.

In den meisten Fällen ist kontinuierlicher Abbau im laufenden Betrieb der bessere Weg. Die bekannteste Technik dafür heisst Refactoring: Du verbesserst die innere Struktur des Codes, ohne sein Verhalten nach aussen zu ändern. Du machst das in kleinen Schritten, abgesichert durch Tests, und du machst es dort, wo du gerade ohnehin arbeitest. Eine bewährte Faustregel ist die Pfadfinder-Haltung: Hinterlasse jede Stelle, die du anfasst, ein wenig sauberer als du sie vorgefunden hast. So fliesst der Abbau in die normale Arbeit ein, statt einen eigenen Budgettopf zu brauchen, den niemand bewilligt.

Ganz grosse Altlasten zerlegst du, statt sie auf einmal zu ersetzen. Du kapselst den problematischen Teil hinter einer klaren Schnittstelle und tauschst dahinter Stück für Stück aus, während aussen alles weiterläuft. Das ist langsamer als der grosse Wurf auf dem Papier, aber es liefert die ganze Zeit über ein funktionierendes Produkt. Diese Dynamik liegt nah an dem, warum SaaS-Projekte scheitern: Sie verlieren sich in einem grossen Plan, statt in kurzen, überprüfbaren Schritten zu liefern.

Wann sich der Aufwand nicht lohnt

Nicht jede Schuld muss getilgt werden, und es wäre eine Verschwendung, so zu tun. Schuld in einem Codeteil, den du selten anfasst und nie erweiterst, kostet dich faktisch nichts. Die Zinsen fallen nur an, wenn du dort arbeitest. Liegt ein hässliches Modul ruhig in der Ecke und tut seit Jahren klaglos seinen Dienst, dann lass es liegen. Sauberkeit um ihrer selbst willen ist kein Geschäftsziel.

Es gibt auch Lagen, in denen sich neue Schuld bewusst lohnt. Wenn du eine Geschäftsidee testest und noch nicht weisst, ob sie trägt, ist schneller, unsauberer Code oft die richtige Wahl. Du willst zuerst lernen, ob das Ding überhaupt gebraucht wird, bevor du es solide baust. Diese Logik steckt auch hinter der Frage, was ein MVP kostet: Du kaufst Tempo gegen spätere Aufräumarbeit, und das ist ein vernünftiger Handel, solange du die Schuld danach auch wirklich notierst und tilgst.

Und manchmal ist der Rewrite eben doch richtig. Wenn die zugrunde liegende Technologie abgekündigt ist, wenn das System eine Grössenordnung skalieren muss, für die es nie gedacht war, oder wenn der Defektanteil so hoch ist, dass von gesundem Kern kaum noch die Rede sein kann, dann ist Weiterflicken die teurere Variante. Der Punkt ist nicht, dass Rewrites verboten sind. Der Punkt ist, dass sie die Ausnahme sein sollten und eine nüchterne Begründung brauchen, nicht nur den Wunsch nach einer sauberen Tafel.

So bleibt das Thema steuerbar

Technische Schulden verschwinden nie ganz, und das ist in Ordnung. Ein Produkt, das lebt und sich verändert, produziert laufend neue. Die Frage ist nicht, ob du Schulden hast, sondern ob du sie kennst und ob du sie unter Kontrolle hältst.

Drei Gewohnheiten halten das Thema klein. Du machst Schulden sichtbar, sobald sie entstehen, statt sie zu verschweigen. Du tilgst kontinuierlich im Kleinen, dort wo du sowieso arbeitest, statt auf den grossen Aufräumtag zu warten, der nie kommt. Und du triffst die Entscheidung, eine Schuld aufzunehmen, bewusst und dokumentiert, damit aus einem Kredit nicht stillschweigend ein Klotz wird.

Wenn du den Verdacht hast, dass dein Produkt langsamer geworden ist und nicht recht weisst warum, ist der erste Schritt selten ein Werkzeug. Es ist ein offenes Gespräch im Team darüber, wo es weh tut. Das, was dann auf der Liste steht, ist meistens überraschend konkret und überraschend gut behandelbar.