De bug ’29/02/00′ bestaat niet, zo licht Niels Meijer toe.
Bugs in software ontstaan voornamelijk als gevolg van kortzichtig programmeerwerk, of het niet overzien van een bepaalde te programmeren problematiek. Men ziet iets over het hoofd. De millenniumbug is daar een typisch voorbeeld van. Hierbij is over het hoofd gezien dat de te programmeren software ook na 1999 moet functioneren. Anno 2000 klinkt dat heel vreemd maar in 1985 was het jaar 2000 heel ver weg en programmeerde men vrolijk een datum-rekensommetje op basis van de laatste twee getallen. Kortzichtig maar snel! Er is dus terecht gevreesd voor millenniumschade, met name in de financiële sector. Denk er maar aan dat je in 2000 een negatieve jaarrente (bijvoorbeeld in de periode 1/2/1999 tot 1/2/2000) zou ‘ontvangen’ op je spaartegoed� Pijnlijk toch?
Bovengenoemde kortzichtigheid in aanmerking genomen, kan men zich voorstellen dat een programmeur denkt dat een jaar altijd 365 dagen telt en navenant rekent in z’n software. Na een periode van maximaal vier jaar zullen mensen die met die software werken een schrikkelbug melden. Eén keer in de vier jaar is het immers een schrikkeljaar en telt het jaar 366 dagen, omdat de maand februari dan 29 dagen telt in plaats van 28. De programmeur past zijn software aan met een instructie à la ‘if jaartal modulus 4=0 then dagen=366 else dagen=365’ uiteraard analoog een ‘if-je’ voor het aantal dagen van februari van dat jaartal. Klaar is Kees, de software is schrikkelbestendig! Wat hij vergeet, of niet weet, is dat elk jaartal dat een veelvoud is van 100, geen schrikkeljaar is, maar daarentegen dat een jaartal dat een veelvoud is van 400 weer wel een schrikkeljaar is. Hij denkt überhaupt dat zijn software de volgende eeuw niet haalt, op het moment dat hij het in 1985 schrijft.
Maar nu is het 2000, een schrikkeljaar, zoals we weten. Voor onze ‘net’ schrikkelproof gemaakte software is er geen vuiltje aan de lucht, immers 2000 modulus 4=0 en de software houdt rekening met 29 dagen in februari en 366 dagen in het hele jaar. Toevallig leveren de niet geprogrammeerde eisen ‘if 2000 modulus 100=0 then dagen=365’ en ‘if 2000 modulus 400=0 then dagen=366’ geen andere waarde op. De kortzichtige programmeur (de creator van een potentiële millenniumbug) heeft geen centje pijn met zijn software, zijn software hobbelt gewoon door. Pas in 29 februari 2100 wordt het spannend, maar zolang zal de software niet draaien. De 29/02/00 bug zou alleen kunnen ontstaan als de programmeur alleen de ‘2000 modulus 100’-regel heeft geprogrammeerd, en niet de ‘2000 modulus 400’-regel. Weliswaar is dat ook een kortzichtigheid,maar niet een die ten grondslag ligt aan een millenniumbug. Een louter theoretische bug, waar er zo velen van zijn, maar waarvan geen ophef wordt gemaakt omdat we ze niet zien aankomen! De trits datums (09/09/99, 01/01/2000 en 29/02/2000) is door onze branche goed verkocht als een doom-scenario in drie bedrijven, waarvan alleen de 01/01/2000 een mogelijk gerechtvaardigd probleemgeval was. Computers blijven moeilijk en ondoorzichtig voor een leek, die daardoor makkelijk bang en onzeker kan worden gemaakt. Fear, Uncertainty en Doubt (FUD) werken in de verzekeringsbranche ook zo goed.
Niels Meijer, projectadviseur ICT