Technische Schulden

Technische Schulden sind eine Metapher für zukünftige Kosten, die entstehen, wenn zweckmäßige kurzfristige Design- oder Implementierungsentscheidungen gegenüber solideren, aber langsameren bevorzugt werden, ähnlich wie finanzielle Schulden Zinsen verursachen.

Definition

Technische Schulden sind die impliziten zukünftigen Kosten zusätzlicher Nacharbeiten, die dadurch entstehen, dass man sich jetzt für eine einfache oder begrenzte Lösung entscheidet, anstatt für einen besseren Ansatz, der länger dauern würde, wobei der fortlaufende Mehraufwand, um die Abkürzung zu umgehen, die Zinsen für diese Schulden darstellt.

Scope

Dieses Thema behandelt die Ursprünge und Definition der Metapher der technischen Schulden; die Unterscheidung zwischen absichtlichen und unbeabsichtigten sowie umsichtigen und rücksichtslosen Schulden; die Anwendung der Begriffe Kapital und Zinsen auf Software; Methoden zur Identifizierung, Messung und Priorisierung von Schulden; und Strategien zur Verwaltung und Rückzahlung dieser Schulden innerhalb eines Entwicklungsprozesses.

Core questions

• Was zählt als technische Schuld und wie unterscheidet sie sich von gewöhnlichen Mängeln?
• Wann ist die Aufnahme von Schulden ein umsichtiger Kompromiss und keine Nachlässigkeit?
• Wie können technische Schulden identifiziert, gemessen und priorisiert werden?
• Welche Strategien zahlen Schulden zurück, ohne die Bereitstellung von Funktionen zu stoppen?

Key theories

Die Schuldenmetapher

Cunningham fasste zweckmäßige Designentscheidungen als Kreditaufnahme für die Zukunft auf: Sie beschleunigen die Lieferung jetzt, verursachen aber Zinsen in Form von zusätzlichem Aufwand bei jeder nachfolgenden Änderung, bis die Schulden durch Refactoring zurückgezahlt sind.

Absichtliche versus unbeabsichtigte Schulden

Technische Schulden werden nach den Achsen Absicht und Umsicht kategorisiert; absichtliche, umsichtige Schulden sind eine bewusste strategische Abwägung, während unbeabsichtigte oder rücksichtslose Schulden aus mangelnder Fähigkeit oder Disziplin entstehen und gefährlicher sind.

Clinical relevance

Unkontrollierte technische Schulden verlangsamen die Entwicklung, erhöhen die Fehlerraten und können letztendlich eine Codebasis lähmen; die Sichtbarmachung und bewusste Verwaltung von Schulden ermöglicht es Teams, kurzfristige Geschwindigkeit gegen langfristige Wartbarkeit mit offenen Augen abzuwägen.

Evidence & guidelines

Forschungsinitiativen und -werkzeuge, einschließlich SQALE-basierter Schuldenmessung und statischer Analyseplattformen, bieten Methoden zur Quantifizierung und Verfolgung technischer Schulden, obwohl kein einziger Standard vorherrscht.

History

Cunningham prägte die Schuldenmetapher 1992, um Stakeholdern inkrementelle Design-Kompromisse zu erklären; das Konzept gewann in den 2000er und 2010er Jahren mit agiler Entwicklung, speziellen Forschungsseminaren und Tools, die darauf abzielen, Schulden zu quantifizieren und zu verwalten, an Bedeutung.

Debates

Ist technische Schuld eine nützliche oder überstrapazierte Metapher?

Einige argumentieren, dass die Schuldenmetapher zu locker auf jede Code-Schwäche angewendet wird, was ihre Bedeutung verwässert, während andere sie als wertvolles Kommunikationsmittel für Kompromisse betrachten; präzise Definitionen versuchen, sie handlungsrelevant zu halten.

Key figures

• Ward Cunningham
• Philippe Kruchten
• Ipek Ozkaya
• Robert Nord

Seminal works

• cunningham1992
• kruchten2019
• avgeriou2016

Frequently asked questions

Sind alle technischen Schulden schlecht?

Nein. Wie finanzielle Schulden kann die Aufnahme technischer Schulden eine vernünftige strategische Entscheidung sein – zum Beispiel, um eine kritische Frist einzuhalten – vorausgesetzt, sie ist bewusst, sichtbar und wird zurückgezahlt; die Gefahr liegt in unbeabsichtigten oder unkontrollierten Schulden, die stillschweigend Zinsen ansammeln.

Wie unterscheiden sich technische Schulden von einem Bug?

Ein Bug ist ein für Benutzer sichtbares, inkorrektes Verhalten, während technische Schulden eine interne Strukturschwäche sind, die nicht unbedingt eine falsche Ausgabe erzeugt, aber die Kosten und das Risiko zukünftiger Änderungen erhöht; die beiden können miteinander verbunden sein, sind aber unterschiedliche Anliegen.