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.
@hk
Een probleempje, je weet nooit of je software compleet foutvrij is. Dat blijkt pas in de praktijk. Als het even mee zit, heb je de meeste ellende eruit en als het live draait komt er in de regel nog meer boven drijven. En dan nog als je denkt er te zijn zit er altijd nog een ongeluk in een klein hoekje. 100% foutvrij is naar mijn mening ook niet vast te stellen.
@hk: Je denkt veel te “nauw”, fout in software gaat dieper dan requirements. Wat als je foutloze software heeft maar die kan niet omgaan met het wegvallen van verbindingen (waardoor er fouten kunnen ontstaan). Input kan dan perfect in alle geteste gevallen leiden tot correcte output en dan nog kunnen er fouten in de software zitten. Of dat vreemde tekens ineens tot foute weergave leiden. Of dat variabelen in tijdelijk geheugen worden geschreven terwijl dit tot fouten leidt als er schaalvergroting wordt toegepast. Dit zijn slechts een paar voorbeelden.
Er bestaat nagenoeg geen foutloze software (definieer een fout) met als enige uitzondering zeer beperkte software die nauwelijks iets kan.
Nothing has to be perfect 🙂
@Henri: Eigenlijk wat je als laatste zegt ontkracht je betoog. Zeer beperkte software kan heel makkelijk foutloos zijn.
Naar mate de functionaliteit toeneemt echter kost het meer moeite, lees: tijd en geld om iets foutloos te krijgen.
Dan treed het kosten/baten principe in werking. Er zijn ook nog dingen zoals het ’time-to-market’ principe en geaccepteerd risico.
is it a bug or is it a feature, that is the question, …..vrij naar..
@Henri. Nou, ik denk niet te nauw, denk ik.
Als het uitgangspunt is dat software niet foutloos is dan kunnen we met zijn allen wel inpakken. Dan is alles best effort; niet alleen het ontwikkelen, maar ook het leveren, onderhouden, herstellen en wijzigen. Want de software, en daarmee het systeem is dan dus nooit foutloos.
Onlangs werd het tot nu toe grootse priemgetal gevonden, dat bestaat uit 17.425.170 cijfers. Dat kunnen we onmogelijk controleren. Sterker, we moeten er dus eigenlijk rekening mee houden dat een fout in de software de uitkomst onbetrouwbaar maakt. Tenzij de software zo simpel is dat zij foutloos werkt en slechts afhankelijk is van de beschikbare rekenkracht van de computers. Maar de foutloze werking van software kan alleen maar worden bewezen voor zover wij het zelf na kunnen rekenen. In dat geval moeten we dus aannemen dat de software foutloos werkt, ook als de uitkomsten niet meer controleerbaar zijn.
Ergo, voor zover de uitkomsten van toegepaste software controleerbaar is, is die software wel degelijk foutloos te krijgen. Naarmate de complexiteit, dan wel de uitkomsten niet meer controleerbaar zijn, hebben we in toenemende mate rekening te houden met afwijkingen.
Zie het als een laserstraal die in een vastgestelde hoek de ruimte inschiet. Op 1000 meter is haar eventuele afwijking onmeetbaar, op 1000 lichtjaar is haar afwijking niet controleerbaar, maar wellicht honderdduizenden kilometers.
@hk: Ik pak de handschoen gewoon weer op 🙂
Hoezo inpakken? Je bekijkt het veel te zwart-wit. Een auto functioneert vaak foutloos, maar door de tijd heen gaan er dingen stuk (en kunnen er fouten optreden). Als het onderweg gebeurt komt de Wegenwacht langs en geeft je een fix zodat je weer verder kan of sleept je naar een garage.
Wat ik bedoel te zeggen is dat fouten niet per se slecht zijn en dat fouten ook later op kunnen treden als de software in gebruik is. Belangrijker is hoe manage je de risico’s? Want software of diens afhankelijkheden veranderen door de tijd heen, je moet het pragmatische managen.
Bij een Marsmissie zijn fouten zeer duur, maar voor chatsoftware hoeft een foutje niet te betekenen dat de dienst onbruikbaar is.
Dan je voorbeeld over priemgetallen…. Wat een nerd voorbeeld 🙂 Who cares? En je kunt het wel zeker controleren door de berekening over een jaar met krachtige computers alsnog te berekenen op een ander systeem en wellicht algoritme. Dus “Onmogelijk” is dan ook weer ontkracht, haha.
Maar goed, het onderwerp is nu wel uitgekauwd naar mijn mening.
Nog even herkauwen.
Eerst te nauw, dan te zwart/wit.
Kijken of ik er nog een dimensie aan toe kan voegen.
Als het uitgangspunt is dat software foutloos is dan zijn we goed bezig, zelfs als we rekening houden met risico’s. Als het uitgangspunt is dat het niet foutloos is dan kunnen we wel inpakken.
Als we onszelf marktleider in software ontwikkeling noemen en we zeggen tegelijkertijd dat software niet foutloos is dan vraag ik me af of dat reclame is voor het bedrijf. Als we bedoelen dat we marktleider zijn om dat we de minste fouten in software maken dan is dat marketing, maar daarbij accepteren we het fouten maken in software als een gegeven. En nogmaals: dat laatste geloof ik niet.
Het uitgangspunt bij het etiketteren van producten is dat er precies op staat wat er in zit. Consumenten vertrouwen daarop. 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”?
Ik begrijp niet waarom ‘profesionals’ naar aanleiding van zo’n mager weinig zeggend maar wel herkenbaar artikel op deze manier discussieren.
Natuurlijk, het is tot op zekere hoogte mogelijk om het correcte functioneren van software mathematisch aan te tonen. Daar vallen echter al allerlij factoren als interrupt situaties, invloeden van andere software delen, eventueel het OS al buiten.
Nog maar even niet te spreken over een domweg onjuiste specificatie dan wel uitvoering van de gewenste functionaliteit zoals het voorbeeld dat Wilbert aankaart.
Uit de discussie krijg ik echter de indruk dat software die door onkunde, gemakzucht, economische overwegingen of ander vormen van gepruts gewoon bagger in elkaar geflanst is gewoon geaccepteerd moet worden.
Dit is nu net waarom het elke keer weer fout gaat ! pay peanuts get monkeys.
Het is (zo leert mijn ervaring) niet extra veel moeite om de software die je toch al moest schrijven, in een keer goed en netjes af te werken en je daarbij eenvoudige dingen af te vragen als:
– Wat ik doe, kan dat eigenlijk wel ? en wat doe ik als het niet kan ?
– Wat ik doe, begrijpt mijn vakcollega dat ook ? en als dat niet zo is, waarom dan niet ?
– Als het niet werkt, hoe kom ik er dan achter waarom het niet werkt en hoe lost ik het vervolgens op.
En zo is er nog een heel scala aan overwegingen vast te hangen die eenmaal ingeburgerd weinig extra moeite kosten en veel gelazer achteraf voorkomen.
Zo heeft het bijvoorbeeld weinig zin om (door mij zo gehate) java toepassingen vol te duwen met stacktraces in een exception als de gebruiker dan wel applicatie beheerder geen flauw idee heeft wat al die meldingen inhouden. Een simpele melding die aangeeft wat er fout gaat is evenveel tikwerk.
Zo kan een applicatie die een netwerk verbinding niet voor elkaar krijgt gewoon keurig na een timeout een melding geven wat het probleem is. kleine moeite.
@Henri sorry je opmerking over priemgetallen deel ik totaal niet.
Het ging hier slechts om een voorbeeld, waneer jij in een vliegtuig zit dat van de juistheid van deze priemgetallen afhankelijk is, dan is het welliswaar specialistisch geneuzel maar niet iets waar aleen een nerd zich mee hoeft bezig te houden maar waar ook academici zich mee bezig houden.
Waneer je niet in staat bent een correct werkend chat programmaatje te schrijven,
blijf dan liever ook van grotere projecten vandaan (dit uiteraard naar analogie want we hebben het uiteraard over heel andere vakkennis)
Ook het voorbeeld over slijtage van een auto deel ik niet. Software slijt immers niet.
(Nu ja wat heet, onder Windows zorgen o.a. updates er wel voor dat de prestaties steeds beroerder worden)
Mischien lijkt ik een oude zeur, maar dat komt vast omdat ik komende week weer wat dichter bij de catagorie ‘duurdere werknemer’ behoor….
@Pascal : Kijk, het artikel was flut, de discussie vind ik zelf erg leerzaam om dat HK mooi zijn argumenten verdedigd en ik dus weer geprikkeld wordt om opnieuw na te denken.
Priemgetallen zijn de bom, ook als het aankomt op dingen als hashen en versleutelen, maar uitrekenen tot 17.425.170 cijfers valt in de categorie mooie uitdaging, maar als **software** bevat het geen functionaliteit waardoor het als voorbeeld van foutloze software niet sterk is.
Op mijn beurt ben ik het niet eens met “niet extra veel moeite om de software die je toch al moest schrijven, in een keer goed en netjes af te werken”. Zoals je als duurdere werknemer (c.q. freelancer) weet staan projecten altijd onder druk van budget, deadlines en vaak incompetentie specificaties waardoor je vaak niet de kans krijgt om zaken netjes af te werken omdat dat te duur en te lang duurt.
@HK: Mooie analogie over etiketten op voedsel! Maar zie hier een groot verschil met software. Zo’n beetje ieder (gecertificeerd) productie proces bevat controles. De output wordt gecheckt en daardoor is de foutkans, dus dat een potje een verkeerde inhoud heeft zeer klein. Het een een volwassen cyclus. Software daarentegen is het Wilde Westen, ieder neefje kan software schrijven en dat mag ook nog verkocht worden en wellicht gebruikt binnen (grote) ondernemingen.
Maar goed, ik schrijf al jarenlang software en ik weet zeker dat geen van deze software foutvrij is. Veel software is ook een levend iets en zeker tegenwoordig met veel iteraties en releases. Kan ik dan inpakken? Nee, want net als bij het productie proces van potjes dek ik zaken in door controles, audit trails en andere zaken zodat ik een mogelijke fout kan herstellen. Ik ben gewoon pragmatisch.
Zo heb ik een prachtige SOAP webservice gemaakt voor bepaalde data communicatie. Leek foutloos, heeft al miljoenen batches verwerkt. Totdat er een batch van 1 GB aankwam en ik een geheugenfout niet had afgedekt waardoor die batch in de soep liep maar verzuimde de aanroeper hiervan op de hoogte te stellen. Fout ja, maar kon ik daardoor inpakken?
Enfin, we weten allebei wellicht wat we bedoelen…
PS: @HK oh, de ironie!
http://www.nu.nl/binnenland/3354511/supermarkten-doen-extra-tests-vanwege-paardenvlees-.html