Vrijdag de dertiende. De dag waarop bijgelovige mensen liever thuisblijven. Maar in de softwarewereld hoef je niet bijgelovig te zijn om onheil te vrezen, want sommige van de duurste software fouten uit de geschiedenis hadden niets met pech te maken. Ze hadden alles te maken met ontbrekende tests, verkeerde aannames en code die niemand goed genoeg had gecontroleerd.
Dit zijn dertien beroemde software bugs die samen miljarden aan schade veroorzaakten, levens kostten en complete systemen platlegden. Van een ruimtesonde die verdween door een rekenfout tot een beurshandelsysteem dat in drie kwartier 440 miljoen dollar verbrandde. Elk verhaal is fascinerend op zich, maar de echte waarde zit in wat er steeds weer fout ging, want de patronen herhalen zich verrassend vaak.
Geen droge opsomming dus, maar dertien verhalen met een punchline. En ja, er zit zelfs eentje bij over Gangnam Style.
1. De ruimtesonde die verdween door een rekenfout
In 1999 stuurde NASA de Mars Climate Orbiter naar Mars. De reis duurde negen maanden en de totale missie kostte 327 miljoen dollar. Alles verliep volgens plan, tot de sonde de atmosfeer van Mars naderde en plotseling verdween. Weg. Voorgoed.
De oorzaak bleek pijnlijk simpel: het navigatieteam op aarde rekende in het metrische stelsel (newtons), maar de software van fabrikant Lockheed Martin leverde stuwkrachtdata in het Engelse stelsel (pound-force). Niemand had gecontroleerd of beide systemen dezelfde eenheden gebruikten.
Testles: integratie tests (tests die controleren of verschillende systemen goed samenwerken) zijn geen luxe. Ze zijn een noodzaak, vooral wanneer meerdere teams aan hetzelfde project werken.
Maar het verlies van een ruimtesonde is nog relatief abstract. De volgende blunder kostte mensenlevens.
2. De bestralingsmachine die patiënten verwondde
Tussen 1985 en 1987 gaf de Therac-25, een computergestuurde bestralingsmachine voor kankertherapie, minstens zes patiënten een dodelijke of zwaar verwondende dosis straling. De machine gaf tot honderd keer de bedoelde dosis, omdat een softwarefout optrad wanneer de operator snel genoeg typte.
Het probleem was een zogeheten race condition (een fout waarbij twee processen tegelijk om dezelfde data strijden). De software bevatte geen onafhankelijke veiligheidscontrole, want de ontwikkelaars vertrouwden volledig op de software zelf. Eerdere versies van de machine hadden nog een hardwarematige beveiliging, maar die was bij de Therac-25 weggelaten.
Testles: software die mensenlevens kan beïnvloeden, vereist onafhankelijke veiligheidslagen. Vertrouw nooit op een enkel controlepunt.
En als je denkt dat race conditions alleen in medische apparatuur voorkomen, wacht dan tot je het verhaal over de stroomuitval leest. Maar eerst: een raket die zichzelf opblies.
3. De raket die zichzelf opblies na 37 seconden
Op 4 juni 1996 lanceerde de European Space Agency de Ariane 5 raket voor haar eerste vlucht. Na 37 seconden begon de raket oncontroleerbaar te tollen en blies het zelfvernietigingsmechanisme de raket op. De onbemande lading van circa 370 miljoen dollar ging in rook op.
De oorzaak? Een integer overflow (een rekenfout waarbij een getal te groot wordt voor de opslagruimte). De software probeerde een 64-bit getal te proppen in een 16-bit variabele. Die code was overigens nog afkomstig van de Ariane 4, waar het prima werkte, want de Ariane 4 had lagere snelheden en dus kleinere getallen.
Testles: hergebruikte code in een nieuwe context verdient nieuwe tests. Wat werkte in het oude systeem, werkt niet automatisch in het nieuwe.
Van exploderende raketten naar exploderende bankrekeningen. De volgende blunder kostte geen 37 seconden, maar slechts 45 minuten.
4. Het bedrijf dat 440 miljoen dollar verloor in 45 minuten
Op 1 augustus 2012 startte beurshandelaar Knight Capital een nieuwe versie van hun handelssoftware. Binnen een paar minuten begon het systeem onbedoelde transacties uit te voeren, omdat oude, niet meer gebruikte code per ongeluk was geactiveerd op een van de servers. De meeste servers draaiden de nieuwe versie, maar een enkele server draaide nog een oude versie met een functie die nooit voor productie bedoeld was.
In 45 minuten verloor Knight Capital 440 miljoen dollar. Het bedrijf ging bijna failliet en werd kort daarna overgenomen.
Testles: een deployment (het uitrollen van nieuwe software) zonder verificatie op alle servers is Russische roulette. Controleer altijd of elke omgeving dezelfde versie draait.
Die 440 miljoen dollar is een astronomisch bedrag. Maar de volgende blunder trof niet een bedrijf, maar de hele wereld.
5. De update die 8,5 miljoen computers tegelijk crashte
Op 19 juli 2024 stuurde cybersecuritybedrijf CrowdStrike een update uit voor hun Falcon-sensor. Binnen minuten crashten de eerste van uiteindelijk 8,5 miljoen Windows-systemen wereldwijd met het beruchte "blue screen of death". Vluchten werden geannuleerd, ziekenhuizen schakelden over op handmatige systemen en banken konden geen transacties verwerken.
De oorzaak was een foutieve configuratie-update die niet goed getest was voordat ze naar alle klanten tegelijk werd uitgerold. Er was geen gefaseerde uitrol (eerst een kleine groep, dan steeds meer) en geen canary release (een testgroep die de update als eerste krijgt om problemen vroegtijdig te ontdekken).
Testles: nooit alles tegelijk uitrollen. Gebruik canary releases en gefaseerde deployments, zodat een fout niet meteen de hele wereld raakt.
Die CrowdStrike-update was een moderne wake-up call. Maar de grootste collectieve paniek rond software vond plaats op de drempel van een nieuw millennium.
6. De bug waar de hele wereld bang voor was
Op 1 januari 2000 zou de wereld vergaan. Althans, dat was de vrees. De millenniumbug (Y2K) ontstond doordat programmeurs jarenlang jaartallen opsloegen als twee cijfers in plaats van vier. "99" was 1999, maar wat was "00"? Het jaar 2000, of 1900?
Overheden en bedrijven besteedden gezamenlijk meer dan 300 miljard dollar aan het opsporen en repareren van deze fout. Uiteindelijk viel de schade op nieuwjaarsdag mee, juist omdat er zo massaal getest en gerepareerd was.
Testles: Y2K bewees dat testen werkt. De ramp bleef uit omdat mensen het probleem serieus namen en op tijd actie ondernamen. Preventie is onzichtbaar, maar onmisbaar.
Van een bug die decennia sluimerde naar een kwetsbaarheid die jarenlang verborgen zat in het hart van het internet.
7. Het gat in het hart van het internet
In april 2014 onthulden onderzoekers Heartbleed, een kwetsbaarheid in OpenSSL, de encryptiesoftware die op dat moment door zo'n tweederde van alle webservers werd gebruikt. De bug zat in een simpele functie genaamd "heartbeat" en kwam neer op een ontbrekende bounds check (een controle of een verzoek niet meer data opvraagt dan toegestaan). Daardoor kon een aanvaller stukjes geheugen uitlezen van servers, inclusief wachtwoorden, encryptiesleutels en persoonlijke gegevens.
Het schokkende? De bug zat al twee jaar in de code voordat iemand hem ontdekte. En de hele wereld was afhankelijk van deze ene opensourcebibliothek.
Testles: security testing (het testen van software op kwetsbaarheden) mag geen bijzaak zijn. Juist de componenten waar iedereen blind op vertrouwt, verdienen de meeste aandacht.
Blind vertrouwen op software speelde ook een rol bij de volgende blunder, maar dan met vliegtuigen.
8. Het vliegtuig dat zichzelf naar beneden duwde
In oktober 2018 en maart 2019 stortten twee Boeing 737 MAX-toestellen neer, waarbij 346 mensen omkwamen. De oorzaak was MCAS, een automatisch vluchtbeheersysteem dat de neus van het vliegtuig naar beneden duwde op basis van data van slechts een enkele sensor. Wanneer die sensor foutieve data gaf, duwde MCAS het toestel herhaaldelijk omlaag, terwijl de piloten vochten om het weer omhoog te krijgen.
Boeing had een systeem gebouwd met een single point of failure (een enkel onderdeel waarvan het falen het hele systeem laat crashen). Bovendien wisten de meeste piloten niet eens dat MCAS bestond, want Boeing had het niet in de handleiding opgenomen.
Testles: test nooit alleen het "happy path" (het scenario waarin alles goed gaat). Test juist wat er gebeurt als een sensor liegt, als data ontbreekt, als het systeem faalt.
En als je denkt dat alleen vliegtuigbouwers kampen met onleesbare software, dan is het volgende verhaal een eye-opener.
9. De auto die zelf gas gaf
Tussen 2009 en 2011 ontving Toyota meer dan 9.000 klachten over auto's die plotseling onbedoeld accelereerden. Na jarenlang onderzoek analyseerden NASA-ingenieurs de software en wat ze vonden was onthutsend: het gaspedaalsysteem bevatte meer dan 11.000 globale variabelen, de code was wat experts "spaghetti code" noemen (verwarde, moeilijk leesbare code zonder duidelijke structuur). Er waren geen defensieve programmeertechnieken gebruikt en variabelen werden op onvoorspelbare manieren gedeeld tussen processen.
Toyota betaalde uiteindelijk meer dan 1,2 miljard dollar aan schikkingen.
Testles: codekwaliteit is testkwaliteit. Als code zo complex is dat niemand hem begrijpt, kan ook niemand hem goed testen. Refactoring (het herstructureren van code zonder de functionaliteit te veranderen) is geen luxe maar een testvereiste.
Na al deze zware verhalen is het tijd voor iets lichters. Want soms zijn software blunders niet gevaarlijk, maar gewoon hilarisch.
10. De dag dat Gangnam Style YouTube brak
In december 2014 werd Gangnam Style van PSY de eerste YouTube-video die meer dan 2.147.483.647 views bereikte. Dat getal is geen toeval: het is het maximum van een 32-bit integer (het grootste gehele getal dat in 32 bits past). YouTube had hun viewcounter oorspronkelijk gebouwd met een 32-bit integer, omdat niemand had verwacht dat een video ooit zoveel views zou krijgen.
YouTube zag het aankomen en upgradede hun counter naar 64-bit, wat ruimte biedt voor ruim 9,2 triljard views. Ze maakten er een marketingmoment van door de counter even te laten "glitchen" als je er met je muis overheen ging. Of de counter daadwerkelijk brak of dat YouTube het preventief oploste? Dat liet YouTube bewust in het midden.
Testles: test voor groei. Wat vandaag onmogelijk lijkt, is morgen realiteit. Boundary testing (testen op de grenzen van wat een systeem aankan) voorkomt verrassingen.
Van een grappige bug naar een die 55 miljoen mensen in het donker zette.
11. De stroomuitval die een heel continent trof
Op 14 augustus 2003 viel de stroom uit in het noordoosten van de Verenigde Staten en delen van Canada. 55 miljoen mensen zaten zonder elektriciteit, sommigen tot twee dagen lang. De directe oorzaak was een softwarefout in het alarmsysteem van energiebedrijf FirstEnergy: een race condition (dezelfde soort fout als bij de Therac-25) zorgde ervoor dat operators geen waarschuwingen kregen toen hoogspanningslijnen oververhit raakten.
Zonder alarmen wist niemand dat er een probleem was. Wat als een lokale storing begon, cascadeerde daardoor binnen minuten naar een complete blackout.
Testles: test je alarmsystemen. Het mooiste monitoringsysteem ter wereld is waardeloos als de alerts niet aankomen. En ja, dit is ook een les over het testen van je testsystemen.
Alarmsystemen die falen klinkt abstract. De volgende blunder maakte het pijnlijk concreet.
12. Het raketschild dat niet beschermde
Tijdens de Golfoorlog in 1991 miste een Patriot-raketafweersysteem in Dhahran, Saudi-Arabië, een inkomende Scud-raket. De raket trof een Amerikaanse kazerne en doodde 28 soldaten. Het systeem had 100 uur onafgebroken gedraaid, en door een floating point afrondingsfout (een minuscule rekenfout bij het werken met decimale getallen) was de interne klok 0,34 seconden afgedreven. Bij een raket die met 1.600 meter per seconde vliegt, betekent dat een afwijking van meer dan een halve kilometer.
De fout was bekend. Er was zelfs een software-update voor verstuurd. Maar die was nog niet geïnstalleerd.
Testles: een bekende bug die niet gefixt wordt, is geen bug meer. Het is een keuze. En testen stopt niet bij het vinden van de fout, het stopt pas als de fix in productie draait.
Van een bekende bug die niet gefixt werd, naar een onbekende die overal verstopt zat.
13. De kwetsbaarheid die overal zat
In december 2021 werd Log4Shell ontdekt, een kritieke kwetsbaarheid in Log4j, een veelgebruikte Java-loggingbibliotheek. Het probleem: Log4j was zo wijdverspreid dat vrijwel elke grote organisatie ter wereld geraakt was, van Apple tot Amazon, van Minecraft-servers tot overheidsinstanties. De kwetsbaarheid maakte het mogelijk om op afstand code uit te voeren op servers, simpelweg door een speciaal geformuleerd stukje tekst te loggen.
Het meest verontrustende was dat veel organisaties niet eens wisten dat ze Log4j gebruikten, want het zat verborgen in andere software die ze hadden geïnstalleerd. Een SBOM (Software Bill of Materials, oftewel een inventarislijst van alle softwarecomponenten) had dit zichtbaar gemaakt, maar bijna niemand had er een.
Testles: weet wat er in je software zit. Als je niet kunt vertellen welke bibliotheken je applicatie gebruikt, kun je ook niet weten of ze kwetsbaar zijn.
Dertien verhalen, een rode draad
Dertien software blunders. Van ruimtereizen tot YouTube, van bestralingsmachines tot beursvloeren. De contexten zijn totaal verschillend, maar de onderliggende oorzaken vertonen een opvallende overeenkomst.
Telkens opnieuw ging het mis door dezelfde soort fouten: ontbrekende integratietests, blind vertrouwen op een enkel onderdeel, code die niemand meer begreep en aannames die niemand had gecontroleerd. Geen van deze rampen werd veroorzaakt door exotische, onvoorspelbare problemen. Het waren stuk voor stuk basale testprincipes die niet werden toegepast.
En dat is misschien wel de meest geruststellende les van allemaal, want het betekent dat je ze kunt voorkomen. Niet met dure tools of ingewikkelde processen, maar met discipline. Met de vraag: "Wat als dit misgaat?" Met de test die je schrijft voor het scenario dat niemand verwacht.
Dus de volgende keer dat iemand zegt dat testen "te duur" is of "te veel tijd kost", verwijs ze dan naar Knight Capital. Naar de Ariane 5. Naar de Therac-25. Want niet testen is altijd duurder.
Benieuwd hoe je jouw teststrategie naar een hoger niveau tilt? Of wil je gewoon eens sparren over waar je het meeste risico loopt? We denken graag met je mee. Plan een vrijblijvend gesprek
Bronnen
- NASA Mars Climate Orbiter, MCO Mishap Investigation Board
- Therac-25 – Wikipedia, Leveson & Turner, IEEE Computer 26(7), 1993
- Ariane flight V88 – Wikipedia, ESA/CNES Lions Report
- SEC enforcement action Knight Capital
- CrowdStrike IT outages – Wikipedia, CISA alert
- Year 2000 problem – Wikipedia, Y2K bug – Britannica
- Heartbleed.com, CISA OpenSSL advisory
- Boeing 737 MAX groundings – Wikipedia, PMC Engineering Ethics
- Toyota vehicle recalls – Wikipedia, Barr Group expert witness testimony
- TechCrunch, Variety
- Northeast blackout of 2003 – Wikipedia, NASA Safety message
- GAO Rapport Patriot Missile, University of Minnesota analyse
- Log4Shell – Wikipedia, CISA advisory
