Begriff

Verständnisschuld

Info

Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.

Kurzdefinition

Abstand zwischen dem, was ein System tut, und dem, was das dafür verantwortliche Team erklären kann. Man nimmt sie jedes Mal auf, wenn Code angenommen wird, ohne dass jemand sagen kann, warum er so geschrieben ist, und man tilgt sie mit der Zeit, die es kostet, eine Absicht zu rekonstruieren, die nie jemand gefasst hat.

Ausführliche Definition

Der Ausdruck ist den technischen Schulden nachgebildet und übernimmt deren Mechanik — ein sofortiger Vorteil gegen höhere Kosten später —, ändert aber das, was geliehen wird. Technische Schulden betreffen den Zustand des Codes; diese hier betreffen den Zustand in den Köpfen derer, die ihn warten.

In den Artikeln dieses Blogs bezeichnet der Begriff die Kehrseite der assistierten Entwicklung: Ein Team, das generierten, übernommenen und gepatchten Code mergt, ohne dass ihn irgendwer erklären kann, bekommt sofort Funktionalität und später die Unfähigkeit zur Diagnose. Der Passivposten bleibt unsichtbar, solange nichts bricht, denn die Anwendung läuft, die Bildschirme antworten und die Tests laufen durch.

Der normative Sinn verlangte eine messbare Schuld, die sich durch ein klar umrissenes Vorhaben tilgen lässt. Die Praxis kennt weder Zähler noch Fälligkeit: Man stellt sie im Moment des Vorfalls fest, wenn ein Team entdeckt, dass es nicht mehr weiß, warum alles zusammenbricht, und getilgt wird sie durch ein erneutes Durchlesen, für das niemand mehr Zeit hat.

Gebrauch im Feld

Der Begriff kommt in Merge-Regeln vor — Code ablehnen, den niemand erklären kann —, bei der Abwägung des Verständnisbudgets pro Feature (der Vertrag, die Tests, die Architekturentscheidung, die bekannten Grenzen) und bei der Diagnose eines Teams, dessen Korrekturtakt steigt, ohne dass sich das Produkt verändert.

Synonyme und Varianten

„Unverstandener Code“, „Code annehmen, den man nicht erklären kann“. Verwandte Wendungen für denselben Passivposten: „eine Architektur, in der man nie wirklich zu Hause war“, „Entscheidungen, die niemand wirklich getroffen hat“.

Nicht zu verwechseln mit

  • Technische Schulden — Entwurfsschwäche, für die das Unternehmen beschlossen hat, sie zu beheben, und die deshalb Kosten und einen Platz in den Prioritäten hat; sie wird mit Umbauarbeit getilgt, während die Verständnisschuld mit der Unfähigkeit bezahlt wird, zu entscheiden, was umgebaut werden soll — und sie braucht eine Entscheidung, um zu existieren, während diese hier beim Merge entsteht.
  • Rekonstruierbarkeit — Eigenschaft eines Systems, das ein Team anderswo neu bauen könnte; sie ist der Aktivposten, dessen Passivposten diese Schuld ist, und die Frage „Könnte ich es neu aufbauen?“ ist der direkteste Weg, das eine oder das andere festzustellen.
  • Dokumentationsschulden — fehlende oder veraltete Dokumente über das System; ein Team kann alles dokumentiert und nichts verstanden haben, so wie es alles verstehen kann, ohne etwas aufgeschrieben zu haben.
  • Bus-Faktor — Zahl der Personen, deren Weggang ein System unbetreibbar machen würde; er misst, wie ein vorhandenes Verständnis verteilt ist, nicht, dass es fehlt.
  • Legacy — geerbtes System, dessen Entscheidungen anderswo und früher getroffen wurden; die Verständnisschuld wächst auf Code, der diese Woche geschrieben wurde.

Beispiele

„Wer unverstandenen Code annimmt, nimmt eine Verständnisschuld auf.“ — der Referenzgebrauch, formuliert als Folge einer Merge-Regel.

Dutzende Pull Requests, die ein Assistent über Nacht erstellt hat und die gemergt werden, ohne dass jemand die Auswirkungen geprüft hat: Die ausgelieferte Menge ist ein Passivposten, kein Vorsprung.

Eine Anwendung, die die glücklichen Pfade durchläuft und Hunderte technischer Entscheidungen enthält, die generiert, übernommen, gepatcht und dann vergessen wurden, trägt die ganze Schuld, auch wenn noch kein Fehler aufgetreten ist.

Mehrdeutigkeiten / Debatten

Das Wort „Schuld“ legt einen Betrag und eine Fälligkeit nahe, die sich hier durch nichts bestimmen lassen: Keine belegte Praxis beziffert den Abstand zwischen dem, was ein System tut, und dem, was ein Team davon erklären kann.

Umstritten bleibt auch die Zurechnung: Trägt die Schuld die Person, die gemergt hat, oder das Team, das wartet? Der hier gewählte Gebrauch ordnet sie dem Team zu, weil es sie tilgt.