Risiken und Nebenwirkungen
26.09.2014, 09:00 Uhr
Absolute Quantifizierung von Technical Debt
Als ich zum ersten Mal in einem Tool einen Geldbetrag als Mass für technische Schulden sah, war ich skeptisch, ohne zu wissen warum ....
Artikel direkt im Zhlke-BLOG lesen Die Metapher der technischen Schulden war mir vertraut und ich hielt (und halte sie auch heute noch) für sinnvoll. Es war die Reduktion auf eine einzelne Zahl, die mich skeptisch machte. Viele Diskussionen später kann ich meine Skepsis nun begründen. Der Geldbetrag in den mir bekannten Tools basiert schlussendlich auf statischer Code-Analyse und eventuell irgendeiner Form von Testabdeckung. Das heisst, dass der Geldbetrag ein Mass für die relativ lokale Code-Qualität ist (definiert durch die Regeln der benutzten Analyse-Tools, die zum Teil jede Methode einzeln betrachten), während die wirklich grossen und teuren Probleme wie eine ungeeignete Architektur oder ein schiefes Domänenmodell nicht berücksichtigt werden. Dadurch besteht das Risiko, dass ein Team zuerst Aufwand in die ?kleinen? Probleme investiert. Auf den ersten Blick scheint diese Bereinigung eine gute Idee zu sein, schliesslich sinkt die gemessene technische Schuld mit verhältnismässig wenig Aufwand. Auf den zweiten Blick erinnert es aber an die Geschichte der Person, die den verlorenen Schlüssel bei der Strassenlaterne sucht (da ist es hell) statt dort, wo sie ihn verloren hat. Die Strassenlaterne entspricht dem Tool, das die kleineren Probleme beleuchtet, während die grossen Probleme im Dunkeln bleiben. Selbst wenn wir das Problem der unvollständigen Messung lösen könnten, würde das in meinen Augen nicht viel bringen: Der Geldbetrag beziffert die Arbeit, die investiert werden müsste, um die technische Schuld zu begleichen. Darin stecken die Annahmen, dass es genau eine ideale Lösung ohne technische Schulden gibt, dass der Aufwand fürs Erreichen dieser idealen Lösung bekannt ist, und dass es Sinn macht, sie anzustreben. Nur sind üblicherweise alle drei Annahmen falsch:
- Es gibt höchstens für triviale Systeme ein einziges richtiges Design.
Der Normalfall ist, dass es mehrere gute Lösungen für ein Problem gibt, sowohl bei globalen als auch bei lokalen Design-Fragen. Auch wenn nur letztere gemessen werden: Auf welche dieser Lösungen bezieht sich die Messung der technischen Schuld? - Der Aufwand variiert mit der allgemeinen Erfahrung und den spezifischen System-Kenntnissen der umsetzenden Person.
Weitere Einflüsse sind unter anderem die gewählten Strategien, Konflikte mit der Arbeit von anderen Team-Mitgliedern und die Mächtigkeit der Tools. - Meiner Erfahrung nach stecken die grössten Probleme oft in den Teilen der Software, die am seltensten angefasst werden. Das sind Teile, die vor langer Zeit unter Zeitdruck und mit ungenügendem Kontextwissen oder instabilen Requirements geschrieben und seither kaum verändert wurden, weil entweder die Requirements nun stabil sind oder der Business-Nutzen nicht gross genug ist, dass jemand neue Anforderungen finden würde.
Für Tools ist solcher Code ein gefundenes Fressen, kaum irgendwo ist die Dichte an Unsauberkeiten so gross wie hier. Und trotzdem ist unter Umständen fraglich, ob sich grosse Aufräumarbeit an diesen Teilen im Laufe der Lebenszeit der Software überhaupt noch rechnen. Wenn aber die technischen Schulden auf eine einzelne Zahl reduziert werden, dann besteht die Gefahr, dass solche weitsichtigeren Überlegungen der blinden Reduktion der Schulden zum Opfer fallen.
Ein weiterer Ort, wo sich Probleme gerne ansammeln, sind die Ränder von selten veränderten Teilen. Weil niemand mehr den Code wirklich versteht und sich an eine grössere Veränderung wagt, versammeln sich rundherum die Workarounds und Überbleibsel von schon lange verworfenen Design-Ideen. Diese Bereiche sind eher ein Hinweis darauf, dass die stabile Zone in der Mitte vielleicht doch aufgeräumt werden müsste, da sich ihr Umfeld verändert und sie sich mitverändern müsste.
Statische Code-Analyse und Tools für die Messung der Testabdeckung halte ich durchaus für sinnvoll. Ihr Nutzen ist meiner Meinung nach am grössten, wenn sie mir während der Entwicklung laufend Feedback über den Code geben, an dem ich gerade arbeite. Die Metapher der technischen Schuld ist ein wichtiges Hilfsmittel für Diskussionen über die Konsequenzen von verschiedenen Lösungsansätzen oder darüber, welche Teile des Codes besondere Aufmerksamkeit brauchen. In diesem Kontext ist es völlig ausreichend oder sogar effektiver, die bekannten Probleme konkret zu benennen und mit Vergleichen (?Das Design von Klasse X stört mehr als das von Klasse Y?) zu arbeiten. Für Diskussionen mit weniger technisch orientierten Personen, die mit diesen konkreten Problem-Beschreibungen wenig anfangen können, halte ich einen absoluten Betrag für die technischen Schulden trotzdem für bedenklich. Da gerade die grossen und teuren Brocken von der Messung nicht erfasst werden, ist die Zahl im besten Fall nur bedingt aussagekräftig, während sie im schlimmsten Fall irreführend sein kann. Idealerweise haben alle an der Diskussion Beteiligten ein längerfristiges Interesse an der Software und entwickeln dadurch ein Verständnis dafür, dass gewisse Kompromisse nur durch den Aufbau von technischen Schulden möglich sind. In so einem Umfeld ist es eher möglich, die Bereinigung der durch einen bestimmten Kompromiss verursachten Schulden von vornherein einzuplanen. Ausserdem haben die Beteiligten mit einem längeren Zeithorizont eher ein Interesse daran, alte Schulden abzutragen und danach davon zu profitieren, dass neue Anpassungen einfacher umgesetzt werden können. Zum Zhlke-BLOG
