
Software bouwen is iets dat zich grotendeels in onze hoofden afspeelt. Zolang het nog niet gebouwd is, is er niets van te zien, niets van te voelen. Alles zit alleen nog maar in ons hoofd. Daarbij komt het probleem dat je zelden in je eentje software bouwt. Meestal is het gewoon te ingewikkeld en te groot. Dus bouw je samen. Maar als software iets is dat in je hoofd zit? Hoe gaat dat dan met meerdere hoofden? Dan moeten we dus communiceren. Zorgen dat mijn ideeën over de te maken software in de pas lopen met jouw ideeën. We schrijven requirements en we maken modellen. En we praten heel veel.
Requirements schrijven we meestal in gewone taal. Dat werkt goed voor requirements. Taal heeft de zeggingskracht die je bij requirements nodig hebt. "Het systeem zal opstarten met een loginscherm"; daar is geen woord Spaans aan. Modellen zitten anders in elkaar. Met modellen proberen we abstracte constructies te beschrijven, constructies die niet zomaar met een (Nederlands) woord te vangen zijn. Bovendien proberen we gebruik te maken van het "een plaatje zegt meer dan duizend woorden" – adagium. Helaas zegt hetzelfde plaatje vaak meer dan duizend verschillende woorden voor verschillende toeschouwers. Om dat te vermijden gebruiken formele modelleertalen.
Die formele modellen (UML, BPMN, ArchiMate, ...) hebben natuurlijk alleen maar nut wanneer je met mensen communiceert die de taal ook kennen. Dat is niet altijd het geval. Voor mensen die geen formele modelleertalen kennen (opdrachtgevers, gebruikers, managers, ...) wil je 'plaatjes' gebruiken. Formele modellen werken daarbij averechts. Leken – dat klinkt wat denigrerend, maar ik heb even geen beter woord – willen andere dingen zien dan softwarebouwers. Ze willen zien wat het meest complexe onderdeel is, in welke volgorde er gebouwd gaat worden, welk onderdeel hergebruikt gaat worden, waar de problemen zitten, ... Leken willen niet weten dat component A een interface aanbiedt en dat component B daar gebruik van maakt.
Misschien moeten we de plaatjes die we voor de leken maken maar geen 'modellen' noemen. Het zijn informele plaatjes, ze missen het gestructureerde van echte modellen. Misschien is 'visualisaties' een beter woord. Ik heb altijd wel lol in het maken van dergelijke 'visualisaties'. Ik vind ook dat je daar best wat energie in mag steken. Vaak worden ze gebruikt om met de belangrijkste partijen in en rondom het project te communiceren. Daar mag je best wat tijd aan besteden. Dat verdien je dubbel en dwars terug. Ik vind ook dat je creatief mag zijn met zulke platen, dat je ze echt mooi moet maken. Zo loop ik al een hele tijd rond met het plan om een pop-up boek te maken om een architectuur mee te visualiseren. Zo'n boek dat je openvouwt en dan vouwt een plaat zich in 3D uit. Dat lijkt me geweldig, een architectuur in pop-up vorm. Het blijkt alleen heel veel werk te zijn. Gruwelijk veel. Ik krijg het maar niet rond.
Vorige week kwam een collega ineens aan met een 3D-visualisatie. Had hij even in Google SketchUp gemaakt. Ik had natuurlijk wel eens gehoord van SketchUp, maar had nog niet de moeite genomen om er eens achter te gaan zitten (ja, ik loop wat achter). Ik had wel andere 3D-tools geprobeerd, maar dat leverde meestal net zo veel werk op als een pop-up book. SketchUp is zo veel makkelijker. Daarmee kun je inderdaad in een uurtje een hele mooie plaat maken. Je kunt zelfs een filmpje genereren waarin je door een 3D-ruimte heen beweegt. 3D levert zo veel meer mogelijkheden op, het maakt je platen zo veel mooier. Voor mij de komende even geen UML, ArchiMate of SysML, ... Ik ga aan de 3D.