Klaar?

Hoe bepaalt de schilder dat zijn schilderij áf is? Wanneer hij het schilderij zat is? Wanneer er een klant langs loopt en zegt “Die wil ik kopen!”? Er zijn ook schilders die in een paar uur een doek vol met verf kwakken en dan roepen “Zo, die is klaar. Daar kan ik niets meer aan verbeteren!”

Ik zoek metaforen, omdat ik aan leken moet kunnen uitleggen hoe wij werken

Ik ben al jaren op zoek naar geschikte metaforen voor ons werk. Ik zoek metaforen, omdat ik aan leken moet kunnen uitleggen hoe wij werken, hoe het is om een systeem te bouwen. Die leken, dat zijn niet zozeer m’n moeder of mensen op verjaardagsfeestjes, maar onze gebruikers of opdrachtgevers. Zij hebben vaak genoeg geen clou van hoe we werken. Als ze daar al een idee van hebben, is dat meestal een verkeerd idee – met alle nare gevolgen van dien. Meestal denkt men dat systemen bouwen iets heel erg deterministisch en voorspelbaars is. “Je stopt er requirements in en er komt code uit”.

Een voorbeeld van zo’n metafoor is ‘pannenkoeken bakken’. Systemen bouwen is als pannenkoeken bakken. De eerste mislukt altijd. Dat hoort gewoon zo. Je moet een opdrachtgever uitleggen dat hij vooral ook om de eerste pannenkoek moet vragen – een eerste ruwe versie van een systeem. Die eerste pannenkoek is nodig om samen te leren hoe het daarna verder moet.

Zo’n metafoor past natuurlijk nooit helemaal. Ons vak is nogal anders dan alle andere vakken. Ik ben vooral op zoek naar metaforen die de complexiteit en het onvoorspelbare van ons werk begrijpelijk maken. “Software bouwen is als huizen bouwen. Je begint bij het fundament” – dat vind ik een flauwe en vooral ook incorrecte metafoor. Wij hebben geen last van zwaartekracht. Ik kan net zo goed beginnen met het programmeren van het zolderraam. De interessantste metaforen laten vooral feedbackprocessen zien. Die gaan ‘van achteren naar voren’. Daarom wil ik beginnen bij de allerlaatste en allerbelangrijkste vraag in het ontwikkelproces: is het systeem klaar?

Het is nóóit klaar!

Dat is ook de meest giftige vraag in ons vakgebied. Het is nóóit klaar! Iedereen vindt er iets anders van. Het is als allemaal schilders die samen moeten bedenken of het schilderij klaar is. We hebben vooraf wel een minimum viable product en een definition of done bedacht, maar daarmee raken we alleen maar de meest basale aspecten. Alle features zijn getest en gedocumenteerd en de code is technisch gezien goed, maar is dít nu de versie die we moeten gaan opleveren? Moet die ene bug niet toch gefixt? Moeten we niet toch nog wat meer testen? Moet er ondanks die minimum viable product niet nog iets bij – of juist áf?

Net als bij schilders kun je vol bravoure roepen dat het helemaal af is, of je kunt eeuwig blijven frunniken aan het systeem. In de praktijk is het de klant die het beu is, de tijd die op is of de ontwikkelaars die het zat zijn. Klaar is klaar!