Kurzdefinition

Entwurfs- oder Architekturschwäche einer Software, für die das Unternehmen beschlossen hat, sie zu beheben, und die deshalb Tilgungskosten und einen Platz in den Prioritäten hat. Solange diese Entscheidung nicht gefallen ist, bleibt die Schwäche eine Unannehmlichkeit oder ein latentes Risiko.

Ausführliche Definition

Im allgemeinen Sprachgebrauch umfasst der Begriff alles, was ein Entwickler an bestehendem Code bedauert: eine alte Abkürzung, eine schwache Architektur, angehäufte Komplexität, eine veraltete Bibliothek. Die Finanzanalogie ist dort rein beschreibend – man spricht von Schulden, um zu sagen, dass etwas später etwas kosten wird, ohne dass ein Gläubiger, eine Fälligkeit oder ein Betrag benannt würde.

In den Artikeln dieses Blogs ist der Begriff dem vorbehalten, was eine Entscheidung durchlaufen hat. Eine seit Jahren bekannte Schwäche, die niemand ins Programm aufgenommen hat, ist keine Schuld: Sie hat weder Termin noch abgewogene Kosten noch einen Verantwortlichen für die Tilgung. Zur Schuld wird sie, wenn das Unternehmen urteilt, dass die Kosten, sie mitzuschleppen, die Kosten ihrer Behebung übersteigen – weil sie eine Strategie blockiert, das Team erheblich verlangsamt, einem Risiko aussetzt, die vom Kunden wahrgenommene Qualität verschlechtert oder eine wichtige Produktänderung verhindert.

Der Gebrauch in der Praxis weicht deutlich vom hier gewählten Sinn ab: Dort bezeichnet „Wir haben technische Schulden“ einen Dauerzustand des Systems und löst nichts aus. Der hier gewählte Sinn macht aus dem Begriff einen Status, den man erwirbt, keine Feststellung, die man wiederholt.

Gebrauch im Feld

Priorisierungs-Review zwischen einem Produktthema und einem technischen Thema, Argumentation eines Entwicklers vor einem Gremium, Entscheidung über die Aufnahme eines technischen Themas in die Roadmap, Festlegung einer Behebungsstrategie, die vom täglichen Bug-Management getrennt ist.

Synonyme und Varianten

„die Schulden“ als Kurzform · „Architekturschulden“, wenn die Schwäche strukturell ist · „technische Unannehmlichkeit“ und „latentes Risiko“ für den Zustand vor der Entscheidung.

Nicht zu verwechseln mit

• Defekt — Abweichung zwischen dem erwarteten und dem tatsächlichen Verhalten einer Software; Schulden zeigen kein sichtbar fehlerhaftes Verhalten, sie verteuern die Weiterentwicklung.
• Zero-Bug-Policy — Regime, das verbietet, einen bekannten Fehler ohne Entscheidung zu behalten; es betrifft Verhaltensabweichungen, nie Entwurfsschwächen.
• Roadmap — Übersicht der großen committeten, vorbereiteten und möglichen Themen; technische Schulden erscheinen darin erst nach der Entscheidung zur Behebung.
• Dette de compréhension — Abstand zwischen dem, was ein Team hervorgebracht hat, und dem, was es über das Hervorgebrachte weiß; sie wird mit der Unfähigkeit bezahlt, zu entscheiden, was neu gebaut werden soll, während technische Schulden mit Umbauarbeit bezahlt werden.
• Refactoring — Verbesserung des Codes von innen ohne Verhaltensänderung; ein Mittel der Tilgung, nicht die Schulden selbst.
• Essenzielle Komplexität — dem behandelten Problem innewohnende Schwierigkeit, die keine Architekturarbeit beseitigt.
• Reconstructibilité — Eigenschaft eines Systems, das ein Team anhand seiner Verträge, seiner fachlichen Regeln und seiner Tests anderswo neu bauen könnte; sie beschreibt, was man über das System sagen kann, nicht die Qualität seines Entwurfs.
• Dette de compréhension — Abstand zwischen dem, was ein System tut, und dem, was das dafür verantwortliche Team erklären kann; sie betrifft die Köpfe derer, die es warten, während technische Schulden den Zustand des Codes betreffen, und sie braucht keine Entscheidung, um zu existieren.

Beispiele

Eine schwache, seit Langem bekannte Architektur, die niemanden am Ausliefern hindert: Unannehmlichkeit, keine Schuld.

Dieselbe Architektur an dem Tag, an dem sie ein strategisches Vorhaben blockiert und das Unternehmen beschließt, sie zu überarbeiten: Schuld, für die ein Platz in den Prioritäten gefunden werden muss.

Mehrdeutigkeiten / Debatten

Die Finanzanalogie ist umstritten: Schulden setzen eine freiwillige Kreditaufnahme voraus, während ein großer Teil dessen, was der Begriff abdeckt, ohne Wahl angehäuft wurde, aus Unkenntnis oder unter Termindruck. Manche schlagen vor, ihn bewusst eingegangenen Abkürzungen vorzubehalten.

Eine zweite, praktischere Unschärfe: Gehören technische Schulden in die Kapazität des Teams oder in die Themen der Roadmap? Beide Antworten sind im Umlauf, und sie machen nicht dieselbe Person zum Entscheider.