De afgelopen jaren heb ik me menigmaal verbaasd over sommige metrieken die binnen bedrijven worden gegenereerd. Niet zozeer over de metrieken zelf, maar wel over de schijnzekerheid die hiermee wordt gecreëerd. Zo werden er bij een van de projecten waar ik voor werkte, metingen gedaan naar het aantal regels code dat een programmeur per tijdseenheid maakte. Eén afdeling stak met kop en schouders boven de rest uit. Wat bleek: daar werkten ze met modelleertalen en genereerden ze hun code vanuit modellen. Deze gegenereerde code werd ook meegenomen in de metingen, wat het verschil verklaarde.
Een andere afdeling deed metingen in hoeverre ze voldeed aan codeerstandaarden. Het aantal mismatches met de standaard werd afgezet tegen het totaal aantal regels code. Hieruit volgde een kwaliteitscoëfficiënt. Het totaal aantal regels code omvatte behalve echte code echter ook commentaar en lege regels. Een briljante constructie: je kon de kwaliteit van de code verbeteren door lege regels toe te voegen.
Een derde type meting betreft de volwassenheid van een softwareproduct gebaseerd op het aantal openstaande problemen. De creativiteit die projecten laten zien om deze meting te beïnvloeden, is bewonderenswaardig. Clusteren van problemen (’als we van deze vijf problemen nu één probleem maken‘) of afmelden van problemen terwijl ze nog niet zijn doorgeleverd naar de eindversie levert snelle winst op in de meting. En het houdt de manager tevreden.
Bovenstaande voorbeelden hebben een overeenkomstig aspect: het behalen van de target is een doel op zich geworden. Management stuurt zeer zwaar op de getallen, zonder te kijken hoe ze tot stand zijn gekomen. Ontwikkelaars en teamleiders worden steeds creatiever in het manipuleren van de brondata teneinde de targets te behalen en daarmee het management tevreden te houden. Hiermee wordt voor managers een schijnzekerheid gecreëerd. Ze vertrouwen blindelings op de metrieken die ze krijgen aangeleverd.
Vanuit het configuratiemanagement hebben we afgelopen jaren een aantal verbeteringen aan weten te brengen in betrouwbaarheid van bovenstaande metrieken. Door af en toe een audit te doen op de probleemadministratie en te controleren of opgeloste problemen ook echt zijn geleverd, hebben we een bijdrage kunnen leveren aan het beter gebruiken van deze metriek. Op basis van onze inzichten in de broncode in de CM-archieven hebben we daarnaast de filters voor het meten van productiviteit en codekwaliteit aangepast, zodat ook deze metingen van grotere toegevoegde waarde zijn geworden.
Eens te meer blijkt: meten is weten. Maar als je niet weet wat je meet, dan meet je slechts schone schijn.