Don’t believe the model, don’t ignore the model

Blinde vlekken

Het gevaar van selectieve waarneming

Een goede raad: don’t believe the model: de werkelijkheid is altijd anders, rijker, gedetailleerder, genuanceerder en veelkleuriger. Nog een goede raad: don’t ignore the model, want goede modellen doen uitspraken over een stukje van de werkelijkheid, uitspraken die in veel gevallen waar zijn.
Vooral de combinatie van deze adviezen is waardevol: zonder het eerste advies is de verleiding groot het tweede in te korten tot: ‘modellen doen uitspraken over de werkelijkheid die waar zijn’. Samen geven ze het evenwicht dat het mogelijk maakt beschikbare modellen te onderzoeken en ze zinvol toe te passen als de situatie zich daarvoor leent.

Zoals de IT haar eigen modellen kent zo kennen ook andere disciplines hun eigen modellen. Dat zijn modellen die uitspraken doen die we niet zonder meer mogen vertalen naar ons vakgebied. Als we echter rekening houden met het ‘don’t believe’, dan kunnen we er op een verantwoorde manier van profiteren. In deze voorlopig laatste aflevering behandel ik nu eens geen modellen uit andere disciplines. In plaats daarvan is er aandacht voor het verstandig gebruiken van modellen uit onze eigen IT-discipline.

Kleine hoekjes, grote ongelukken

Stel, je hebt een applicatie die met drie seconden vertraging een actie moet uitvoeren. En opeens, ergens in oktober, duurt het een keer ruim een uur. Als goede IT’er beginnen we met tegen de betreffende gebruiker te zeggen dat ‘dat niet kan’ — die gebruiker heeft het net meegemaakt, maar dat deert ons niet. Ook na lang zoeken en honderd keer proberen hebben we nog steeds geen oorzaak gevonden. Tot we horen dat het speelde om drie uur ’s nachts; toen de wintertijd inging, en de klok een uur terug moest. We realiseren ons dat de systeemklok automatisch werd teruggezet, waarna we de gebruiker kunnen uitleggen dat de schuld in Redmond ligt.

En stel, je hebt een satelliet die iets moet laten vallen in de atmosfeer van een verre planeet. Dat iets seint informatie over de atmosfeer naar de satelliet, die het vervolgens weer doorstuurt naar moeder Aarde. Ergens vergeet iemand rekening te houden met het dopplereffect. Door de grote zwaartekracht is de snelheid waarmee het iets door de atmosfeer valt zó groot dat de signalen naar de satelliet er ernstig door vervormd raken. Al met al is het effect dat er niets op aarde aankomt. Hoe leg je dat aan een gebruiker uit?

Sinds de film Forrest Gump kunnen we dergelijke zaken kort samenvatten: ‘shit happens’. Maar wat doen we eraan?

Projectmanagement is de afwas doen

Het huishouden als model voor het managen van IT-projecten. Boodschappen doen, eten koken, de afwas doen, bedden verschonen, de was doen, strijken, de badkamer en het toilet schoonmaken. En morgen en overmorgen weer, tot je er moedeloos van wordt. Veel werk en, behalve zo nu en dan een bloemetje op vrijdagmiddag, weinig applaus.

CMM, het Capability Maturity Model (Paulk, 1994), beschrijft vijf levels, niveaus van professionaliteit. Om op level 2 te functioneren moeten zes processen ‘op orde’ zijn. Drie daarvan zou je de primaire processen van projectmanagement kunnen noemen: het beheer van eisen en wensen, het planningsproces en de voortgangsbewaking. Daarnaast zijn er nog drie: kwaliteitszorg, configuratiemanagement en subcontractmanagement. Als deze processen adequaat zijn ingericht, is er sprake van een ontwikkelorganisatie die ‘het huis op orde heeft’: de afwas wordt op tijd gedaan, er is wat te eten in huis en je glijdt niet uit in de badkamer.

Het vervelende van het huis op orde houden, is dat het huis op orde hebben niet betekent dat het verder een fluitje van een cent is. Iedereen die regelmatig huishoudelijk werk doet, kan haarfijn uitleggen dat het huis op orde houden hard werken is om op dezelfde plaats te blijven. (Zie ook het kader ‘Het Rode-Koningineffect‘.)

Het CMM is een goed model. Waarmee ik bedoel dat het behulpzaam kan zijn bij pogingen de kwaliteit van het ontwikkelproces in een organisatie te verbeteren. Wat mij betreft is het een model waarvoor het ‘don’t ignore’ harder moet worden benadrukt dat het ‘don’t believe’.

Ik voelde mij dan ook nogal zeker van mijn zaak toen ik onlangs bij een presentatie over de verbetering van het ontwikkelproces het bereiken van CMM level 2 boven aan het prioriteitenlijstje zette (voor organisaties die zich nog op level 1 bevinden uiteraard). Met als credo: je moet eerst je huis op orde hebben, en zorgen dat je het op orde houdt, alvorens het eigenlijke ontwikkelproces succesvol — dat wil zeggen: blijvend — kan worden verbeterd.

(Ver)blind

Een al te groot vertrouwen in een model leidt echter tot selectieve waarneming: wat niet in het model past, zie je niet meer. Gelukkig zat er bij de presentatie iemand in het publiek die me vroeg of ik wel eens van de ‘blinde vlek van Winograd’ had gehoord. Ik had daar nog nooit van gehoord, en het boek waaraan hij refereerde (Winograd and Flores, 1986) is zo moeilijk toegankelijk dat ik het er nog niet op nagelezen heb.¹ Dat maakte de boodschap evenwel niet minder helder: je kunt in je ontwikkelproces verbeteren wat je wil, maar de grote ongelukken waarmee dit artikel begon, voorkóm je er niet mee. Blinde vlekken zijn de oorzaak van dat soort ongelukken: er is gewoon niet aan gedacht; om de een of andere reden is het aan de aandacht ontsnapt.

Communiceren als remedie

Communiceren met anderen is het enige wat je in staat stelt je eigen blinde vlek te ontwijken. Een heel praktische uitwerking daarvan is ‘pair programming’. In hun artikel ‘All I Really Need to know about Pair Programming I Learned in Kindergarten’ beschrijven Laurie Williams en Robert Kessler de praktische uitwerking van deze manier van werken. In pair programming ontwerpen, coderen en testen twee programmeurs gezamenlijk hun programma’s. Gezamenlijk is écht gezamenlijk. Niet één persoon coderen en de ander testen, nee, gezamenlijk achter het scherm, de een meekijkend terwijl de ander de statements invoert. Onderzoek heeft aangetoond dat deze aanpak sneller en efficiënter is, dat de opgeleverde code nagenoeg foutloos en ook anderszins kwalitatief beter was, en, last but not least, dat 96 procent van de programmeurs hun werk op deze manier leuker vond.

Groupthink

Blinde vlekken zijn helaas niet beperkt tot individuen. Ook in groepen ontsnappen zaken soms aan de aandacht. Soms neemt dat vormen aan die beter onder woorden gebracht worden met ‘niet willen zien’ dan met ‘niet zien’, een fenomeen dat bekend is onder de naam groupthink (Janis, 1972), Blind vertrouwen in een model als CMM en denken dat je er bent als je weer een niveau hoger zit, zou een vorm van groupthink kunnen zijn.

Mensen in je buurt die je attent maken op je eigen selectieve waarneming, gecombineerd met je eigen bereidheid goed naar deze mensen te luisteren, kunnen voorkomen dat je in deze kuil valt. Dan behouden modellen hun waarde en blijft ‘don’t ignore the model’ een zinvol advies!

Literatuur

Janis, I.R.. Victims of group-think. Boston, Houghton Mifflin, 1972.
Paulk, Mark C., e.a.. The Capability maturity model: Guidelines for improving the software process, Addison-Wesley, 1994, ISBN 0 201 546647
Williams, Laurie A. and Robert R. Kessler. 'All I Really Need to know about Pair Programming I Learned in Kindergarten', In: Communications of the ACM, mei 2000 (Vol. 43. No. 5).
Winograd, Terry and Fernando Flores: Understanding computers and cognition: A new foundation for design, Norwood, NJ, Ablex, 1986.

Noot

1. Zie voor een samenvatting www.cpsc.ucalgary.ca/~robertof/excerpts/WinogradFlores1987.html. [404, WL, 20081224]

oorspronkelijke publicatie: Wil Leeuwis, in: informatie, december 2000, p. 45-47. © 2000, informatie.