De bouwmetafoor gaat niet eens op voor de bouw

Software ontwikkelen is niet hetzelfde als een huis bouwen, betoogde ik onlangs in een lightning talk.¹

De bouwmetafoor suggereert dat architecten verantwoordelijk zijn voor het ontwerp, ontwikkelaars voor de uitvoer, en testers voor de inspectie. Het suggereert bovendien een lineair proces, waarin het hele gebouw eerst wordt ontworpen, daarna wordt gebouwd, en pas uiteindelijk wordt geïnspecteerd.

Mentaal model

Althans, dat is het mentale model van huizenbouw zoals het in mijn hoofd leefde. Maar, wezen mijn collega’s me terecht, dat is helemaal niet hoe huizen worden gebouwd – nu niet meer, in elk geval. De bouw anno nu heeft veel ideeën uit agile en lean geïncorporeerd en heeft daarom tegenwoordig – grappig genoeg – meer weg van softwareontwikkeling dan je zou verwachten.

Dus niet alleen softwareontwikkeling is niet als het bouwen van een huis – zelfs het bouwen van een huis blijkt niet als het bouwen van een huis!

Dat wijst ons op een interessante eigenschap van mentale modellen: ze kunnen volslagen losgezongen blijken van de realiteit – en zonder dat we het doorhebben bovendien. Het probleem met de “bouw”-metafoor is dus niet dat we softwareontwikkeling vorm proberen te geven als een constructieproces. Het is veeleer: dat we softwareontwikkeling vorm proberen te als het beeld dat wij hebben van eenconstructieproces. Maar dat dat beeld overeenstemt met de werkelijkheid, kan zomaar een aanname blijken te zijn die weinig met de feitelijke werkelijkheid te maken heeft.

Fictie dicteert

Dat betekent niet dat het niet zinvol is om dat beeld van de werkelijkheid te bekritiseren. Immers, hoe de bouw zichzelf daadwerkelijk organiseert hoeft in principe geen enkele invloed te hebben op de manier waarop we softwareontwikkeling organiseren – zelfs wanneer we denken ons te baseren op het model van de bouw.

De ideeën uit de “bouw”-metafoor – een scheiding van ontwerp- en bouwverantwoordelijkheden en een gefaseerde aanpak – hebben nog steeds invloed op de manier waarop we ons werk organiseren. Er bestaan nog steeds managers die een waterval-proces proberen op te dringen aan hun ontwikkelteams. En er bestaan nog genoeg teams die daar – schoorvoetend? – mee akkoord gaan, omdat ze niet aan kunnen geven waarom die ideeën niet passen op de praktijk van softwareontwikkeling.

Maar het is niet zo dat het management altijd de schuldige is hier. Die ideeën kunnen net zo goed uit de teams zelf komen, als deze erop staan dat er pas ontwikkeld kan worden als er (scherm)ontwerpen zijn gemaakt, en er pas kan worden getest als de feature in code is omgezet. (Zie bijvoorbeeld deze blog.)

Een fictie dicteert in zulke gevallen de werkelijkheid. En wie die fictie bestrijdt, is dus niet per se een Don Quichot die windmolens bedwingt (– al voelde ik me na afloop van mijn lightning talk wel zo!).

Nederigheid

Socrates meende dat het kwaad voortkomt uit onwetendheid. Nu klinkt “het kwaad” in deze context wel heel erg bombastisch, maar het is inderdaad onwetendheid – in dit geval: van hoe huizen daadwerkelijk gebouwd worden – die ons op een spoor zet om inefficiënte ontwikkelmethoden te volgen.

Niet voor niets zei diezelfde Griekse wijsgeer: “Ik weet dat ik niets weet.” (Zie ook deze blog.) Die nederigheid voorkomt dat je al te stellige uitspraken zult doen over hoe je softwareontwikkeling vorm dient te geven.

Het is te hopen dat die Socratische wijsheid me in de toekomst wat terughoudender te maken al te stellig metaforen uit te werken waar ik maar bar weinig van afweet.

aannames · agile ontwikkeling · feedback · leermoment · mentaal model · presenteren