Software – robuustheid

Ik vroeg me zopas eens af waarom het nu toch zo is dat er op zoveel plaatsen nog steeds zoveel problemen met software zijn. Of het nu gaat om een Tesla, Boeing, de metro naar Hoek van Holland, het UWV, de Belastingdienst of nog hele ritsen organisaties meer…als er problemen zijn dan komen softwareproblemen bovenmatig veel bovendrijven.

En toen schoot me iets te binnen. Een van de kernproblemen van software is dat de programmacode één schier eindeloze reeks Single Point of Failures is. Of er nu een letter verkeerd staat, een punt, of wat ook…het resultaat is dat de boel klapt. Met andere woorden; de huidige software is heel erg zwart-wit: het doet het, en dan ook perfect, of het doet het niet. Het is juist om die reden ook heel moeilijk software robuuster te maken.

Hoe wordt in de rest van de wereld robuustheid van producten verhoogd? Dat is niet moeilijk. Voorbeelden hiervan zijn:

  1. Het toevoegen van meer materiaal: Een brug wordt sterker door deze eenvoudigweg “dikker” uit te voeren;
  2. Het toevoegen van bepaalde stoffen: Bij TataSteel in IJmuiden kun je staal van verschillende sterktes krijgen die gemaakt is door toevoeging van mangaan of silicium de eigenschappen aanpassen;
  3. Het combineren van stoffen, zoals betonijzer in een betonconstructie van een gebouw.

Zullen we dat eens vertalen naar onderstaand stukje code waarin de leeftijd wordt bepaald?

Of, ietsje beter misschien:

Het doel van dit stukje code is duidelijk; het bepalen van de leeftijd, bijvoorbeeld om te bepalen of je toegang hebt tot de website van Heineken.com. Hoe kunnen we de robuustheid van dit stukje code verhogen?

Wel, analoog aan de drie opties die hiervoor zijn geschetst komt het neer op:

  1. Het verdubbelen van de programmacode; door het meermalen te kopiëren en uit te voeren wordt dit stukje software robuuster;
  2. Door het toevoegen van bijvoorbeeld extra kleurstof; als de code in paars wordt uitgevoerd, dan is deze extra robuust;
  3. Door ander materiaal toe te voegen, dus bijvoorbeeld snippers glas, wordt de code robuuster.

U voelt wel aan, dit zijn geen van drieën oplossingen die werken. En toch, de bepaling van een leeftijd is minder eenvoudig dan je denkt. Ten eerste hebben we wereldwijd meerdere notaties (DDMMJJ en MMDDJJ). Ten tweede zijn werkelijk meer kalenders dan alleen de meest bekende en gebruikte: “onze” Gregoriaanse kalender. Voorbeelden zijn de Joodse, Islamitische of Saka-kalender die in India wordt gebruikt. Net zoals in de Gregoriaanse kalender met zijn schrikkeldagen zijn in andere kalendersystemen lengtes van jaren ook niet altijd gelijk, en bijvoorbeeld een Islamitisch jaar duurt gemiddeld ongeveer 354 dagen. Wanneer ben je dan 18 jaar? Eerder dan in de Gregoriaanse kalender, of gaan we dat dan compenseren?

Moraal van het verhaal: zelfs zoiets eenvoudigs als het bepalen van een leeftijd vereist al een robuust stukje software dat vele verschillende situaties aankan. Bij een brug is ook niet van te voren bekend welk verkeer er precies overheen zal gaan rijden. Maar bij een brug kunnen we eenvoudig de robuustheid zo hoog opvoeren dat we deze met een gerust hart jaren kunnen gebruiken. Terwijl met de huidige manier waarop software is geconstrueerd, dat niet kan.

Ik moet zeggen dat ik me erover verbaas dat binnen software engineering zoveel aandacht is voor de manier waarop software wordt gecreëerd. Dan weer projecten, dan weer releasematig werken, agile, scrum, devops…de ene na de andere werkwijze buitelt over elkaar heen. Maar een fundamenteel probleem als bovenstaande: “Waarom is software zo geconstrueerd dat robuustheid zo lastig is te verbeteren?”, daar hoor of zie ik niets van. En dat lijkt me eerlijk gezegd een beter tijdsinvestering.