Fachliche Schulden als Kontrapunkt zu "Technical Debt"

Die meisten IT-Profis haben sicherlich schon technische Schulden erfahren, identifiziert, produziert und hoffentlich reduziert. Die wenigsten jedoch haben sich intensiver mit fachlichen Schulden (Domain Debt) auseinandergesetzt. Was sind fachliche Schulden und warum müssen sie ernster genommen werden?

Architektur/Methoden  –  62 Kommentare
Fachliche Schulden als Kontrapunkt zu "Technical Debt"

Eine konkrete wissenschaftliche Definition technischer Schulden gibt es nicht. Die Merkmale zu ihrer Identifikation sind sogar sehr ambivalent. Beispielsweise zählt die Nichtausführung bestimmter Aufgaben oder deren Aufschiebung auf einen zukünftigen Zeitpunkt dazu. Wer hat schließlich noch nicht von fehlender Dokumentation oder unzureichenden Tests gehört? Aber auch die Nutzung von Anti-Patterns,
schlechtem Programmierstil oder fehlende Standards sind kennzeichnend. Trotz dieser Ambivalenz gibt es oftmals einen gemeinsamen Kernpunkt: Technische Schulden sind Aufwandstreiber.

Software mit technischen Schulden ist schwieriger zu warten als Software ohne technische Schulden. Ihre Weiterentwicklung und Wartung dauert schlichtweg länger und ist somit kostenintensiver. Je länger technische Verschuldung besteht, desto teurer wird deren Beseitigung. Schlimmer noch, wenn weitere technische Schulden hinzukommen. Die Softwarebranche scheint sich an solche Schulden gewöhnt zu haben. Zwar versucht man sie zu bekämpfen, jedoch lassen sie sich anscheinend nicht gänzlich vermeiden – und das ist nicht wertend gemeint.

Was in der Softwarebranche jedoch nahezu nie oder zumindest nur sehr selten diskutiert wird, sind fachliche Schulden. Zumindest sind die wenigen Stimmen, die sich zum Thema äußern, in der breiten Masse kaum wahrnehmbar.

(Miss-)Verständnisse

Allerdings gibt es diese Stimmen. Beispielsweise sagte der EventStorming-Erfinder Alberto Brandolini 2017: "It's developer's (mis)understanding, not expert knowledge, that gets released in production."

Wenn das stimmt, müsste man fordern, dass alle Entwickler Fach- beziehungsweise Domänenexperten werden. Aber wie verhält es sich, wenn Entwickler (noch) keine solchen Experten sind? Was ist, wenn sie in einem Lernprozess und damit erst auf dem Weg sind, Experten zu werden? Sie machen Fehler, denn diese sind wichtig, um zu lernen. Beispielsweise tendieren Entwickler dazu anzunehmen, dass Konzepte und Modelle aus einem Kontext der Domäne auch in einem anderen gültig sind. Manchmal erstellen sie inakkurate Abstraktionen und Modelle, weil ihnen Kontextinformationen fehlen – einfache Informationen wie das "Big Picture" oder darüber, wie ihre aktuelle Aufgabe die Bedüfnisse von Benutzern oder Geschäftsprozesse unterstützt.

Auf diese Art kommt es immer wieder vor, dass sich (möglicherweise fehlgeleitete) Hunderttausend-Euro-Entscheidungen in Code manifestieren, der nicht an Geschäftszielen ausgerichtet ist, die niemals jemand deutlich geäußert hat. Als Resultat sind Nachbesserungen und Refactorings unausweichlich.

Welche Art von Fehlern oder Missverständnissen auch existieren, sie schlagen sich in Code nieder. Entwickler verbringen Zeit damit, solchen Code zu schreiben, und gewinnen hoffentlich neue Einblicke in ihre Problemdomäne. Sie refaktorisieren Code, justieren Modelle oder gestalten Kontexte neu. Manager strukturieren Teams neu und widmen Verantwortlichkeiten um. All das kostet Zeit, Aufwand und am Ende Geld. Ist daher Code nicht als eine Art Aufwandstreiber anzusehen? Handelt es sich dabei um Schulden – fachliche, nichttechnische Schulden?