Er wordt vaak een vergelijk gemaakt tussen bruggenbouw en de ontwikkeling van computerprogramma’s. De vergelijking komt doorgaans neer op de vraag waarom bruggenbouw wel altijd goed gaat en softwareontwikkeling zo vaak fout gaat. De aanname voor deze vergelijking is dat het in beide gevallen om een moeilijk product gaat. Laten we dit eens beter bekijken.
Ten eerste is de constatering terecht. Bruggenbouw levert vrijwel altijd een correct werkende brug op. Deze is niet altijd binnen budget, maar hij functioneert in elk geval. Softwareontwikkeling levert inderdaad zeer vaak een product op dat niet goed werkt, dat niet doet wat je nodig hebt, of dat een veelvoud heeft gekost van wat er initieel afgesproken is. De vraag waarom softwareontwikkeling het betrouwbaarheidsniveau van bruggenbouw niet haalt lijkt dus legitiem.
De nadruk ligt echter op lijkt, want hoewel beide producten voldoende complexiteit bevatten, zijn er wel wezenlijke verschillen. In het geval van bruggenbouw gaat het om een in essentie zeer eenvoudige gebruikersinterface. Er is een weg over een verdieping heen en aan de voor- en achterkant is het in vaste grond verankerd. Wanneer de afspraken zijn gemaakt en de technici aan de klus beginnen, is er doorgaans niets wat in het omveld veranderd waardoor de initiële vraag van de opdrachtgever wijzigt. Het is niet zo dat er ineens een berg in het dal onder de brug verrijst. Het is niet zo dat er eerst auto’s overheen moesten en nu ineens ook kuddes olifanten erover heen moeten kunnen. Het is ook niet zo dat je eerst over de rivier heen moest kunnen gaan en nu ineens de rivier in lengterichting moet kunnen begaan via de brug. Het is ook niet zo dat je eerst alleen een rivier moest overbruggen en nu ineens ook een 3 kilometer verderop gelegen dal moet overbruggen met dezelfde brug.
Vergeleken met softwareontwikkeling is de vraag bij bruggenbouw zeer constant. Wanneer de afspraken zijn gemaakt en de tekening klaar is, is het in essentie alleen nog een technisch proces tot aan voltooiing, behoudens problemen met de ondergrond waar de technici tegen aan kunnen lopen. Bij softwareontwikkeling gaat het om een heel andere dynamiek. Gedurende de opdrachtformulering, het ontwerp, de bouw en gedurende het gehele gebruik van een softwaresysteem gaat het om een samenspel tussen mens, techniek en de businessomgeving.
Techniek wordt vaak gezien als een middel tot een doel. Maar dit klopt niet, zeker niet in het geval van softwareontwikkeling. Techniek kan zijn belofte van efficiency, winst, vergroting van gemak, of standaardisatie van processen alleen waarmaken wanneer het op een specifieke manier wordt toegepast en wanneer er op een specifieke manier mee wordt omgegaan. Ernst Jünger noemde dit de Typus der Techniek, ofwel de essentie van techniek. Deze essentie draait om nutsdenken, de wereld als resource zien, standaardisatie van alles, massaliseren, efficiency-denken, en dergelijke zaken. Doordat het allen binnen die mindset functioneert, is techniek zelf een acterend en eisen opleggende speler. Of zoals Heidegger zei, techniek is zelf een Gestell. Zo zijn mensen anders gaan communiceren sinds de introductie van mobiele telefoons en apps. We sturen elkaar korte, staccato berichten, nemen genoegen met een fractie van non-verbale communicatie, en hebben een kortere attention span ontwikkeld. Dit is alles een gevolg van de eisen die techniek ons opleggen door onze wens om de gemakken ervan te gebruiken.
De businessomgeving kan een verandering in de opdrachtformulering opleveren omdat de marktomstandigheden verandert zijn, omdat er een andere strategische koers moet worden gevaren, omdat een concurrent iets op de markt zet waar je op moet reageren, enz. De businessomgeving oefent dus een actieve invloed uit op het samenspel.
De derde factor in het samenspel is de mens. Het leven van een mens is geen rechte lijn van de wieg tot aan het graf. Houdingen, voorkeuren, wensen, eigenschappen, gemoedstoestand, en de mindset zijn zaken die zowel in het privéleven als op het werk kunnen veranderen in de loop van de tijd.
Deze drie factoren werken op elkaar in op een manier die je in bruggenbouw niet ziet. En wie bekend in met nonlineaire dynamiek, die weet dat een interactie van drie acterende entiteiten een onvoorspelbare, en semi-chaotische situatie oplevert. Softwareontwikkeling is op geen enkel moment alleen een technisch proces. De nonlineaire dynamiek van dit samenspel tussen mens, techniek en businessomgeving levert een proces op dat op geen enkel moment vastligt. De opkomst van Agile is een antwoord op het onvermogen van statische methoden om hier grip op te krijgen. En hoewel Agile een noodzakelijke verbetering is, komt ook Agile voort uit een onbekendheid met de Typus der Technik enerzijds en nonlineaire dynamiek anderzijds.
Wie in zijn organisatie softwareontwikkeling echt wil leren beheersen zal de beide laatstgenoemde factoren moeten leren begrijpen. Hier is geen weg omheen. Alleen de beheersing van de essentie van technik en nonlineaire dynamiek kan leiden tot beheersing van kosten, beheersing van opleverdata, beheersing van kwaliteitsprocessen, en beheersing van planning. Het lijkt vreemd om als organisatie met deze zaken aan de slag te gaan, en het is zeker onbekend terrein voor een organisatie, maar de noodzaak tot beheersing laat weinig alternatieven open.
