Abstraktes Q in Blau-Weiß als Symbol für Qualitätsschulden und Softwarequalität.

Qualitätsschulden: Der Schlüssel zu besserer Software-Qualität durch neuen Fokus

,

In der Welt der Softwareentwicklung kann ein einfacher Begriffswechsel den Unterschied zwischen Erfolg und Misserfolg ausmachen.  Es ist Zeit für ein Umdenken: Weg von „technischen Schulden“, hin zu „Qualitätsschulden“.

Definition Qualitätsschulden

Eine Qualitätsschuld ist ein Kompromiss während der Entwicklung bezogen auf Code, Architektur oder Dokumentation einer Software. Meistens weichen diese Kompromisse von zuvor getroffenen Architekturentscheidungen oder Qualitätszielen ab. Qualitätsschulden können bewusst oder unbewusst, umsichtig oder rücksichtslos entstehen. Der „Technical Debt Quadrant“ von Martin Fowler bietet eine nützliche Klassifizierung dieser Schuldenarten.12

Eine Qualitätsschuld grenzt sich andererseits zu neuen Features oder Technologien, Bugs, sowie Aufwänden ohne konkret sichtbaren Nutzen („Goldkante“) ab.

Das Problem etablierter Begriffe und warum „technische Schulden“ nicht funktionieren

Der Begriff „technische Schulden“ ist bekannt, doch er erschwert die Kommunikation mit Entscheidungsträgern.

Ein technischer Fokus begrenzt die Reichweite, da „technisch“ für Product Owner, Fachbereiche und Führungskräfte abstrakt und wenig geschäftsrelevant klingt. Dadurch grenzt sich der Begriff selbst vom strategischen Kontext ab. Zudem entstehen oft Missverständnisse. Der Begriff wird häufig als Bug oder schlechtes Coding missverstanden. Dabei handelt es sich meist um bewusste Kompromisse wegen Zeitdruck oder Ressourcenmangel. Dringlichkeit und langfristige Kosten werden nicht klar vermittelt. Deshalb werden notwendige Investitionen in die Codequalität oft aufgeschoben.

Die Lösung: Qualitätsschulden als strategisches Instrument

Qualitätsschulden rücken den Fokus auf das, was wirklich zählt: die Abweichung von definierten Qualitätsanforderungen oder Architekturentscheidungen. Dieser Begriff bietet eine bessere, business-orientierte Kommunikation und damit entscheidende Vorteile. Qualitätsschulden sind verständlich für alle Stakeholder, da Schulden ein bekanntes Konzept aus der Geschäftswelt sind. Sie bieten einen strategischen Kontext mit direkter Verbindung zu Investitionsentscheidungen und ROI-Betrachtungen. Der Handlungsdruck wird verstärkt, da die Schuld-Metapher verdeutlicht, dass Ignorieren teurer wird. Denn Qualitätsschulden sind kein Hausdarlehen (3-4%) sondern eher ein Dispokredit (15%+).

Quality Debt Records: Systematische Verwaltung von Qualitätsschulden

Um Qualitätsschulden steuerbar zu machen, braucht es ein strukturiertes Vorgehen. Das Quality Debt Record (QDR) bietet hierfür einen standardisierten Rahmen.

Die Struktur und strategischen Vorteile eines QDR

In jedem Quality Debt Record sind folgende Kernelemente dokumentiert:

  • Kontext: Beschreibt, was die Herausforderung war und unter welchen Rahmenbedingungen und externen Faktoren die Schuld entstanden ist.
  • Auswirkungen: Beschreibt, welche signifikanten Auswirkungen die Schuld auf Qualitätsziele und Geschäftsprozese hat, und welche Risiken mit ihr einhergehen.
  • Vorgeschlagene Lösung: Beschreibt, welche Maßnahmen existieren, um die Schuld zu beheben oder reduzieren.
  • Kosten: Beschreibt, welche Kosten die Schuld heute und in Zukunft verursacht, und was die vorgeschlagene Lösung kostet.

Die Nutzung eines solchen QDR für Qualitätsschulden bietet einige strategische Vorteile. Transparenz wird geschaffen, indem alle Beteiligten die Auswirkungen und Kosten der eingegangenen Kompromisse verstehen. Die Priorisierung wird ermöglicht, da QDRs nach Business-Impact und technischem Risiko priorisiert werden, nicht nach „technischem Bauchgefühl“. Investitionsentscheidungen werden unterstützt durch klare Kosten-Nutzen-Analysen für Refactoring-Initiativen. Schließlich wird das Risikomanagement verbessert durch frühzeitige Identifikation kritischer Qualitätsprobleme, bevor sie zu existenziellen Problemen werden.

Implementierung in der Praxis

Es sollte nicht jede kleinteilige Schuld dokumentiert werden. Oft können solche Schulden entweder vermieden, oder sehr zeitnah behoben werden. Es gibt keine pauschalen Kriterien, wann eine Qualitätsschuld zu dokumentieren ist und wann nicht. Allerdings gibt es Indizien, die dafür sprechen: Bei bewussten Architekturkompromissen aufgrund von Zeitdruck, wenn etablierte Qualitätsziele verletzt werden müssen oder bei der Entdeckung bestehender Qualitätsprobleme mit potenziellen Auswirkungen auf das Geschäft. Fokussiere dich auf Qualitätsschulden, die die Systemqualität maßgeblich verschlechtern, zukünftige Entwicklungsgeschwindigkeit beeinträchtigen, Sicherheits- oder Performance-Risiken bergen oder Compliance-Anforderungen gefährden. Auch Qualitätsschulden können sich im Laufe der Zeit verändern; kritischer oder weniger kritisch, günstiger oder teurer werden. Daher empfiehlt sich ein regelmäßiges Sichten der Schulden, z.B. monatlich, quartalsweise oder im Zuge größerer architektonischer Änderungen.

Handlungsempfehlungen und Fazit

Wir empfehlen den Begriff der Qualitätsschulden zusammen mit der Etablierung von systematischer Dokumentation einzuführen, um so ein Mehr an Softwarequalität zu erreichen.

  1. Begriffswechsel einführen: Verwende ab sofort „Qualitätsschulden“ statt „technische Schulden“ in der Stakeholder-Kommunikation.
  2. QDR-Template etablieren: Definiere einen Standard für die Dokumentation von Qualitätsschulden.
  3. Review-Prozesse anpassen: Integriere die QDR-Erstellung in Code-Reviews und Architekturentscheidungen.
  4. Metriken etablieren: Verfolge die Entwicklung deiner Qualitätsschulden auch quantitativ.

Qualitätsschulden sind kein notwendiges Übel, sondern ein strategisches Thema, das proaktiv gemanagt werden muss. Der Begriffswechsel von „technischen Schulden“ zu „Qualitätsschulden“ ist mehr als nur kosmetisch – er verändert die Wahrnehmung und das Management von Qualitätskompromissen grundlegend.

Sven Mohr

Über MICH

Sven Mohr hat Informatik studiert (M.Sc.) und ist bei doubleSlash als Senior Software Architect beschäftigt. Schon lange begeistert er sich für Elektromobilität und hat in diesem Bereich mit seiner umfangreichen Erfahrung Softwarearchitekturen konzipiert, umgesetzt und überprüft. Besonders interessieren ihn Domain-Driven Design und resiliente Softwarearchitekturen.

Alle Beiträge von Sven Mohr

Mehr erfahren

Weitere Infos auf unserer Website und in unserem Newsletter

Pfeil hoch