Der Unsinn der 'Lines of Code' - Eine Argumentationshilfe

Bild: Max Pixel - CC0 1.0

Eigentlich mag man es kaum glauben, aber bis heute gibt es noch Manager die es für eine gute Idee halten den Outcome von Entwicklern an geschriebenen Code-Zeilen (Lines of Code) zu messen. Das ist natürlich Unsinn, gefährlicher Unsinn sogar, jeder Entwickler wird das bestätigen. Das Problem: die Manager die diese Messungen durchführen wollen haben in der Regel keinen echten IT-Hintergrund und können die von Entwicklern vorgebrachten Argumente nicht nachvollziehen. Eine Übersetzung ist notwendig, z.B. diese hier.

Stellen wir uns die Lines of Code wie Baumstämme vor, die zum Bau von Blockhäusern verwandt werden. Das fertige Blockhaus entspricht in diesem Fall der zu bauenden Anwendung. Nun könnte man natürlich so argumentieren: je mehr Baumstämme ein Bautrupp verbaut, desto schneller ist das Haus fertig. Diese Zahl nach oben zu treiben ist also scheinbar sinnvoll. Eine Einschränkung müssen wir dem Bautrupp-Leiter (Manager) allerdings mitgeben - genau wie er von der Software-Anwendung nur die Oberfläche sieht, wird er von dem Haus nur die Aussenseite sehen. Wie es innen aussieht weiss er nicht. Und mit diesem Wissen schauen wir uns einige mögliche Blockhäuser einmal näher an.

• Haus I besteht aus je zwei Seitenwänden zu je 10 Stämmen, zwei Giebelwänden zu je 14 Stämmen und einem Dachstuhl aus 12 Stämmen, in Summe sind hier also 60 Stämme verbaut.
• Haus II ist eigentlich baugleich zu Haus I, allerdings sind die Wände an den Ecken des Hauses nicht richtig zusammengebaut, wodurch sie sich nicht mehr gegenseitig gerade halten. Um sie zu stabilisieren werden sie von innen durch diagonale Balken gestützt, wodurch in Summe 68 Stämme verbaut wurden.
• Haus III entspricht weitestgehend auch Haus I, wurde von seinem Bautrupp aber durch eine Innenwand geteilt. Das stand so nicht im Bauplan, erschien dem Team aber irgendwie sinnvoll. Verbaut wurden 70 Stämme.
• Haus IV wurde mit doppelt so dicken Wänden gebaut, jede Wand ist also zwei Baumstämme dick. Immerhin der Dachstuhl bleibt einfach, im Haus wurden also "nur" 108 Stämme verbaut.
• Haus V ist nicht benutzbar. Um die Vorgaben zu erfüllen und möglichst viele Stämme zu verbauen wurde der gesamte Innenraum mit ihnen zugestapelt. 200 Stämme fügen sich zu einem massiven, hausförmigen Block.

Man könnte die Beispiele fortführen, es ist aber auch so klar worum es geht. Obwohl in Haus I die wenigsten Stämme verbaut wurden ist es am besten konstruiert worden - Haus II ist instabil und notdürftig stabilisiert, Haus III hat die nicht benötigte Innenwand, bei Haus IV hätte man mit halb so viel Material ein genau so gutes Ergebnis erzielt, Haus V ist einfach nur unsinnig.

Das beste Vorgehen wäre es in diesem Fall gewesen nicht die Anzahl der verbauten Stämme zu messen sondern zu überlegen wie mit möglichst wenig Material ein stabiles und nutzbares Gebäude erstellt werden kann. Und an dieser Stelle beenden wir die Analogie und kommen zurück zu den Lines of Code, bei denen es sich genauso verhält. Es bleibt die Frage: wie soll ein Manager ohne IT-Hintergrund erkennen ob eine Anwendung gleichzeitig schlank, stabil und benutzbar ist? Vielleicht kann er das gar nicht? Nun, wenn das so ist soll er das Urteil darüber anderen Leuten überlassen. Mit dem Erheben sinnloser und kontraproduktiver Metriken hilft er jedenfalls niemandem.