Vorsicht, Softwaremetriken!

Im Bestreben Software besser machen zu wollen, stößt man schnell auf das Problem der Quantifizierbarkeit. Denn wie kann man Software als besser oder schlechter identifizieren, wenn man sie nicht vergleichen kann. Ein Vergleich setzt jedoch eine Messbarkeit voraus.

Metriken müssen her. Softwaremetriken sollen Softwarequalität messbar und somit vergleichbar machen. So ist zumindest die Idee. Es gibt bereits eine ganze Reihe davon: sie messen Zeilen, Abhängigkeiten, Kommentare, den Modularisierungsgrad und vieles mehr.

Es gibt jedoch zwei Aspekte, die man leider allzu oft außer Acht lässt:

1. Systeme ändern sich durch ihre Beobachtung
2. Man entwickelt einen immens großen blinden Fleck

Verhaltensänderung

Der Einsatz von Metriken wird nur allzu oft davon gefolgt, dass Aussagen über Code getroffen werden (z.B. "Das Modul XY hat zu wenig Kommentare und zu viele Zeilen pro Funktion."). Natürlich gibt es Personen, die für deren Entstehung gesorgt haben und sich kritisiert fühlen. Früher genügte es die Funktionalität umzusetzen. Jetzt muss auch noch die Anzahl der Kommentare stimmen. Das Ziel hat sich verschoben. Nach den ersten Feedbacks werden die Entwickler ihre Gewohnheiten ändern.

Das war auch das Ziel. Man wollte Änderung. Die Software soll besser werden. Und sie wird besser - garantiert! Denn die Entwickler werden dafür sorgen, dass die Metrik ein besseres Bild auf Ihr Projekt wirft.

Nur leider wird das Ergebnis anders sein als erhofft. Wo früher Kommentare Mangelware waren (weil z.B. getAsXml() selbsterklärend war), dort werden sie zur Redundanz (z.B. /* get item as xml */). Die Handlungen der Entwickler orientieren sich nicht an Softwarequalität, sondern an den Metriken.

Blinder Fleck

Bei der Verwendung solcher Metriken vergisst man schnell die Tatsache, dass sie nicht Qualität selbst messen, sondern vielmehr Indikatoren für schlechte Qualität sind. So sind Funktionen mit langen Codeblöcken ein Zeichen für schwer lesbaren Code. Kurze hingegen können lesbar sein - sie können aber auch genau so unlesbar sein.

Letztendlich sind solche Metriken ein kläglicher Versuch etwas zu messen, das nicht leicht zu messen ist. Es ist als wolle man die Güte eines Romans anhand seiner Seiten, Zeilen, Wörter bemessen oder anhand der Anzahl der darin vorkommenden Personen.

Man versteift sich auf Aspekte, die bestenfalls vage etwas mit dem beabsichtigten Ziel zu tun haben. Das eigentliche Ziel, die Qualität zu verbessern, bleibt dabei schnell auf der Strecke.

Fazit

Solange der Softwareentwicklungsprozess nicht ausreichend gut verstanden ist und wir nur ein Gefühl für Qualität haben, diese jedoch nicht in Worte fassen können, solange wir nur Negativlisten wie z.B. Code-Smells aufführen können, sind wir nicht in der Lage, Qualität zu messen. Wir können bestenfalls die Abwesenheit von Qualität feststellen. Das reicht jedoch nicht.

Daher plädiere ich dafür, bis dahin diese Aufgabe von menschlichen Experten erledigen zu lassen:

Peer Reviews von erfahrenen Entwicklern.

(Und als Nebeneffekt lernen weniger erfahrene Entwickler von den "alten Hasen" etwas.)