In den letzten Tagen habe ich mich mit SunarQube und damit verbundenen Themen auseinander gesetzt und viel gelernt. Der Begriff der “technischen Schuld” hat einige Gedanken in Bewegung gesetzt. Zwar ist das Thema seit ich Softwareprojekte umsetze präsent, aufgearbeitet habe ich es noch nie vollständig. Zu diesem Thema lassen sich einige Quellen finden, auch gibt es hochtheoretische Abhandlungen darüber, an dieser Stelle möchte ich meine aktuelle Gedankenwelt zu diesem Thema behandeln.
Warum ich darüber schreiben möchte, wurde durch folgende Antwort auf einen meiner Tweets ausgelöst:
@norberteder ein weiteres Tool kann ein umdenken in den Managerköpfen nicht bewirken. Stillstand ist vorprogrammiert durch Altlasten.
— Dennis Bischof (@dbischof) July 30, 2013
Ursprünglich habe ich eine Installationsanleitung für SunarQube geschrieben. Ein Tool zur Source Code Analyse und der Findung der technischen Schuld eines Teams/Projektes. Dennis hat dies sofort auf die Management-Ebene bezogen. Dies ist der Punkt, an dem ich einhaken muss.
Andreas Schlapsi hat vor Jahren einen sehr guten Artikel zum Thema Technische Schulden geschrieben. Ich empfehle diesen Beitrag zu lesen, bevor es hier weiter geht.
Begriffsdefinition
Unabhängig der grauen Theorie, bedeutet der Begriff der technischen Schuld für mich:
- Aufbau von Problemstellen im Source Code bedingt durch fehlendes Know-How, falscher Umgang mit Pattern/Bibliotheken/Werkzeugen etc.
- Bewusstes Umgehen von definierten Regeln um (vermeintlich) schneller zu einer Umsetzung zu gelangen (Workarounds)
- Verteufeln von qualitätssichernden Maßnahmen (siehe Tests) mit der Argumentation des erhöhten Zeitaufwandes
- Fehlende Überlegungen hinsichtlich der Auswirkungen aktueller Implementierungen. Dabei geht es nicht um die Berücksichtigung aller möglichen Eventualitäten, das ist unrealistisch. Vielmehr sollten wahrscheinliche bzw. mögliche Erweiterungen nicht unmöglich gemacht werden.
Technische Schulden und Management
Technische Schulden haben erst einmal gar nichts mit dem Management zu tun. Das Management tut das, wofür es da ist: Es versucht alles, dass Anforderungen/Projekte in möglichst kurzer Zeit und unter Verwendung möglichst geringer Ressourcen umgesetzt werden und somit den maximal möglichen Ertrag bringen (Gewinnmaximierung). Das ist eine durchaus verständliche Vorgehensweise eines Managements (auch wenn dies gerade von Entwicklern nicht gerne akzeptiert wird). Im Grunde ist sie auch korrekt, da nur durch dieses Vorgehen ein Wachstum des Unternehmens oder zumindest eine Sicherung des Fortbestandes gewährleistet werden kann.
Natürlich birgt dies auch einige (potentielle) Nachteile für Entwickler:
- Sinnvolle und hilfreiche Tools werden nicht, oder nur mit einer ungenügenden Anzahl an Lizenzen angeschafft, da der Anschaffungspreis (und damit offensichtliche Kosten) im Vordergrund stehen und weniger die (aber auch schwer messbaren) möglichen Einsparungen.
- Es wird häufig um “Abkürzungen” gebeten, um eine kürzere Durchlaufzeit zu erreichen.
- Qualitätssichernde Maßnahmen werden nicht “bezahlt” da die “schnelle Kohle” im Vordergrund steht.
- Ein Aufbau der notwendigen Infrastruktur wird nicht einkalkuliert, da entweder nicht “notwendig” oder aber auch zu einem späteren Zeitpunkt durchführbar.
Die meisten praxiserprobten Softwareentwickler können diese Liste beliebig weiter führen, wobei auch bei diesem Thema gerne in Extremen gedacht wird. Qualitätssichernde Maßnahmen – als Beispiel – sind extrem wichtig, wenn eine längere Projektlaufzeit gegeben sind. Meine Aussage impliziert, dass Projekte mit kurzer Laufzeit keine Tests notwendig machen. der beliebteste Satz der Softwarenentwicklung kommt nun zu tragen: “It depends”. Ist es eine Einmallösung mit ein paar wenigen Tagen Durchlaufzeit, dann sind Tests wohl ein rein akademischer Ansatz. Der Mehrwert kaum gegeben, da keine oder kaum Änderungen zu erwarten sind und manuelle Tests in kürzester Zeit durchgeführt werden können. Bei sich ständig weiterentwickelnden Projekten (Standardprodukte, kundenspezifische Lösungen mit teilweise mehrjährigen Entwicklungen) sieht das natürlich gänzlich anders aus.
Nun, da es in der Natur des Menschen liegt, Probleme erst bei anderen zu suchen, wird vor allem das Projektmanagement (dieses ist in der Regel ja recht nahe an der Softwareentwicklung) gerne für technische Schulden verantwortlich gemacht, gibt er immerhin vor was zu tun ist. Nun, genau das ist der springende Punkt. Er gibt vor WAS zu tun ist. Er definiert in keinster Weise WIE etwas zu tun ist (auch wenn das diverse Spezifikationen oftmals suggerieren).
Technische Schulden und Entwickler
Entwickler bekommen von ihren Projektmanagern (oder wie sie im jeweiligen Unternehmen genannt werden, oftmals – gerade bei kleineren Unternehmen – auch direkt vom Chef) ihre Vorgaben. Das sind dann mehr oder weniger gut formulierte Spezifikationen (gerne auch in Wasserfall-Manier). Die Umsetzung obliegt zur Gänze dem oder der Softwareentwickler. Der Softwareentwickler entscheidet wie eine Umsetzung durchgeführt wird (natürlich können Themen wie Plattform etc. sehr wohl vorgegeben werden), wie die Architektur aussieht, welche Patterns, Bibliotheken und Werkzeuge zum Einsatz kommen. Vielmehr entscheidet er auch, wie SEIN Entwicklungsprozess aussieht. Werden Tests geschrieben, agiert er sogar nach TDD? Gerade OSS bietet einen wahren Fundus an vielen hilfreichen Tools, die bei der Entwicklung sehr gut unterstützen können. Werden diese nicht ausgeschöpft, lässt man sich zu sehr “vom Business” treiben usw. entstehen technische Schulden, die irgendwann in der Zukunft zurück bezahlt werden müssen. Das tut – in der Regel – sehr weh, da wichtige Anforderungen nicht umgesetzt werden können und viel Zeit in die Richtigstellung der bisherigen Entwicklung läuft.
Der Entwickler ist alleine für technische Schulden verantwortlich.
Technische Schulden entstehen aus der Entwicklung heraus. Diese wird vom Softwareentwickler durchgeführt, wodurch die Verantwortung klarerweise auch bei ihm liegt.
Technische Schulden und “Goldene Glaskuppel”
Wenn ich oben von Workarounds und deren “Vermeidung” spreche, dann meine ich nicht, dass alles “Unhübsche” abgelehnt werden soll. Es geht nicht um akademische Lösungen. Es geht vielmehr darum, den für diesen Zeitpunkt richtigen Mittelweg zu finden, also eine Lösung, die Erweiterungen nicht unmöglich macht, die Einhaltung von gut überlegten und definierten Standards ermöglicht und eines Entwicklungsprozesses, der nicht alles zulässt (Definitionen zwischen Tür und Angel, als Beispiel), aber dennoch flexibel genug ist, Änderungen zuzulassen. Dies ist ein schmaler Grat, der sehr gerne auf der einen oder anderen Seite überschritten wird. Hier bedarf es durchaus Erfahrung um das richtige Mittelmaß zu finden.
Vorsicht!
Gerade beim Einsatz von Werkzeugen zur Offenlegung der Code-Qualität oder Messung der technischen Schulden ist – aus meiner Sicht – Vorsicht geboten. Nicht jeder versteht die dargebotenen Zahlen und gerne verleiten diese auch, Entwickler unter Druck zu setzen. Als Beispiel sei etwa die Code Coverage zu nennen. Eine Code Coverage von 100% ist wenig erstrebenswert, ein Management kann dies aber anders auslegen, da dies durchaus ein “positives” Verkaufsargument sein kann. Als weitere Beispiel seien die LOC (Lines of Code) zu nennen: Diese werden gerne verwendet, um den Fortschritt eines Teams zu messen. Sprich, 2000 Codezeilen in zwei Wochen wird möglicherweise als gut empfunden, 500 als schlecht. Kann man dies so beurteilen? Nein, natürlich nicht. Genau so wenig ist ein Entwickler, der pro Tag 200 Zeilen Code schreibt besser, als einer, der nur 30 verfasst.
Es ist bei diesem Thema also Vorsicht walten zu lassen um nicht die falschen Schlüsse im Management herbei zu führen – wenn das notwendige Verständnis für derartige Tools fehlt.
Fazit
Um nun den Bogen zum Ursprung dieser Post zu spannen: Es ist irrelevant, ob ein Entwickler-Werkzeug ein Umdenken des Managements bewirkt. Es muss dem Entwickler helfen, seinen Job bestmöglich zu ermöglichen. Einem Management ist ein Entwickler-Werkzeug – aus gutem Grund – schnurzegal (siehe auch “Schuster bleib bei deinen Leisten”). Definitiv, wenn es keine Anschaffungskosten verursacht, weniger, wenn es kostenpflichtig ist. Hier hilft eine Summary hinsichtlich der Vorteile und eine ungefähre Schätzung des ROI (siehe beispielsweise ReSharper). Es empfiehlt sich jedenfalls in unterstützende Werkzeuge zu investieren. Der betriebene Aufwand muss jedoch im Rahmen bleiben, denn wichtig ist der Fortschritt der Umsetzung.