KonzeptKapitel III · Evolution · Baustein 3 von 7

Technische Schulden

Technische Schulden verschieben Aufwand oder Risiko in spätere Arbeit. Ihre „Zinsen“ zeigen sich etwa in wiederkehrendem Zusatzaufwand, manuellen Schritten oder höherer Fehlerwahrscheinlichkeit.

  1. ZinsWiederkehrender Mehraufwand der Abkürzung.
  2. TilgungEinmaliger Umbau beendet den Zins.
  3. GleichstandAb hier lohnt die Tilgung.

Einordnung

Warum das wichtig ist

Nicht jede unschöne Stelle verdient Aufwand. Ohne beobachtbare Folgen entscheidet Bauchgefühl, und wirklich teure Schulden bleiben liegen. Die Bewertung nach wiederkehrender Arbeit macht Prioritäten begründbar.

Dieser Baustein bewertet Folgekosten und Tilgung. Architektur-Erosion beschreibt Strukturabweichungen; Trade-off-Analyse vergleicht gezielte Alternativen.

Auf einen Blick · Von der Abkürzung zur Tilgung

Eine Abkürzung erzeugt Schuld an einer Stelle, deren Zins als laufende Mehrkosten anfällt, bis eine Tilgung sie beseitigt.
Shop-Beispiel · Stufen durchspielen

Zins der Abkürzung über Monate

Das Versandmodul liest Bestelltabellen direkt. Jede Änderung am Statusfeld verlangt manuelle Abstimmung und verursacht wiederkehrende Fehlerprüfungen.

So liest du das Bild

  1. Zins Kennzahl „Mehraufwand bisher“ wächst mit den „Monaten seit der Abkürzung“.
  2. Tilgung Kennzahl „Tilgung einmalig“ und der Schalter „Schuld getilgt (einmaliger Umbau)“.
  3. Gleichstand Bei 5 Monaten zeigen „Mehraufwand bisher“ und „Tilgung einmalig“ beide 30 h.
  • 18 hMehraufwand bisher
  • 30 hTilgung einmalig

Der Zins summiert sich: Nach drei Monaten sind bereits 18 Stunden Mehraufwand angefallen.

Werte illustrativ

Schiebe die Monate vor und schalte die Tilgung zu, um Zins und Tilgung zu vergleichen.

Nutzen & Grenzen

Hilft, wenn

  • Wiederkehrende Änderungen zeigen Zusatzaufwand oder Fehlerfolgen an einer konkreten technischen Stelle.
  • Zeitlich begrenzte Abweichungen profitieren von sichtbarer Folgearbeit und einem festgelegten Neubewertungszeitpunkt.

Grenzen

  • Ohne beobachtete Änderungshäufigkeit und Zusatzaufwand bleibt die Priorität Bauchgefühl; Zahlen entstehen aus echter Arbeit, nicht aus Schätzung im Voraus.
  • Ein umfassender Neuaufbau erhöht das Übergangsrisiko; gezielte Tilgung am betroffenen Änderungspfad ist oft günstiger, etwa per Strangler.
  • Schulden zu benennen beseitigt sie nicht; neue Verstöße verhindert erst eine Prüfung wie bei Architektur-Erosion.

In der Praxis

  1. Frage und Folgen benennen. Beschreibe technische Stelle, wiederkehrenden Mehraufwand oder konkretes Risiko und die betroffene Änderung. Trenne beobachtete Folgen von Vermutungen. Das Ergebnis ist ein bewertbarer Schuldeneintrag.
  2. Zeitpunkt und Wirkung abwägen. Prüfe, wann die Stelle wieder geändert wird und wie sich Aufschub auf Ziele auswirkt. Stelle Nutzen, Kosten und Alternativen gegenüber. Damit wird Tilgung nach erwarteter Belastung und nicht nach bloßer Sichtbarkeit priorisiert.
  3. Gezielt tilgen und nachmessen. Plane eine begrenzte Verbesserung mit klarer Wirkungsmessung und überprüfe die nächste vergleichbare Änderung. Aktualisiere den Eintrag anhand tatsächlicher Kosten. Das Ergebnis zeigt, ob die Maßnahme Zinsen reduziert hat.
Ausführliche Erklärung lesen

Technische Schulden sind eine zeitliche Verschiebung von Aufwand oder Risiko. „Zinsen“ bezeichnen wiederkehrende Folgen wie längere Änderungen, mehr manuelle Schritte oder höhere Fehlerwahrscheinlichkeit; „Tilgung“ ist die gezielte Verbesserung. Eine Abweichung ist relevant, wenn ihre Folge bei erwarteter weiterer Arbeit spürbar wird. Die Einordnung ergänzt die Beobachtung von Architektur-Erosion und eine fundierte Trade-off-Analyse.

Schulden entstehen bewusst, um zu lernen oder rechtzeitig zu liefern, oder unbeabsichtigt durch Veränderung. Ein nützlicher Eintrag benennt Ort, Folge, betroffene Arbeit und Prüfzeitpunkt. Priorität richtet sich nach Eintritt und Wirkung; ästhetische Präferenzen allein begründen keine Tilgung. Gezielt gekoppelte Tilgung kann weniger Risiko erzeugen als ein großer Neuaufbau. Messwerte aus wiederkehrenden Änderungen helfen, die angenommene Belastung zu bestätigen oder neu zu bewerten.

Selbst prüfen

Teste dich in drei Stufen

  1. AblesenIm Bild nachsehen

    Wie hoch ist der Mehraufwand bisher nach 3 Monaten, und was kostet die Tilgung?

    Lösung mit Begründung ansehen

    18 Stunden Mehraufwand bisher; die Tilgung kostet einmalig 30 Stunden (illustrativ).

  2. AnwendenAuf eine neue Lage übertragen

    Das Versandmodul liest Bestelltabellen direkt und kostet 6 Stunden im Monat. Wann ist die Tilgung über den Bestellvertrag wirtschaftlich?

    Lösung mit Begründung ansehen

    Ab Monat 5: Dort ist der Mehraufwand bisher gleich der Tilgung mit 30 Stunden. Danach lohnt sie sich zunehmend.

  3. BewertenEine Alternative abwägen

    Das Team verschiebt die Tilgung auf später. Was spricht dafür, was dagegen, was empfiehlst du?

    Lösung mit Begründung ansehen

    Vorteil: kein Umbauaufwand jetzt, Kapazität für Neues. Nachteil: Der Zins wächst weiter um 6 Stunden pro Monat. Empfehlung: Tilgung mit Prüftermin einplanen, spätestens um Monat 5.

Vertiefen

Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.

Software Analytics

Software Analytics nutzt Daten aus Code und Entwicklung, um konkrete Fragen zum Systemverhalten und zur Änderungsarbeit zu untersuchen. Der Ablauf führt von der Frage über passende Softwaredaten und eine prüfbare Hypothese zur Untersuchung und begründeten Maßnahme. Änderungshäufigkeit, Komplexität und gemeinsame Änderungen können Hotspots oder Kopplungsverdacht anzeigen. Diese Indikatoren belegen weder Ursache noch individuelle Leistung.

Im Shop fragt das Team, warum Bestelländerungen oft Katalog- und Zahlungsmodul berühren. Es vergleicht Änderungshistorie und Komplexität, prüft repräsentative Commits samt fachlichem Kontext und entscheidet danach über eine gezielte Tilgung oder weitere Beobachtung. So richtet sich die Maßnahme nach geprüften Folgen.

Zum AusprobierenFrage, Daten und Befund verbinden. Untersuche im Shop, warum Änderungen am Bestellmodul mehrere Bereiche berühren. Vergleiche Änderungshäufigkeit und Komplexität, prüfe gemeinsame Commits samt fachlichem Kontext und formuliere danach eine Hypothese mit passender Tilgung oder weiterer Messung. Behandle Kennzahlen als Hinweise, nicht als Ursachen- oder Leistungsnachweis.

Weiter im Lernpfad

Als Nächstes in Evolution & Bewertung: Architektur-Erosion.