Overslaan en naar de inhoud gaan

Mind meld

Software bouwen lijkt van een afstandje een clean business, een zakelijk, technisch en voorspelbaar proces van requirements opstellen, coderen, testen tegen die requirements en dan opleveren. Ons hele vakgebied probeert deze zakelijkheid en voorspelbaarheid uit te stralen. In mijn hoofd komen altijd twee termen tevoorschijn als ik zo over software bouwen denk: deterministisch en instrumenteel.
Mind meld
© CC BY 2.0 - Flickr
CC BY 2.0 - Flickr

Deterministisch omdat softwareontwikkeling altijd hetzelfde resultaat op zou moeten leveren als je met dezelfde requirements begint. Kans en chaos spelen geen rol. Alles is voorspelbaar. Instrumenteel omdat wij, de uitvoerders van het ontwikkelproces, geen eigen invloed zouden hebben. We zijn alleen maar een instrument, een radertje, in een groter proces. Wat wij willen, wat wij zelf bedenken, ons humeur, onze achtergrond… Het doet er allemaal niet toe. Het enige wat ertoe doet is of wij optimaal functioneren, optimaal de processtappen uitvoeren die wij uit horen te voeren. Anders ontstaan er bugs – anders zijn wij de bugs.

De realiteit is volgens mij nogal anders. Software bouwen zoals ik het ken, is een nogal onvoorspelbaar, chaotisch gebeuren. Het hele softwareontwikkelproces in je eentje uitvoeren zou het best voorspelbaar kunnen maken, maar geen enkel serieus systeem kun je in je eentje bouwen. Dus moet je samenwerken. In dat samenwerken ontstaat onvoorspelbaarheid. Als mensen moeten samenwerken, dan tellen hun ideeën bij elkaar op, dan kunnen ze een groter ding maken dan wanneer ze alleen werken. Maar die bij elkaar opgetelde ideeën zijn ook gedeeltelijk conflicterende ideeën. Iedereen die meedoet heeft ideeën over het te bouwen ding. Om die conflicten te kunnen onderkennen en overwinnen, zullen we moeten communiceren. De vraag is nu of je dat sluitend en formeel kunt doen.

Zolang we programmeurs nodig hebben, moeten we onderkennen dat onze requirements geïnterpreteerd moeten worden en dus niet volledig sluitend en formeel zijn.

Er is volgens mij maar één manier om formeel, volledig en sluitend een systeem te beschrijven en dat is executeerbare code. Als we een manier vinden om requirementsmodellen zodanig formeel en sluitend op te stellen dat er geen programmeur meer nodig is om ze te interpreteren, dan zijn die modellen dus executeerbare code geworden. Dan doen de requirement-engineers dus het werk van de programmeurs (erbij). Zolang we programmeurs nodig hebben, moeten we onderkennen dat onze requirements geïnterpreteerd moeten worden en dus niet volledig sluitend en formeel zijn. De requirements zijn dus nog niet klaar, ze moeten aangevuld worden door de programmeurs en de testers. Daarom moeten we met z’n allen communiceren – en meer dan alleen requirements overdragen.

Sterker nog, we moeten elkaar overtuigen, elkaar beïnvloeden. Dat is volgens mij de essentie van het proces van systeemontwikkeling. Een groep mensen die elkaar moet proberen te beïnvloeden en overtuigen. Overtuigen dat een requirement verstandig is, overtuigen dat het ene design beter is dan het andere, overtuigen dat een testcase anders moet.

Systeemontwikkeling is niet deterministisch en instrumenteel. Systeemontwikkeling is eerder een soort mind meld van een grote groep mensen die elkaar continu duidelijk proberen te maken welke kant ze op willen. Dat is allesbehalve zakelijk en clean, maar daarmee niet minder interessant of effectief.

Gerelateerde artikelen
Gerelateerde artikelen

Reacties

Om een reactie achter te laten is een account vereist.

Inloggen Word abonnee

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in