Development

Software-ontwikkeling
De klok tikt bij onderhoud op onderhoud

'Om de legacy heen' coderen is zo gek nog niet

Miniserie over dreigende softwarekrach. Aflevering 4; de analyse van Guido van Rossum

© CC BY 2.0 - Flickr.com,  cea +
26 augustus 2016

Miniserie over dreigende softwarekrach. Aflevering 4; de analyse van Guido van Rossum

Bij het aanpassen van bestaande software ('onderhoud') wordt doorgaans vooral code toegevoegd en niet of nauwelijks geschrapt. Dat heeft een reden: binnen bestaande code aanpassen brengt het gevaar van onbedoelde neveneffecten met zich mee. Maar aanpassen door code toe te voegen heeft ook een levensgroot nadeel: doordat er ook onderhoud op onderhoud nodig zal zijn, leidt het tot een exponentiële groei van de onderhoudslast. Zelfs bij optimistische aannames, zoals 5 procent uitstroom en 10 procent instroom per jaar, houdt de groei van het engineerslegioen de groei van de onderhoudslast niet bij. Een steeds groter deel van de beschikbare software-engineeringcapaciteit gaat zodoende op aan codeonderhoud. Als dat zo doorgaat dan zijn binnen 10 jaar alle programmeurs met onderhoud bezig en wordt er niets nieuws meer ontwikkeld.

Er moet iets gebeuren, zegt Tobias Kuijpers. Het loopt zo'n vaart niet, denkt Rini van Solingen. In de  slotaflevering van onze miniserie over de dreigende softwarekrach rekent Guido van Rossum ons voor dat het in elk geval in theorie nog goed af kan lopen. De bedenker van de superefficiënte programmeertaal Pyton betoogt dat software-engineers wel degelijk de juiste keuze maken als ze 'om de legacy heen' programmeren. Om te laten zien dat dat minder gek is dan dat het op het eerste gezicht lijkt, trekt hij een en parallel tussen computersystemen en biologische systemen: "Mitochondriën (subsystemen van een cel) zijn al zo'n miljard jaar oud en evolueren nauwelijks nog. Als er iets mis is met mitochondriën dan gaat de evoluerende cel niet aan de mitochondriën sleutelen maar wordt er omheen gewerkt. Dus mitochondriën zijn in de praktijk onderhoudsvrij".

Is de mondiale softwarekrach
nog af te wenden?

Alle aandacht voor software als aanjager van economische groei en vernieuwing doet gemakkelijk vergeten dat de meeste software op de wereld oud is. En oude software remt vernieuwing af, doordat het geregeld aanpassing behoeft, maar tegelijkertijd moeilijk aanpasbaar is. Nu al zijn er achter de schermen meer software-engineers met oude code in de weer dan met nieuwbouw. En die verhouding zal steeds schever worden. Totdat ergens in de jaren-20 van deze eeuw de software-revolutie verzandt doordat alle software-engineers nodig zijn voor onderhoud. Of toch niet?

Maandag: Hoe groot is het probleem eigenlijk?

Dinsdag: De analyse Tobias Kuipers

Woensdag: De analyse van Rini van Solingen

Donderdag: De analyse van Guido van Rossum

Er omheen werken

De manier waarop software nu wordt onderhouden lijkt volgens Van Rossum sterk op de manier waarop de natuur mitochondriën ongemoeid laat: "Is er iets mis met de firmware of de BIOS dan werkt het operating system er wel omheen. Daardoor is er weinig onderhoud aan de firmware. Is er iets mis met het operating system, dan werkt de bibliotheeksoftware daar wel omheen. Werkt een bibliotheek in een bepaald geval niet goed, dan werkt de applicatie er omheen. Enzovoort."

Volgens Van Rossem gaat dit principe niet alleen op bij het hanteren van software-bugs, maar vooral ook bij het ondervangen van minder gelukkige ontwerpbeslissingen: "Veel fouten in de diepere lagen zitten in het ontwerp van de API en daar is vaak weinig meer aan te doen. UNIX bijvoorbeeld is een geweldig systeem, maar er zitten ook wel ideeën in die minder dan ideaal zijn. Bijvoorbeeld het hergebruik van process ID's, of super-user-rechten. Dit is dus een prima gelegenheid voor de hoger liggende lagen (OS, shell, bibliotheek of zelfs een abstractie in een applicatie) om iets beters te bieden".

Oneindige reeks

Zo bezien is om de legacy heen programmeren misschien toch wel de beste oplossing. Maar dat garandeert natuurlijk niet dat die aanpak daarmee ook goed genoeg is om een softwarekrach te voorkomen. Het doet immers allerminst af aan aan Kuipers observatie dat ook onderhoud code genereert waarop onderhoud nodig zal zijn.

Maar volgens Van Rossum hoeft de noodzaak van onderhoud op onderhoud niet per se een eindeloos groeiende onderhoudslast op te leveren: "De truc is dat een oneindige reeks best wel een eindige limiet kan hebben. De eindeloze reeks 1/2 + 1/4 + 1/8 + 1/16 + ... bijvoorbeeld, heeft som 1. Dus met een eindig aantal programmeurs kunnen we weldegelijk een 'oneindig' aantal softwarelagen onderhouden, als de onderhoudsnoodzaak voor de diepere lagen maar voldoende afneemt."

Geen zorgen

Nieuwe programmeertalen kunnen helpen door daar waar het meeste onderhoud nodig is dat ook goed te faciliteren, verwacht Van Rossum: "Diepere lagen zijn vaak geschreven in talen van lager niveau. Firmware is vaak nog geschreven in assembler en operating systems als Linux en BSD zijn ontwikkeld in talen als C of C++. Maar applicaties worden geschreven in van alles, van Java, C#, Go, Python, PHP en Ruby tot Haskell, Erlang en F#. Naarmate er meer lagen komen zullen nieuwere programmeertalen arriveren die beter werken voor hoger liggende lagen. En in sommige gevallen zullen de bestaande talen evolueren om nieuwe toepassingen mogelijk te maken. Denk aan de ontwikkeling van C, naar C++, waarmee we inmiddels bij de C++14-standaard zijn aangeland. En nieuwe bibliotheken bieden API's aan van een hoger niveau."

Zorgen over het software-onderhoud van de toekomst maakt Van Rossum zich dus niet, maar: "...zorgen over de werkgelegenheid in de IT-sector evenmin!"

Guido van Rossum is de ontwerper van de snel terrein winnende programmeertaal Python. Naast zijn centrale rol in de Python-community is hij software-engineer bij Dropbox. Eerder was hij werkzaam bij CWI en Google.

 

Lees meer over Development OP AG Intelligence
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.