Softwarefouten zijn nooit helemaal te voorkomen. In een vliegtuig zitten bijvoorbeeld gemiddeld nog honderden kleine foutjes in de software die niet direct voor gevaar zorgen. Het is dan ook zaak de grote fouten die tot de meeste schade kunnen leiden tijdens de ontwikkelfase op te sporen. Waar het in bij een vliegtuig om de veiligheid van mensen gaat, is vaker economische schade het gevolg. Hieronder drie gevallen rondom de handel in aandelen.
440 miljoen dollar verlies in 45 minuten
De nieuw geïnstalleerde software van een beurshandelaar heeft voor een schadepost van 440 miljoen dollar gezorgd in 2012. Met het systeem kan in drie kwartier grote hoeveelheden aandelen aan- en weer worden verkocht. Een fout in een software-algoritme zorgde ervoor dat de aandelen tegen een marktprijs werden verworven om vervolgens tegen een lagere prijs te worden verkocht. Op deze manier werd op elke transactie een paar dollarcent verloren. Door de levendige handel werd de prijs van de aandelen omhoog gestuwd. Het leidde uiteindelijk tot een gigantisch verlies voor de beurshandelaren, omdat ze noodgedwongen de tijdelijk overgewaardeerde aandelen tegen een lagere prijs moesten verkopen.
Beursgang gaat niet door
Een onderneming zag zich in 2012 gedwongen de geplande beursintroductie via het eigen handelssysteem af te breken. Oorzaak was een grote fout in de software, die leidde tot een technische storing op het eigen handelsplatform. Het probleem deed zich direct voor op het moment dat de beurs wilde overgaan tot de emissie van de aandelen en niet de normale handelsroutine kon volgen. Hierdoor kwam de handel in de aandelen al stil te liggen voor die goed en wel begonnen was.
Beursgang met hindernissen
Technologische problemen hebben ervoor gezorgd dat de handel in aandelen van een grote social netwerksite in 2012 ernstige hinder ondervindt. Naderhand wordt duidelijk dat een softwarefout er de oorzaak van is dat biedingen en annuleringen niet correct of zelfs helemaal niet worden verwerkt. Deze uitglijder zorgde ervoor dat uiteindelijk niet minder dan dertig miljoen aandelen niet op de juiste manier zijn afgehandeld.
Dit is een eerste blog in een serie over de schade die kan ontstaan als het gevolg van fouten in de software.
Ben weer te snel met drukken. Maar je ziet dus dat de realiteit is inderdaad wat je schrijft:
“Als het uitgangspunt nu ineens wordt dat de informatie pp de etiketten niet foutloos, c.q. onbetrouwbaar is, dan is dat de omgekeerde wereld. Het zou toch te gek zijn als supermarkten op hun etiketten gaan zetten dat de informatie niet foutloos is, maar dat –analoog aan H. Koppen- “het product daarmee niet oneetbaar of slecht is”?”
Ook producten in de supermarkt zijn niet foutloos, maar je hoeft dat er gelukkig niet op te zetten net zoals je niet op software hoeft te zetten dat het niet geheel foutloos is.
En foutloze producten zijn net als foutloze software niet mogelijk! Dat betekent niet dat de supermarkten kunnen sluiten 🙂
Tada!
“niet extra veel moeite om de software die je toch al moest schrijven, in een keer goed en netjes af te werken”.
Ik denk dat die quote van Pascal doelde op zoiets als destjids het strcpy vs strncpy probleem. Veel programmeurs gebruikte strcpy, maar dat leidde toch geheugenlekken. Strncpy kost iets meer werk en moeite omdat je moet uitzoeken hoeveel er gekopïeerd moet worden.
Grappig, toen ik op zoek ging naar bugless software op Google kwam ik op een discussie uit die over de definitie van een “bug” ging.
Technici zullen een duidelijk beeld hebben over functioneren onder normale omstandigheden. Zo zal je systeem jaarlijks langs de zomertijd en wintertijd verandering komen, maar het zal geen rekening hoeven houden met wanneer pasen en pinksteren op dezelfde dag vallen.
Om dit nu meteen een “flut artikel” te noemen is mij te voorbarig. Niet iedereen heeft deze kennis/ervaring. Zowel binnen als buiten de IT-branche. En juist een dergelijke houding is de reden waarom IT vaak niet op waarde geschat wordt door de business. Opvallend is dat zelfs ervaren/bekende “leveranciers” van reacties dit niet inzien. Artikelen over de slechte communicatie tussen IT en business staan hier ook met regelmaat en worden ook als waarheid beschouwd door dezelfde leveranciers van reacties. Maar het feit dat men nu weer dit artikel afbrandt stelt mij zeer teleur en doet mij afvragen wat nu de doelstelling is van deze leveranciers van reacties. Waarschijnlijk dus inderdaad alleen het leveren van reacties!
Gevalletje van “jammer”? Yep!!!!
Maar goed, ik zie de reacties wel weer op me afkomen. Zal waarschijnlijk gaan op spelfouten e.d.
Een aardige reclame waarom we beter moeten testen, maar die conclusie mis ik.
Ook de kleine fouten kosten soms veel geld. Denk allemaal eens na over welk probleem we voor ons uit schuiven. We weten het wel, maar zo’n vaart zal het toch niet lopen.
Maurice, je hebt uiteraard gelijk… MAAR….
– Testen is moeilijk
– Testen is duur
– Testen is geen garantie
– Wat moet je testen ?
Lijkt me redelijk om aan te nemen dat specs en gevraagde functionaliteit wel getest wordt
Maar wat testen we nog meer ?
– Wie gaat er testen ?
– Hoe gaan we testen ?
En dat zijn dan nog maar een paar simpele vragen gesteld door iemand die van testen geen verstand heeft !