Beim Einsatz von Maßen gibt es eine Reihe von Schwierigkeiten, von denen einige fundamental sind, andere jedoch nur durch schlampiges Vorgehen zustandekommen. Zu letzterer Klasse gehören die Verwendung schlecht definierter Maße und die unzulässige Übertragung oder falsche Interpretation von Ergebnissen. Fundamentale Probleme sind hingegen die Nichtverfügbarkeit geeigneter Maße oder die Nichtverfügbarkeit der Eingabedaten für geeignete Maße. Diese Probleme diskutieren wir jetzt im einzelnen.
Eine Methode, sich sehr schnell in Schwierigkeiten zu bringen, besteht darin, Maße zu verwenden, ohne sie exakt zu definieren. Das beste Beispiel hierfür ist zweifellos Lines of Code. Die Zahlen, die bei Maßen mit Intervall- und höheren Skalen als Meßwerte entstehen, drängen ein Vergleichen verschiedener Messungen ja förmlich auf. Dabei muß man aber beachten, daß die Vergleichbarkeit im Hinblick auf das, was man aus der Messung an Information gewinnen möchte, eben oftmals nicht gegeben ist. So ist es weitgehend sinnlos, Programmgrößen verschiedener Programmierer zu vergleichen, solange nicht geklärt ist, ob und wie weit die Zählung der Programmzeilen vom Layout des Programms abhängt, wie Leerzeilen, Fastleerzeilen und Kommentarzeilen gezählt werden etc.
Ohne eine genaue Definition geht also alles schief, mit einer Definition muß man eventuell die Interpretation der Meßwerte ändern. So messen Lines of Code mit Ignorieren von Leerzeilen, Fastleerzeilen und Kommentaren so etwas wie die Länge des Programmtextes, beim Mitzählen der Kommentare so etwas wie die Länge Programmtextes plus seiner Erläuterung (wobei Trennzeilen aus lauter Sternchen oder Strichen Schwierigkeiten machen), und beim Mitzählen auch der Leerzeilen und Fastleerzeilen ist das Ergebnis kaum noch sinnvoll interpretierbar.
Ebenso sinnlos wie das Messen ohne genaue Definition des Maßes ist das Vergleichen von Meßwerten, die aus nicht direkt vergleichbaren Verhältnissen stammen. Zum Beispiel nützen mir auch noch so wunderbar wohldefinierte Produktivitätsmessungen aus der Entwicklung eines WWW-Browsers rein gar nichts, wenn meine Aufgabe lautet, die Produktivität bei der Herstellung einer Fabriksteuerung vorherzusagen oder zu beurteilen. Dennoch werden genau solche Übertragungen (nur meist nicht ganz so offensichtlich) ständig gemacht -- am liebsten in Kombination mit der Verwendung ungenau definierter Maße.
Der dritte Fehler aus der Kategorie ,,Schlamperei`` bei Softwaremaßen besteht in einer unzulässigen Interpretation von Meßergebnissen. Das dramatischste Beispiel in dieser Hinsicht ist der Begriff der Produktivität. Drückt man Produktivität zum Beispiel, wie es sehr oft geschieht, in erstellten Programmzeilen pro Zeit aus, so werden die Programmierer zu einer Reihe von ganz fürchterlichen Verhaltensweisen animiert (insofern an ihre Produktivität irgendwelche Anreize oder Bestrafungen gekoppelt sind). Produktivität wird aber korrekterweise am erzeugten Nutzen (oder Wert) pro Zeit bemessen. Ein richtiges Maß wäre also beispielsweise ,,Vom Endkunden erwünschte Funktionalität pro Zeit``. Die Identifikation von Programmzeilen pro Zeit mit Produktivität ist eine Fehlinterpretation des Maßes. Siehe auch die Diskussion in Abschnitt 6.5.2.
Dies ist das erste fundamentale Problem beim Einsatz von Maßen: Für viele Größen, von deren Relevanz man überzeugt ist, gibt es auch nach jahrzehntelanger Suche noch keine Maße, die sich prozedural formulieren ließen. So wird beispielsweise seit langem nach einem Maß gesucht, das die Komplexität eines Programmstücks oder eines Moduls beschreibt. Von allen bisher vorgeschlagenen Maßen für diesen Zweck ist jedoch bekannt, daß sie eine solche Auskunft allenfalls für eine sehr eingeschränkte Klasse von Programmen geben, deren Einhaltung man wiederum meist nicht automatisch prüfen kann. Ein anderes Beispiel ist die Funktionalität, deren quantitative Beschreibung außerordentlich schwierig ist, aber eine Voraussetzung dafür wäre, ein sinnvolles Produktivitätsmaß zu erhalten. Funktionspunkte liefern hierfür eine gute Teillösung, die aber leider nur für betriebswirtschaftliche und ähnliche Anwendungen zu gebrauchen ist. Die Suche nach aussagekräftigen Maßen ist nach wie vor ein Forschungsthema.
Das zweite fundamentale Problem besteht darin, daß man viele sinnvolle indirekte Maße zwar bequem formulieren kann, jedoch die Zwischendaten fehlen, um sie zu berechnen. Diese Schwierigkeit tritt in drei Formen auf: Zum einen gibt es Maße, für die es einfach einen sehr großen Aufwand verursacht, sie auszuwerten, z.B die Häufigkeit und Art mündlicher Anfragen eines Softwareingenieurs bei Kollegen.
Zum anderen, und dies ist der häufigere Fall, gibt es oftmals Maße, die nützlich wären, deren Eingabedaten aber erst zu spät verfügbar werden. Beispielsweise ist die Zahl von bei Auslieferung noch in einem Programm verbliebener und später in Erscheinung getretener Fehler grundsätzlich erst am Ende der Einsatzdauer der Software, also nach mehreren Jahren, zu ermitteln, wenn das Interesse an dieser Information bereits gering geworden ist, weil die betroffenen Programmierer inzwischen dazugelernt haben, die betroffenen Prozesse schon verbessert worden sind und die betroffenen Werkzeuge und Methoden teilweise gar nicht mehr eingesetzt werden.
Drittens gibt es Maße, die man zwar konzeptionell klar definieren kann, die sich aber grundsätzlich überhaupt nicht berechnen lassen, z.B. die Anzahl von Fehlern in einem Programm, die bei Auslieferung noch vorhandenen sind.