Exponentielles Wachstum der LoC ist kein Zeichen gesteigerter Produktivität

Eines der wesentlichen Eckpfeiler agiler Software Entwicklung ist dessen Transparenz. Teams geben kontinuierlich Auskunft über ihren Fortschritt, erledigte Aufgaben, Hindernisse, Ereignisse im Team, aber auch die Qualität ihrer Arbeit. Das Erfassen von Metriken gehört dabei ebenso zum Handwerk wie gezielte Verbesserungen, die mithilfe dieser Metriken nachgewiesen werden – what gets measured, gets managed. Das Erfassen von Code Metriken ist dabei heute weitestgehend mit Tools wie PMD, Findbugs, Sonarqube und Code-Coverage automatisierbar und dank Code Versioning Systemen wie CVS, SVN oder Git lückenlos nachverfolgbar. Jedoch wie mit allen Statistiken müssen die Werte interpretiert und in einen Kontext gesetzt werden, um daraus sinnvolle Schlüsse ziehen zu können. Einzelne, aus dem Zusammenhang gerissene Werte können dabei nicht nur eine völlig andere

Aussage bekommen, sondern schlicht zu den falschen Schlussfolgerungen führen. Lines of Code (LoC) sind eine Metrik um den Umfang des Codes zu bestimmen. Dabei gibt es verschiedene Abstufungen, z.B. nur Produkt-Code, Produkt- und Test-Code, Konfigurationsdateien, Testdaten, usw. Diese Ausprägung ist für Interpretation nicht unwesentlich, werden keine Tests geschrieben, so können die LoC des Produkts schneller wachsen. Werden Tests erst im Nachgang geschrieben, so wird in dieser Zeit die LoC des Produkts kaum wachsen. Werden LoC der Testdaten mitgemessen und enthalten diese viele doppelte Einträge – was bei Testdaten nicht ungewöhnlich ist – so schlagen diese überproportional auf die LoC auf, ohne einen signifikanten Beitrag zum Produkt zu liefern. Ein nicht seltener Trugschluss ist vor allem, die Wachstumsrate der LoC mit Produktivität gleichzusetzen. Sicher, eine hohe Produktivität lässt die Zahl der LoCs schneller wachsen, aber das ist nur ein Aspekt von vielen.

Schlechte Handwerksarbeit lässt den Code ebenso schnell wachsen. Saubere Programmierarbeit erfordert immer wieder die getroffenen Entscheidungen zu hinterfragen und ggf. nach besseren, einfacheren oder eleganteren Lösungen zu suchen. Daraus ergeben sich oft Möglichkeiten, Code wiederzuverwenden, zu vereinfachen, Teile gar zu entfernen. Diese Arbeiten fügen selten dem Produkt neue Funktionen hinzu, sind aber langfristig sinnvoll, da sie die Wartbarkeit erhöhen und damit langfristig den Return on Invest sicherstellen. Auf die LoCs wirken sich diese Massnahmen jedoch „negativ“ aus, d.h. die LoCs werden sinken, die Kurve flacht sich ab.

Auch ist es bei Projekten, die die Startphase hinter sich haben, nicht ungewöhnlich, dass die Kurve flacher wird. Der Hintergrund ist oftmals, dass die Auswirkungen der neuen Anforderungen im immer komplexer werdenden Code erst analysiert werden müssen. Diese Analyse kostet Zeit, die Änderungen müssen wohlüberlegt sein, damit sie keine vorhandene Funktionalität brechen, Tests müssen angepasst werden. Je grösser die Codebasis, umso „langsamer“ das Wachstum. Hat man späteren Phasen eines Projekts ein exponentielles Wachstum der LoC, ohne dass das Entwicklerteam signifikant vergrössert wurde, hat man ein Problem. Die neu hinzugefügte Code Menge ist häufig „schnell“ runtergeschrieben worden. Da der neue Code relativ zur vorhandenen Codemenge nur einen vergleichsweise kleinen Teil darstellt, schlagen prozentuale Metriken, wie z.B. Code Coverage, Documentation Coverage oder Duplicated Lines, kaum aus oder werden als nicht wesentlich wahrgenommen. Die Folgen sind, dass Tests vernachlässigt werden - die Abdeckung ist ja schon hoch genug - Refactorings werden nicht gemacht, ein paar duplicated Lines sind ja schon ok.

Die Ursachen sind häufig hoher Zeitdruck, knappere Budgets - es sollte nicht mehr viel Aufwand hineingesteckt werden – oder auch häufig Abzug von erfahrenen Entwicklern aus dem Projekt, sodass weniger erfahrene Entwicklung ohne Peer-Kontrolle allein gelassen werden und sich ggf. gut oder besser darstellen wollen.

Das Ergebnis gefährdet die Wartbarkeit des Produkts und stellt damit langfristig ein grosses Kostenrisiko dar. Häufig überlebt ein Produkt das Team, das es betreut. Der Code wird von anderen gelesen, als die, die ihn geschrieben haben. Die Einarbeitung wird bei schlechter Wartbarkeit schwieriger, fehlende Tests stellen ein Risiko bei zukünftigen Änderungen dar, fehlende Dokumentation erschwert das Verständnis. All dies sind Risiken und Kostentreiber in der späten Phase einer Software, die durch einfache Mittel hätten verhindert werden können.

Die Mittel der Wahl sind dabei Praktiken guter Software Craftsmenship, Pair Programming, Peer Reviews, Test Driven Development, Red/Green/Refactor, kontinuierliche Dokumentation, um nur einige zu nennen. Entscheidend ist, dass das Problem erkannt und angegangen wird. Statistiken wie LoCs sind dafür ein Hilfsmittel. Kein Marketing oder Performance Management Instrument.