BLOG

Software ontwikkeling

Software ontwikkeling moet op de schop

2 oktober 2017

Naar aanleiding van een longread in The Atlantic is er een balletje gaan rollen in software land. De manier waarop we naar software kijken en hoe software engineers programmeren, moet anders. Programmeurs denken nog zoals in de jaren 80. Sinds die tijd zijn de manier waarop programmeurs werken en de tools die ze gebruiken maar weinig veranderd. Terwijl onze technologie dermate complex is geworden dat we ons dat niet meer kunnen veroorloven. We kunnen onze eigen systemen bijna niet meer bevatten, zo ingewikkeld zijn deze tegenwoordig. En dat kan catastrofale gevolgen hebben. Een uitgelichte case betreft de problemen bij Toyota. Daar werden ontzettend veel auto’s teruggeroepen doordat plots pedalen niet meer functioneerden en de auto’s niet meer konden remmen. Die pedalen werden vroeger mechanisch aangestuurd maar tegenwoordig gebeurt dat allemaal met software.

Spaghetti code

We blijven tegenwoordig maar doorontwikkelen en doorontwikkelen tot een applicatie eigenlijk niet meer leesbaar is. Software is hierdoor zo complex geworden, dat de complexiteit onze intellectuele kennis overstijgt. En dat is gevaarlijk. Als we onze eigen applicaties straks niet meer begrijpen, hoe kunnen we dan nog ingrijpen in gevaarlijke scenario’s? Software ontwikkelaars begrijpen vaak het probleem niet dat ze moeten oplossen of denken er onvoldoende over na en zijn alleen bezig met code schrijven. Die code is zo ingewikkeld geworden dat ie eigenlijk los staat van de werkelijkheid en de initiatie van het probleem, aldus The Atlantic.

Visual Studio: 55 miljoen regels code en 98% is irrelevant

Chris Granger, die als software ontwikkelaar werkte bij Microsoft, deed een end-to-end onderzoek naar Visual Studio: een software ontwikkelomgeving voor programmeurs die gebruikt wordt door ongeveer een derde van alle professionele programmeurs. Granger deed het eerste en enige end-to-end onderzoek onderzoek tot dan toe. Hij keek 1,5 maand lang naar het gebruikersgedrag. Hoe gebruikt men de tools? Gebruikt men de muis of juist niet? Hoe denkt de gebruiker? Hier zijn allerlei aannames over gedaan maar die zijn nooit getoetst. Zijn bevindingen verrasten hem en velen met hem: Visual Studio is één van de grootste software applicaties ter wereld met meer dan 55 miljoen regels code en 98% (!) daarvan blijkt compleet irrelevant. Zoveel werk als hierin is gestoken maar de belangrijkste problemen waar mensen tegenaan liepen werden grotendeels gemist.

Mensen spelen de computer in hun hoofd: als je programmeurs vergelijkt met schakers, zijn ze geblinddoekt aan het spelen. Veel van hun energie gaat zitten in het proberen voor te stellen waar de stukken staan (denken hoe code wordt geïnterpreteerd door de computer) en er blijft amper nog energie over om over het spel zelf na te denken. Meerdere programmeurs uit het artikel erkennen deze metafoor, die veel breder telt dan dit extreme voorbeeld omtrent Visual Studio.

Software ontwikkeling moet anders

Een belangrijke eigenschap van code is dat het veranderen van 1 regel effect kan hebben op het hele systeem. Dat is tegelijkertijd fantastisch en gevaarlijk. Doordat we zo afhankelijk zijn geworden van software, kunnen kleine fouten of wijzigingen een hele maatschappij op z’n kop zetten. Zoals bijvoorbeeld het geval was toen 911 urenlang niet bereikbaar was, doordat een maximaal aantal oproepen bereikt was. De software maakte geen fout; een mens had de grens immers ooit ingesteld (op een miljoenengetal) omdat er iets moest worden opgegeven. Het duurde dagen eerdat men erachter was dat daar het probleem zat dat er geen oproepen meer doorkwamen. Maar er zijn meer scenario’s denkbaar: auto’s die niet meer kunnen remmen, ziekenhuisapparatuur die mensen doodt. Geen sciencefiction maar waargebeurde verhalen. En de kans op dergelijke fouten neemt in de toekomst alleen maar toe als we verder gaan zoals we nu bezig zijn.

De programmeurs in het artikel van The Atlantic erkennen de problemen. Met zoveel software, zoveel code en het steeds verder overnemen van kritieke functies zijn fouten onvermijdelijk geworden. En de fouten zijn misschien nog niet het grootste probleem, maar het opsporen en oplossen ervan wel: vind maar eens die ene bug in zo’n berg code die zorgt voor het omvallen van het kaartenhuis. Maar de experts hebben gelukkig ook suggesties hoe het dan beter kan: onze software moet meer gaan lijken op de fysieke werkelijkheid, zodat fouten ook sneller zichtbaar worden. Programmeurs moet de lijfspreuk ‘what you see is what you get’ letterlijk gaan nemen bij het oplossen van een probleem. Zo’n oplossing in een model-based design stuit dan weer op veel weerstand uit de software ontwikkelingswereld. Software engineers lijken erg gehecht aan de eigen (ingewikkelde) code. Een omslag naar zo’n model-based design approach kost geld en er zal flink wat tijd overheen gaan om dit te bereiken. Maar onafwendbaar, willen we ergere ongelukken in de toekomst voorkomen.

Lees de volledige longread van 28 pagina’s in The Atlantic. Wilt u meer weten over model-based design en hoe wij dit bij u kunnen toepassen? Neem dan vrijblijvend contact met ons op.

Contact met Senet

Senet Woerden
Trasmolenlaan 12
3447 GZ Woerden
Bekijk op kaart

Senet Eindhoven
Gestelsestraat 258
5654 AM Eindhoven
Bekijk op kaart

+31(0)40-2930395