Elk jaar zouden er wereldwijd 1,8 miljoen softwareontwikkelaars moeten worden opgeleid. Dit gebeurt duidelijk niet. De it-industrie produceert meer software dan het kan onderhouden. Met onbetrouwbare it-systemen tot gevolg. Hoe gaan we dit oplossen?
Software die niet verder ontwikkeld wordt, verliest zijn waarde. Prof. Manny Lehman introduceerde dit idee al in 1978 in één van zijn lezingen – ‘Programs, Cities, Students – Limits to Growth’.
Oude programma’s draaiend houden
Met andere woorden, als je ophoudt met het updaten en wijzigen van je bestaande softwaresysteem of –component, dan houdt die uiteindelijk op met werken. Soms zorgt een grote iOS- of Windows-upgrade er bijvoorbeeld voor, dat net jouw favoriete applicatie niet meer bruikbaar is. Maar het is niet altijd zo zichtbaar, een organisatie kan er bijvoorbeeld voor kiezen om specifieke oude programma’s draaiende te houden op een Windows NT-computer ergens in een kelder. Of, een nucleair wapenplatform.
Dus, zelfs nu er zoveel nieuwe softwaresystemen als paddenstoelen uit de grond schieten, blijft het belangrijk om bestaande systemen te blijven verbeteren en upgraden om deze relevant, bruikbaar en winstgevend te houden.
Software onderhouden is duur
Volgens verschillende bronnen zijn er ongeveer twaalf miljoen professionele softwareontwikkelaars in de wereld. Dit aantal bevat de mensen die een significant deel van hun inkomen verdienen met het programmeren van computers. Dit varieert van Excel-experts tot de cool kids die bezig zijn met JavaScript en Swift, tot studenten die nog steeds wachten op het moment dat Haskell populair wordt. En laten we vooral ook niet de Cobol-programmeurs vergeten die de afgelopen twee decennia dagelijks aan de betalingssystemen van onze banken hebben gesleuteld.
De afgelopen vijftien jaar hebben mijn collega’s en ik softwaresystemen en bijbehorende ontwikkelteams geanalyseerd en hebben we hen geholpen met het verbeteren van hun efficiëntie en hun resultaten. Gedurende die vijftien jaar hebben we aardig wat gegevens verzameld waaruit onder andere blijkt, dat de gemiddelde ontwikkelaar zo’n tienduizend regels code per jaar schrijft. Ook weten we nu dat van die tienduizend regels code jaarlijks gemiddeld zo’n 15 procent van de broncode verandert tijdens upgrades. We hebben letterlijk miljarden regels code gezien en deze 15 procent is een opmerkelijk stabiel getal.
Kortom, er zijn twaalf miljoen ontwikkelaars die elk jaar gezamenlijk 120.000.000.000.000 regels code schrijven of veranderen. Het jaar nadien moet circa 15 procent van die regels worden gewijzigd. Alles bij elkaar vergt dit 1,8 miljoen fulltime ontwikkelaars, wat betekent dat er elk jaar 1,8 miljoen ontwikkelaars zouden moeten worden opgeleid. Dit gebeurt duidelijk niet. In de VS ontvangen per jaar zo’n 88.000 mensen hun computer science diploma en zijn er momenteel 144.500 openstaande vacatures. Andere landen staan er helaas niet veel beter voor.
Niet genoeg ontwikkelaars, wat nu?
Er worden duidelijk niet genoeg ontwikkelaars opgeleid om alle (nieuwe) code te onderhouden. Dit heeft drie gevolgen:
- Er is een enorme vraag naar softwareontwikkelaars, bij voorkeur programmeurs. De vraag is zelfs zo groot dat traditionele scholen en onderwijsinstituten niet aan de vraag kunnen voldoen. Mensen betalen tienduizend euro voor een crash course van twaalf weken waarin amateurs de basisprincipes van professionele software engineering leren.
- Ontwikkelaars doen enkel nog ‘breakdown maintenance’. Als er ergens wat kapot gaat, gaan ze voor een snelle, vaak dirty fix, zoals blijkt uit de eindeloze stroom van problemen die oude systemen teistert.
- Bedrijven stoppen met innoveren. Sommige organisaties spenderen meer dan 90 procent van hun it-budget aan ‘zorgen dat alles blijft draaien’ (keeping the lights on). Dit betekent dat er elk jaar miljoenen worden uitgegeven om ervoor te zorgen dat alles blijft werken, zoals het al werkte.
Systemen crashen of worden onbetrouwbaar
Vergeet niet dat bij het onderhoud van systemen een groot deel van de inspanning zit in het onderhoud van grote, tamelijk onzichtbare enterprise softwaresystemen waar jij en ik dagelijks op vertrouwen zonder het te weten. En omdat deze systemen inmiddels zo groot zijn dat ze niet meer goed onderhouden kunnen worden (i.e. 15 procent van de code moet worden veranderd per jaar), beginnen ze mankementen te vertonen en worden ze onvoorspelbaar.
Bijvoorbeeld:
- Een systeem update bij de Royal Bank of Schotland in juni 2012 zorgde voor een reeks storingen die pas na een maand waren opgelost, resulterend in ernstige problemen voor tweehonderdduizend klanten.
- Twee hackers toonden dat ze de volledige controle van een Jeep Cherokee van een journalist konden overnemen, omdat het onmogelijk was geworden om een degelijke beveiliging toe te voegen aan het enorme besturingssysteem van deze wagen.
- In de bekende zaak, waarbij sommige Toyota-voertuigen versnelden, terwijl de bestuurders het pedaal niet aanraakten, kostte het onafhankelijke experts twintig maanden om, aan de hand van de broncode, te bepalen of het gaspedaal op de juiste manier met de motor was verbonden.
Bovenstaande voorbeelden illustreren dat het probleem dat de it-industrie meer software produceert dan het kan onderhouden, meer is dan enkel een economisch probleem. Deze trend heeft ook gevolgen voor de continuïteit, betrouwbaarheid en veiligheid.
Wetenschap moet werken aan langetermijnoplossing
Het creëren van een technologie die minder onderhoud vereist, zou een structurele langetermijnoplossing kunnen zijn. Dit zou dus een belangrijk onderzoeksonderwerp moeten zijn, maar – voor zover ik weet – is dit momenteel niet het geval. Er wordt veel onderzoek (academisch en commercieel) gedaan naar meer productieve technologieën – het soort waarmee je een systeem sneller kunt maken. Hoewel dit interessant is, blijkt dit in de praktijk zelden relevant. Als je gedurende zeven jaar 1,6 miljoen euro aan onderhoud gaat spenderen voor een systeem van 1 miljoen euro, dan is het niet van groot belang of dat systeem een maand eerder wordt opgeleverd.
Van Lehman hebben we geleerd dat software onderhoud nodig heeft om waardevol te blijven. In het boek ‘The Laws of Software Process’ legt Philip Armour uit, dat software uitvoerbare kennis van een proces is. Nu organisaties continu veranderen, is het belangrijk dat hun software mee verandert. Wat we nodig hebben, is een technologie die toestaat deze wijzigingen zo goedkoop mogelijk te implementeren. Zoals eerder genoemd is de verandersnelheid 15 procent met huidige technologieën en dat is niet houdbaar op de lange termijn.
Oog op onderhoudbaarheid stopt exponentiële groei
Terwijl wetenschappers hopelijk aan nieuwe technologieën werken, is er ook iets wat wij nu al kunnen doen om het tij te keren.
Hoewel de verandersnelheid van 15 procent redelijk constant lijkt, betekent het niet dat elk systeem jaarlijks 15 procent groter wordt. De snelst groeiende systemen zijn complex en moeilijk te testen. Meestal durft niemand ze nog aan te raken, omdat het risico dat er wat stuk gaat te groot geworden is. Deze systemen zijn vaak zo inflexibel, dat elke verandering aan de functionaliteit een nieuw systeem vergt ,dat de output van het vorige onveranderbare systeem gebruikt om tot de gewenste resultaten te komen. Het nieuwe systeem functioneert effectief gezien als een uitbreiding op het oude systeem en zal dus alleen maar mee groeien.
Of men kopieert hele stukken broncode binnen het systeem, die men dan vervolgens aanpast – in tegenstelling tot het aanpassen van de code op zijn plaats. De logica daarachter is, dat als je de originele code op haar plaats laat, en dan gaat werken met een aangepaste kopij, de originele code in elk geval blijft werken. Stel je voor: je verbouwt je huis, maar in plaats van het vervangen van de keuken, bouw je er een nieuwe keuken bij aan de achterkant van het huis. En een een nieuwe badkamer, en nu je toch aan het verbouwen bent, ook een nieuwe woonkamer. En vervolgens een paar jaar later, misschien toch een andere keuken…
Als je ontwerpt en bouwt met onderhoudbaarheid in het achterhoofd (wat niet duurder of trager is, dan ontwerpen en bouwen zonder rekening te houden met onderhoudbaarheid), dan kan dit het verouderingsproces minstens vertragen. Wij zien dat in de beste systemen er nog steeds, elk jaar, 15 procent van de code wordt aangepast. Het systeem neemt echter niet toe in volume. Dat betekent dat er wel 15 procent van de regels code wordt veranderd en aangepast, maar dat er geen extra regels code worden toegevoegd.
Op die manier spendeer je elk jaar nog steeds 15 procent van je initiële ontwikkelinspanning aan onderhoud, maar zo voorkom je dat dit het jaar nadien 32,5 procent is.
Beheren van het totale code volume
Als je bovenstaande strategie combineert met solide management en monitoring op het totale code volume van je organisatie, dan heb je tenminste enige controle over de situatie.
Bij nieuwe software initiatieven zou je jezelf meteen af moeten vragen hoeveel regels code aan oude software van je huidige softwareportfolio je kan elimineren en er uiteraard ook zorg voor dragen dat deze ook daadwerkelijk verwijderd worden. Elke 66.000 regels code vergt immers één fulltime, niet goedkope, en moeilijk te vinden softwareontwikkelaar voor onderhoud.
Deze blog van Tobias Kuipers is een samenwerking tussen O’Reilly en de Software Improvement Group. Deze publicatie verscheen op: https://www.oreilly.com/ideas/why-you-need-to-know-about-code-maintainability
De redenering in dit artikel klopt niet helemaal. Een aanzienlijk deel van de ontwikkelaars schrijft geen nieuwe code, maar is bezig met onderhoud. Wat overigens ook een groot probleem is.
Meer software ontwikkelaars lost m.i. het probleem niet op.
De redenering in dit artikel klopt niet helemaal. Een aanzienlijk deel van de ontwikkelaars schrijft geen nieuwe code, maar is bezig met onderhoud. Wat overigens ook een groot probleem is.
Meer software ontwikkelaars lost m.i. het probleem niet op.