Martin Fowler vertritt die These, man könne Produktivität nicht messen. Als Physiker sage ich: "I beg to differ Mr Fowler!" Sein zentrales Argument ist, dass es nicht möglich sei das Ergebnis der Softwareentwicklung zu messen. Das erscheint mir dann doch arg fatalistisch. Wir sind in der Lage, Spektralanalysen von Sternen durchzuführen, die wir mit dem bloßen Auge nicht einmal annähernd sehen können, wir messen alles und jeden mit einer Genauigkeit die einfach unvorstellbar ist, aber Softwareentwicklung, oder besser, deren Ergebnis soll unmessbar sein? Wohl kaum. Was sicherlich richtig ist: Es ist schwer Produktivität genau zu messen. Softwareentwicklung ist ein kreativer Prozess und es liegt in der Natur der Sache, dass ein Stück Software nie zweimal unter vergleichbaren Bedingungen erstellt wird. Deswegen wird es wohl in der Tat keine Messung geben der Art, dass der Chef mit einer Art Geigerzähler durch die Büro's läuft und misst wo, denn die Produktivität verloren geht. Ein bisschen mehr Aufwand wird wohl notwendig sein.

Das erste Problem ist die Definition der Produktivität, und dies ist der Punkt, an dem Martin Fowler glaubt zu scheitert. Er macht verschiedene Vorschläge:

• Lines of Code pro Person und Zeit
• Function Points pro Person und Zeit
• Nutzen für den Kunden pro Person und Zeit
• langfristiger Nutzen für den Kunden pro Person und Zeit (hier spielen Wartbarkeit und Anpassbarkeit hinein)

Das ist aber in keiner Weise ein prinzipielles Problem! Es ist einfache eine Frage von: Was will ich eigentlich wissen? Auch um Elektrizität zu messen gibt es verschiedene Ansätze: Spannung, Strom, Leistung, Kapazität ... es ist die Aufgabe dessen, der die Messung vornimmt, zuvor zu bestimmen, was er messen will.

Wenn ich die Produktivität von zwei Programmiersprachen vergleichen will sind Lines Of Code vermutlich ein schlechte Maßeinheit, da sie zwischen zwei Sprachen nicht vergleichbar ist. Aber wenn ich zwei Java IDEs miteinander vergleichen möchte könnte, dies ein sehr einfaches, direktes und aussagekräftiges Maß sein. Wenn ich die Leistungsfähigkeit eines Teams, oder einer Methode beurteilen möchte, dann ist es vermutlich sinnvoll eine ganze Reihe von Maßzahlen zur Beurteilung heranzuziehen. Schließlich wird eine Stromquelle typischerweise auch durch wenigstens zwei Größen (Strom und Spannung) gekennzeichnet. Leider gibt es bisher wenig brauchbare Standards für diese Fragestellung, so dass wohl jeder, der sich für dieses Thema interessiert seine eigenen Maßeinheiten definieren muss.

Ein weiteres Indiz, welches Fowler anführt, als Beleg der Unmessbarkeit von Softwareentwicklung, würde ich als Physiker einfach als statistischen Fehler bezeichnen. Er führt Beispiele an, bei denen verschiedene Function Point Analysen Abweichungen von 300% hatten. Ist doch wunderbar, bei Experimenten im Physikpraktikum zum Foucaultschen Pendel haben einige Gruppen festgestellt, das Bielefeld auf der Südhalbkugel, bzw. jenseits des Nordpols liegen. Ãœber 300% Messfehler hätten wir nur gelächelt. Aber ernsthaft, es gibt ein recht einfaches Mittel gegen solche Fehler: Mehrfach messen. Wenn eine Messung von X vom wahren Wert um d Prozent abweicht, so weicht der Durchschnitt aus n Messungen nur noch um 1/sqrt(d) ab. (Kann man in HTML eigentlich mittlerweile vernünftig Formeln schreiben?) Wenn ich jetzt mal davon ausgehe, dass die 300% Messfehler ein Extremwert ist, und ein typischer Wert, bei -25% bis +50% liegt, so kommt man schon recht schnell in brauchbare Gebiete. Vor allem, da exakte Werte (in welcher Einheit auch immer) meist gar nicht so relevant sind. Meist sind die Fragestellungen ja eher in der Art: Ist Test First, besser als Test last? Ist Agil besser als Wasserfall? Ist Ruby besser als Java? Wenn man eine solche Fragestellung an einigen Projekten untersucht, die sich ansonsten wenig unterscheiden, kommt man mit guter Wahrscheinlichkeit zügig zu einem belastbaren Ergebnis.

ABER, ja leider kommt jetzt doch noch das große ABER. Die Softwarebranche ist noch hochgradig dynamisch. Ständig kommen neue Sprachen, Betriebssysteme, Frameworks, Methoden und dergleichen mehr auf den Markt, so dass zwei Projekte nur selten ausreichend ähnlich sind, um direkte Rückschlüsse auf die Auswirkungen eines Parameters auf die Produktivität zu zu lassen. Eine Analyse wäre nur mit entsprechendem statistischen Aufwand und/oder unter kontrollierten Bedingungen möglich, beides ist in Mittelständischen Unternehmen meist nicht praktikabel.

Als Quintessenz bleibt also Produktivität IST messbar, allerdings werden die Kosten für eine solche Messung häufig als höher als der Nutzen eingeschätzt. Nicht viel besser, aber weniger fatalistisch als die Aussage von Martin Fowler.