Skip to main content

Kontakt

Was interessiert Sie?

Zurück zum Glossar (T)
Glossar · T

Technische Schuld.

Technische Schuld bezeichnet den späteren Mehraufwand, der entsteht, wenn eine Lösung bewusst oder unbewusst schnell statt tragfähig gebaut wird. Wie bei einer Finanzschuld kann die Aufnahme richtig sein — teuer wird sie erst, wenn die Zinsen in Form dauerhaft langsamerer Weiterentwicklung mitlaufen.

TEGLOSSARDLM Digital

Technische Schuld — ausführlich erklärt

Das Bild stammt von Ward Cunningham und ist bewusst finanziell gedacht. Es gibt bewusste Schuld — man entscheidet sich für die schnelle Variante, um einen Termin zu halten, und weiss, was später nachzuholen ist. Und es gibt unbewusste Schuld, die aus fehlendem Wissen, Zeitdruck oder wechselnden Verantwortlichkeiten entsteht. Betroffen sind nicht nur Codezeilen: Auch eine Datenstruktur, die den Sonderfall nicht vorsieht, eine fehlende Dokumentation, ein manueller Deployment-Schritt oder eine seit Jahren nicht aktualisierte Abhängigkeit sind Schuld, die Zinsen kostet.

Erkennbar wird sie an Symptomen, nicht an Messwerten. Änderungen, die klein klingen, dauern immer länger. Fehler kehren nach der Behebung an anderer Stelle zurück. Neue Entwickler brauchen ungewöhnlich lange, bis sie produktiv sind. Es gibt Stellen im System, an die sich niemand freiwillig setzt. Und die Antwort auf Anforderungen lautet zunehmend «geht nicht» statt «kostet so viel». Wer diese Sätze im eigenen Team hört, hat kein Motivationsproblem, sondern ein strukturelles — und sollte es als solches benennen statt als Tempoproblem.

Ein typischer Entstehungsweg: Ein Proof of Concept beweist, dass die Datenübernahme aus dem Altsystem funktioniert. Weil er läuft, wird er nicht ersetzt, sondern erweitert — Zugangsdaten fest im Code, keine Fehlerbehandlung, Annahmen, die nur für den Testdatensatz gelten. Zwei Jahre später hängt der Rechnungslauf daran, niemand kennt den Code, und jede Anpassung ist ein Risiko. Die Tilgung kostet dann ein Mehrfaches dessen, was der saubere Neubau am Anfang gekostet hätte. Das ist kein Einzelfall, sondern das häufigste Muster in gewachsenen KMU-Systemen.

Der Umgang ist eine kaufmännische Entscheidung, keine Glaubensfrage. Praktikabel ist ein fester Anteil der Kapazität — häufig etwa zehn bis zwanzig Prozent — für Tilgung: Abhängigkeiten aktuell halten, Tests für die kritischen Pfade nachziehen, manuelle Schritte automatisieren. Ebenso wichtig ist Transparenz im Angebot: Wenn eine schnelle Variante gewählt wird, gehört der spätere Aufwand schriftlich festgehalten. Und nicht jede Schuld muss getilgt werden. Für ein System, das in achtzehn Monaten ohnehin abgelöst wird, ist Weiterleben mit der Schuld die wirtschaftlich richtige Antwort.

Weiterführende Seite

Proof of Concept (PoC)

Häufige Fragen zu Technische Schuld

Nein. Bewusst aufgenommene Schuld kann richtig sein, etwa um eine Marktchance oder einen Termin zu halten oder um eine Annahme schnell zu prüfen. Problematisch ist unbewusste Schuld und der Fall, in dem die Tilgung nie eingeplant wird. Entscheidend ist, dass die Entscheidung ausgesprochen, notiert und mit einem Zeitpunkt für die Rückzahlung versehen wird.

An der Entwicklung der Aufwände: Wenn vergleichbare Änderungen über die Zeit teurer statt günstiger werden, arbeitet das Team gegen das System. Weitere Hinweise sind lange Testphasen vor jedem Release, wiederkehrende Fehler und Aussagen wie «das ist historisch gewachsen». Fragen Sie nach der Testabdeckung der kritischen Abläufe und nach dem Alter der eingesetzten Abhängigkeiten.

Als Erfahrungswert werden häufig zehn bis zwanzig Prozent der laufenden Kapazität genannt, dauerhaft und nicht als einmaliges Aufräumprojekt. Wichtiger als die genaue Zahl ist die Regelmässigkeit: Kleine, laufende Tilgung ist deutlich günstiger als ein grosses Sanierungsvorhaben, das irgendwann unvermeidlich wird und dann mit dem Tagesgeschäft kollidiert.

Bereit für Ihr Projekt?

Wenden Sie dieses Wissen auf Ihre Website an — DLM Digital hilft Ihnen dabei.