Een van de gevolgen van dat principe is dat je nooit iets precies kan meten zonder het te beïnvloeden. Een bekende metafoor daarvoor is het zoeken naar een bal in een donkere kamer. Op de tast kom je vroeger of later de bal tegen, en dan weet je waar die bal was op dat moment. Maar tegelijk weet je niet hoe snel die bal in beweging was, en bovendien heb je, door de bal aan te raken, die snelheid verandert.
Vrijwel alle automatisering is opgebouwd uit ketens van componenten en organisaties, zoals serverhosting, internetproviders en andere online dienstverleners. De beschikbaarheid en respons van de hele keten is afhankelijk van de kwaliteit van elk van de componenten en de organisaties die die componenten beheren. Wil je dus weten hoe de keten presteert, dan moet je kijken hoe elk van de componenten presteert. Echter, door het meten beïnvloed je het resultaat.
Ik heb ergens een sharepointserver staan met een slechte ‘koude start''. De eerste keer dat ik een pagina opvraag doet die er een paar minuten over. Daarna gaat het sneller. Als ik nu elke vijf minuten ga kijken hoe lang het laden van die pagina duurt, zal ik daarom nooit meer een koude start zien. De meting beïnvloedt dus het resultaat.
Een ander voorbeeld. Een niet nader te noemen dienstverlener realiseert met zijn servers meer downtime dan uptime. Om in Limbo-termen te spreken: 'How low can you go?' Klachten er over worden afgewimpeld. Totdat we nauwkeurig gaan waarnemen en de uptime uitdrukken in harde cijfers. Dan blijkt er in een keer wat te gebeuren en schiet de kwaliteit van de dienstverlening omhoog.
Software-ontwikkelaars hebben een speciaal woord voor een bug (fout) die verdwijnt als je hem gaat onderzoeken. Ze noemen het een Heisenbug.
Peter van Eijk is onafhankelijk adviseur (www.digitalinfrastructures.nl).
Om te kunnen beoordelen moet u ingelogd zijn: