Albert Mietus
Telkens als ik een leuk stukje hardware koop, gaat het na verloop van tijd kapot. Immers, alles, behalve software, slijt. Soms zelfs al heel snel, bij een slecht in elkaar gezet maandagochtendexemplaar bijvoorbeeld. En soms gebeurt het spontaan; als ik het laat vallen, dan is het dom, maar ook kapot. En anders zal ooit één onderdeel falen en de levensduur van mijn gadget beëindigen. Dit zijn de drie fundamentele faalmethodes, die samen de ’badkuipkromme‘ vormen: de kans op kinderziektes neemt snel af, vervolgens is er lange tijd een kleine kans dat het spontaan kapotgaat, waarna slijtage toeslaat en de kans op ’overlijden‘ weer toeneemt. Tot zover de microcursus reliability-engineering, een methode om te rekenen aan de levensduur die elke ingenieur kent. Iedereen, behalve de software-ingenieur, want die weet dat software niet slijt …
Dat rekenen gebeurt met geavanceerde, stochastische modellen. De basis is echter eenvoudig: de faalkans is de inverse van de MTBF (mean time between failure) en voor de meeste ontwerpen mogen we de kans per onderdeel optellen. Omgekeerd: voor een systeem dat honderd uur onafgebroken moet werken en samengesteld is uit duizend onderdelen geldt dat elk onderdeel – gemiddeld – slechts eens in de honderdduizend uur mag falen. Dat is minder dan eens in de elf jaar! Gelukkig zal de software over elf jaar nog net zo werken als op dag een. Software slijt immers niet.
Oké, software kan crashen. Maar dat is wat anders; gewoon opnieuw opstarten en je zult zien dat het dan wel werkt. Dus het is niet echt kapot, laat staan versleten. Vaak komt dat trouwens, aldus de gemiddelde programmeur, doordat de gebruiker iets doms heeft gedaan. Niet iets waar de software-ingenieur rekening mee kan houden. Zolang de gebruiker niets doms doet, zal de software niet slijten. Toch?
Maar als software niet slijt, waarom zijn er dan ontwikkelaars die Windows herinstalleren? Oké, af en toe je harde schijf wissen en dezelfde software opnieuw installeren maakt het systeem weer fris en snel. Waarschijnlijk komt dit door een onbegrepen neveneffect, want een niet versleten onderdeel vervangen door exact hetzelfde zal niet echt helpen. Daarom weiger ik om hieraan mee te werken. Want ik mag niet twijfelen; software slijt niet.
PhD pitches at the Benelux RF Conference
Learn about the latest trends and developments in high-end RF techniques. On 24 May, the Benelux RF Conference will take place in Nijmegen. New this year are the PhD pitches, in which young professionals present their research results. Make sure to reserve your seat in time and register now.
Toch twijfel ik stiekem wel eens, heel stilletjes. Het zou leuk zijn als ook ik die badkuipkromme zou kunnen gebruiken. Als ik met die mooie, moderne rekenmethodes kan voorspellen wanneer de volgende bug optreedt. Of als ik vooraf kan berekenen hoe lang de software blijft werken. Maar al die twijfel is zonde van mijn tijd; software slijt niet!
Software gaat immers makkelijk elf jaar mee. Daar twijfelt toch niemand aan? Neem bijvoorbeeld Windows XP, dat op 24 augustus 2001 uitkwam. Iemand zal die oorspronkelijke versie, nu ruim elf jaar oud, toch nog wel gebruiken? Iemand die geen behoefte had aan patches, servicepacks en ander ontwerpherstel. Iemand die liever zijn systeem altijd up and running houdt dan niet versleten software vervangt. Wil de lezer voor wie dit geldt zich even melden? Dan hebben we het proefondervindelijk aangetoond: software slijt niet!
Maar stel dat software wel zou kunnen slijten. Dat software, als onderdeel van complexe hightech systemen, wel na verloop van tijd kapot zou kunnen gaan. Stel je voor, dan zouden ook wij moeten rekenen aan levensduur. Maar dan zou er wellicht ook budget komen om complexe fail-safe ontwerpen te mogen maken. Of zouden er middelen worden vrijgemaakt om al die details op te lossen waar codecheckers al jaren over klagen. Vaak is er geen budget voor die extra inspanning; software slijt immers niet.
En toch. Is er niet een software-ingenieur die deze rekenmodellen snapt en wil omzetten in een stukje opensource code? Code waarmee iedereen zo‘n slijtage-class kan inbouwen? Zodat ook elk softwaredeel netjes, kunstmatig, kan verouderen. Exact volgens de juiste stochastische modellen. Dan snappen ook budgethouders dat die extra budgetten nodig zijn. Want slijtage snapt iedereen.
Tactisch zou ik zo‘n module graag willen hebben, maar praktisch is het waarschijnlijk niet. Want het gaat om gemiddeld elf jaar, dus soms veel korter en soms ook veel langer. Maar bovenal twijfel ik, wederom. Is het ethisch correct om iemand te vragen een class te programmeren die elf jaar mee moet gaan? Ik vrees dat code al overleden is lang voordat die softwarematig versleten is.