Development

Software-ontwikkeling
Mind meld

Mind meld

Systeemontwikkeling is een heel interessant proces van mensen die elkaar continu duidelijk proberen te maken welke kant ze op willen

© CC BY 2.0 - Flickr Eddi van W.
28 augustus 2017

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.

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.

Reactie toevoegen
1
Reacties
Anoniem 30 september 2017 17:20

Het hele gedoe met AI big data data science draait er om dat het NIET deterministisch is. Het is de data die in een iteratie de richting van de logica met een waarschijnlijkheid in een niet natuurlijk / binair getal.