Qualitätsinvestitionen statt technischer Schulden
Wohl jeder Entwickler kennt die Probleme bei der Wartung und Änderung alter Codebasen. Der Code ist schlecht strukturiert, es gibt nur wenige Tests, und die Versionen der verwendeten Bibliotheken sind recht alt. Diese technischen Probleme dem Management besser zu kommunizieren, ist die Metapher der "technischen Schulden" angetreten.
- Felix Müller
- Eberhard Wolff
Wohl jeder Entwickler kennt die Probleme bei der Wartung und Änderung alter Codebasen. Der Code ist schlecht strukturiert, es gibt nur wenige Tests, und die Versionen der verwendeten Bibliotheken sind recht alt. Viele Dinge sind außerdem viel zu kompliziert umgesetzt. Diese technischen Probleme dem Management besser zu kommunizieren, ist die Metapher der "technischen Schulden" angetreten.
Die Idee hinter der Metapher "technische Schulden" ist, den Qualitätskompromiss als Schuld zu begreifen. Er lässt sich sogar beziffern: Es sind der Aufwand beziehungsweise die Kosten zum "Reparieren" der Codebasis – also zum Verbessern der Struktur, zum Schreiben der entsprechenden Tests oder zur Umstellung auf neue Versionen der verwendeten Libraries.
Auf Schulden sind auch Zinsen zu zahlen. Bei der Metapher der technischen Schulden sind die Zinsen die verringerte Produktivität des Teams bei der Implementierung neuer Features. Die erste Intuition bei technischen Schulden ist es, sie abzutragen und zu verringern. Das ist aber nicht immer sinnvoll. Im Gegenteil: Zusätzliche technische Schulden können eingegangen werden, um ein neues Features "quick & dirty" zu implementieren. In dem Fall opfert das Team die Qualität für einen Vorteil bei der Time-to-Market. Langfristig verkehrt sich der Produktivitätsvorteil dann aufgrund der "Zinsen" in einen Nachteil, sodass man vorsichtig mit dem Aufnehmen von Schulden sein muss (Abb. 1).
Für das Abtragen der Schulden gibt es unterschiedliche Ansätze. Kleinere Verbesserungen sollte jeder Entwickler in seiner täglichen Arbeit durchführen. Stehen aber größere Änderungen an, ist der Aufwand einzuplanen und irgendwie im Budget vorzusehen. Dazu gibt es viele unterschiedliche Ansätze – ein InfoQ-Artikel führt einige aus. Bei der Diskussion um ein solches Budget soll gerade die Metapher der technischen Schulden helfen. Schließlich stammt sie aus der Finanzwelt, einem Bereich, mit dem Manager vertraut sein sollten.
Das Team kann nun eine Aussage treffen und gegebenenfalls den Aufwand für das Abtragen der Schulden abschätzen. Werkzeuge wie SonarQube können dabei helfen. Oft ist der Aufwand für das "Aufräumen" der Codebasis recht hoch (Abb. 2).
Beim verantwortlichen Management kann dieser Ansatz zu Schwierigkeiten führen. Immerhin sind mit dem Projekt offensichtlich versteckte Aufwände und ein technisches Risiko verbunden. Woher soll das Budget für diese Aufwendungen kommen? Vom Kunden? Aber es sind ja keine Features. Am Ende bekommen die Entwickler oft kein "Go" für umfangreiche Verbesserung. In der Situation treffen sie die Entscheidung zum Umgang mit den technischen Schulden selbst.
Das ist teilweise professionell – immerhin ist ein Fokus auf Qualität ein Zeichen professioneller Arbeitsauffassung –, aber wenn ganze Tage in Verbesserungen investiert werden müssten, sollte es eine Managemententscheidung sein. Der Aufwand ist gegen die Implementierung von Features und Time-to-Market zu priorisieren. Das sollte nicht unter dem "Management-Radar" geschehen, außer wenn die Entwickler den Aufwand in den Aufwand zur Implementierung der Stories "einpreisen" – also bei jedem Feature überlegen, ob der Code vorher verbessert werden sollte, um dann das Feature einfacher zu implementieren. Auf jeden Fall verdeutlicht das, dass die Metapher der technischen Schulden nicht unbedingt hilft, um dem Management die Qualitätsprobleme zu veranschaulichen und sinnvolle Entscheidungen vorzubereiten.
Das Problem mit den technischen Schulden
Die Qualität des Codes hat nämlich eine entscheidende Eigenschaft: Sie ist völlig egal – solange der Code nicht geändert werden soll. Dann aber ist die Qualität äußerst wichtig. Das Hauptproblem ist also: Welche Schulden sind egal und welche extrem wichtig? Welche Schulden sollen wann abgetragen werden? An dieser Stelle hilft die Metapher der technischen Schulden allein nicht weiter.
Die technischen Schulden haben mit dem erfolgreichen Abschluss eines Projekts nichts zu tun. Aber am Ende entstehen in einigen Situationen ökonomisch unsinnige Entscheidungen. Wenn die Qualität langfristig vernachlässigt wird, sinkt die Produktivität immer weiter – was insbesondere Manager nicht sinnvoll finden
können. Entwickler können solche Situationen vorhersehen und haben dann oft ein schlechtes Gefühl, aber sie können es nicht belegen oder gegenüber dem Management klar kommunizieren.
Dazu lässt sich ein anderer Begriff aus der Finanzwelt nutzen: die Investition. Wenn Entwickler die Qualität des Codes erhöhen, ist das eine Investition. Sie ist nur sinnvoll, wenn sich so in Zukunft eine höhere Produktivität erreichen lässt. Qualität ist eben kein Selbstzweck, sondern erleichtert Änderungen an der Codebasis, beeinflusst so die Produktivität und ist daher von ökonomischer Bedeutung. Also ist die grundlegende Idee, dass Qualitätsverbesserungen eine Investition sind. Sie sind sinnvoll, wenn durch die Verbesserungen mehr Aufwand eingespart wird, als für die Umsetzung der Verbesserungen notwendig ist. Ideal wäre es, wenn sich sogar ein Return on Investment für die Qualitätsmaßnahmen berechnen ließe.
