Softwareslijtage

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?