Was sind technische Schulden?
Technische Schulden sind der Mehraufwand, der bei jeder künftigen Änderung an einer Software anfällt, weil früher eine schnelle statt einer sauberen Lösung gewählt wurde. Sie entstehen durch Abkürzungen im Code, in der Architektur, bei Tests oder im Betrieb und wachsen, solange niemand sie zurückzahlt.
Der Begriff stammt von Ward Cunningham, der ihn 1992 als Vergleich mit einem Kredit eingeführt hat. Eine schnelle Lösung ist wie geliehenes Geld: Sie kommen früher ans Ziel. Dafür zahlen Sie Zinsen, und zwar in Form von zusätzlicher Arbeit bei jeder Änderung, die den betroffenen Teil der Software berührt. Die Tilgung ist die Überarbeitung, mit der dieser Mehraufwand wieder verschwindet.
Der Vergleich hat eine Stärke: Er macht deutlich, dass Schulden nicht grundsätzlich schlecht sind. Ein Kredit kann sinnvoll sein, wenn ein Termin wichtiger ist als die Form der Lösung. Zum Problem wird die technische Schuld erst, wenn niemand sie kennt, niemand sie zurückzahlt und die Zinsen einen wachsenden Teil der Entwicklungszeit binden.
Arten technischer Schulden
Bewusst oder unbewusst
Bewusste Schulden nimmt ein Team mit offenen Augen auf: Die Messe steht an, die Funktion muss fertig sein, die saubere Lösung folgt später. Das ist vertretbar, wenn die Entscheidung festgehalten wird und ein Termin für die Rückzahlung existiert. Unbewusste Schulden entstehen ohne Entscheidung. Das Team kannte den besseren Weg nicht, die Anforderungen haben sich geändert, oder eine Bibliothek ist über die Jahre veraltet. Diese Schulden sind schwerer zu steuern, weil sie in keiner Liste stehen.
Wo sie entstehen
- Code
Kopierte Logik, sehr lange Funktionen, unklare Namen. Jede Änderung muss an mehreren Stellen nachgezogen werden.
- Architektur
Module, die eng miteinander verflochten sind. Eine Änderung im Bestellwesen wirkt sich unerwartet auf die Abrechnung aus.
- Tests
Fehlende oder unzuverlässige automatische Tests. Ob eine Änderung etwas beschädigt, zeigt sich erst im Betrieb.
- Abhängigkeiten
Frameworks, Bibliotheken und Laufzeitumgebungen, die mehrere Hauptversionen zurückliegen oder vom Hersteller nicht mehr gepflegt werden.
- Dokumentation
Entscheidungen und Zusammenhänge sind nirgends festgehalten. Neue Kolleginnen und Kollegen brauchen lange, bis sie produktiv arbeiten.
- Infrastruktur
Von Hand eingerichtete Server, manuelle Auslieferung, fehlende Überwachung. Der Betrieb hängt an Handgriffen, die nur wenige kennen.
Woran Sie technische Schulden im Alltag erkennen
Sie müssen keinen Code lesen, um technische Schulden zu bemerken. Die Anzeichen zeigen sich in der täglichen Zusammenarbeit mit der Entwicklung.
- Änderungen dauern länger als früher. Vergleichbare Anforderungen brauchen heute spürbar mehr Zeit als vor zwei Jahren, obwohl das Team nicht kleiner geworden ist.
- Releases machen Sorgen. Auslieferungen werden aufgeschoben, gebündelt und auf Randzeiten gelegt, weil nach jedem Release mit Fehlern gerechnet wird.
- Wissen liegt bei einzelnen Personen. Bestimmte Teile der Software fasst nur eine Person an. Ist sie im Urlaub, bleibt die Aufgabe liegen.
- Versionen sind veraltet. Framework, Datenbank oder Betriebssystem erhalten vom Hersteller keine Sicherheitsupdates mehr.
- Schätzungen gehen regelmäßig daneben. Aufgaben, die einfach aussahen, ziehen unerwartete Nacharbeiten an anderer Stelle nach sich.
Ein einzelnes Anzeichen ist kein Beweis. Treten mehrere gleichzeitig auf, haben Sie es in der Regel mit Legacy-Software zu tun, deren Schulden über Jahre gewachsen sind.
Wie Sie technische Schulden messbar machen
Technische Schulden lassen sich nicht in einer einzigen Zahl ausdrücken. Sie können aber Kennzahlen erheben, die zusammen ein belastbares Bild ergeben. Wichtig ist der Verlauf über die Zeit im eigenen System, nicht der Vergleich mit einem allgemeinen Richtwert.
- Durchlaufzeit von Änderungen
Zeit vom Beginn der Arbeit bis zur Auslieferung an die Nutzer. Steigt sie bei gleich großen Aufgaben, wachsen die Zinsen.
- Fehlerquote nach Releases
Anteil der Auslieferungen, die einen Fehler im Betrieb, eine Rücknahme oder eine Sofortkorrektur nach sich ziehen.
- Testabdeckung
Anteil des Codes, den automatische Tests durchlaufen. Aussagekräftig ist die Abdeckung in den geschäftskritischen Teilen, nicht der Gesamtwert.
- Veraltete Abhängigkeiten
Zahl der Bibliotheken mit bekannten Sicherheitslücken oder ohne Herstellerunterstützung. Gängige Paketverwaltungen liefern diese Liste automatisch.
- Statische Analyse
Werkzeuge prüfen den Code auf Komplexität, Dopplungen und Regelverstöße. Die Ergebnisse zeigen, wo sich Probleme häufen.
Besonders hilfreich ist die Kombination zweier Sichten: Welche Dateien sind schwer verständlich, und welche werden häufig geändert? Schulden in einem Modul, das seit Jahren niemand anfasst, kosten kaum Zinsen. Schulden in einem Modul, das jede Woche geändert wird, kosten sie ständig. Dort lohnt sich der Abbau zuerst.
Was Untätigkeit kostet
Die Kosten technischer Schulden stehen auf keiner Rechnung. Sie zeigen sich an anderer Stelle:
- Geschwindigkeit: Neue Funktionen kommen später auf den Markt, weil ein Teil der Arbeitszeit in Umwege fließt.
- Sicherheit: Für Komponenten ohne Support gibt es keine Korrekturen mehr, wenn eine Lücke bekannt wird.
- Ausfälle: Fehler nach Auslieferungen stören den Betrieb und binden die Entwicklung mit Sofortmaßnahmen.
- Personal: Entwickler arbeiten ungern dauerhaft in einem schwer wartbaren System. Geht die Person mit dem Wissen, steigt das Risiko sprunghaft.
- Handlungsspielraum: Je länger Sie warten, desto weniger Optionen bleiben. Aus einem planbaren Umbau wird irgendwann ein Ersatz unter Zeitdruck.
Technische Schulden abbauen: fünf Strategien
Die Strategien bauen aufeinander auf. Beginnen Sie mit der kleinsten, die Ihr Problem löst.
1. Laufend mitnehmen
Wer eine Stelle im Code ohnehin ändert, räumt sie dabei ein Stück auf. Das kostet wenig und verbessert genau die Teile, an denen tatsächlich gearbeitet wird. Für große strukturelle Probleme reicht es nicht.
2. Fester Anteil je Sprint
Das Team reserviert in jedem Sprint einen festen Teil seiner Kapazität für den Abbau. Wie groß dieser Anteil ist, hängt von Ihrem System ab. Entscheidend ist, dass er verlässlich eingeplant und nicht bei jedem Termindruck gestrichen wird.
3. Gezieltes Refactoring
Ein klar abgegrenzter Bereich wird in einem eigenen Vorhaben überarbeitet, zum Beispiel das Modul mit den meisten Fehlern. Voraussetzung sind Tests, die das bisherige Verhalten absichern. Fehlen sie, entstehen sie zuerst.
4. Strangler-Ansatz
Das alte System wird schrittweise ersetzt. Neue Funktionen entstehen in einer neuen Anwendung, bestehende Funktionen wandern Stück für Stück hinüber, bis das Altsystem abgeschaltet werden kann. Der Betrieb läuft währenddessen weiter. So gehen wir auch bei einer Softwaremodernisierung in der Regel vor.
5. Neuentwicklung als letzter Schritt
Eine vollständige Neuentwicklung ist die teuerste und riskanteste Variante. Sie ist gerechtfertigt, wenn die technische Grundlage nicht mehr tragfähig ist, etwa weil die Plattform nicht mehr unterstützt wird. Ob der neue Ansatz trägt, lässt sich vorab mit einem Proof of Concept an einem kleinen, kritischen Ausschnitt prüfen.
Wie Sie es der Geschäftsführung erklären
„Wir müssen refactoren“ überzeugt niemanden, der ein Budget freigeben soll. Übersetzen Sie technische Schulden in Folgen für das Geschäft.
- Nennen Sie die Auswirkung, nicht die Ursache. Statt „Der Code ist unsauber“: „Eine Preisänderung im Portal dauert heute mehrere Wochen und bindet zwei Entwickler.“
- Zeigen Sie den Verlauf. Eigene Kennzahlen über mehrere Quartale belegen, ob es besser oder schlechter wird.
- Benennen Sie das Risiko. Was passiert, wenn die Datenbankversion keine Sicherheitsupdates mehr bekommt oder der einzige Kenner des Systems kündigt?
- Legen Sie Optionen vor. Zwei oder drei Wege mit Aufwand, Dauer und Wirkung. Dazu gehört auch die Option, nichts zu tun, mit ihren Folgen.
Technische Schulden sind eine Frage der Priorität, nicht der Schuld. Wer sie sichtbar macht, kann über sie entscheiden.
Wann ein externes Audit sinnvoll ist
Das eigene Team kennt das System am besten. Trotzdem gibt es Situationen, in denen ein Blick von außen hilft:
- Vor einer größeren Investition, wenn zwischen Modernisierung und Neuentwicklung entschieden werden muss.
- Wenn Geschäftsführung und Entwicklung den Zustand der Software unterschiedlich einschätzen.
- Wenn das System von einem Dienstleister oder einem früheren Team stammt und die Dokumentation fehlt.
- Bei Unternehmenskauf, Nachfolge oder Finanzierungsrunde, wenn eine technische Bewertung verlangt wird.
- Wenn dem Team im Tagesgeschäft die Zeit für eine systematische Bestandsaufnahme fehlt.
Ein Audit ersetzt nicht den Abbau. Es liefert die Grundlage dafür: eine priorisierte Liste der Risiken, ein Zielbild und einen Plan mit Aufwandsrahmen.
Häufige Fragen
Sind technische Schulden immer schlecht?
Nein. Eine bewusst gewählte Abkürzung kann richtig sein, wenn ein Termin es verlangt. Sie muss festgehalten und später zurückgezahlt werden.
Kann man technische Schulden vollständig abbauen?
Nein, und das ist auch kein sinnvolles Ziel. Software, die weiterentwickelt wird, baut laufend neue Schulden auf. Ziel ist ein Niveau, bei dem Änderungen planbar bleiben.
Was ist der Unterschied zwischen technischen Schulden und Legacy-Software?
Legacy-Software ist ein altes System, das weiter betrieben wird. Technische Schulden sind der Mehraufwand, der in einem System steckt. Legacy-Software hat fast immer hohe Schulden, aber auch ein junges System kann welche haben.
Wer ist für den Abbau verantwortlich?
Die Entwicklung erkennt und behebt die Schulden. Die Entscheidung über Zeit und Budget liegt bei der Geschäftsführung oder der Produktverantwortung. Ohne diese Entscheidung bleibt der Abbau liegen.
Wie lange dauert der Abbau?
Das hängt von Größe und Zustand des Systems ab. Erste Verbesserungen an häufig geänderten Stellen sind oft nach wenigen Sprints spürbar. Eine schrittweise Ablösung eines Altsystems ist ein Vorhaben über viele Monate.
Nächster Schritt
Onveda entwickelt seit 2010 in Langenfeld Software für den Mittelstand. Wenn Sie wissen möchten, wie es um Ihr System steht, prüfen wir in einem Software-Audit in zwei Wochen Architektur, Sicherheit und Wartbarkeit, zum Festpreis von 3.000 bis 6.000 € netto. Sie erhalten eine priorisierte Liste der Risiken, einen 90-Tage-Plan und einen Budgetrahmen. Wenn Sie zuerst über Ihre Situation sprechen möchten, vereinbaren Sie ein Gespräch.
