Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Waar softwarefouten toe kunnen leiden

 

Computable Expert

Wilbert van den Bliek
Algemeen Directeur SQS BeNeLux, SQS BeNeLux. Expert van Computable voor het topic Development.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4672618). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Tja, leuk om te lezen, maar zo kan ik ook boeken vullen.

Waar software op een zolderkamer toe kan leiden: En zo kan ik heel veel successen noemen.

Er zit geen opinie in de opinie.

Het stuk bevat geen conclusie, geen mening, geen stelling (of nee, ik ben te kort door de bocht: Softwarefouten zijn nooit helemaal te voorkomen is stelling)

Ik wil geen mierenziften, maar dit kan ik missen.

@Henri

Muggen moet je ziften, met mieren doen ze iets anders ;)
(of zag je muggenneuken niet te zitten?)

Maar voor de rest ben ik het met je eens. Met een uurtje googelen kun je genoeg voorbeelden vinden op internet om een 10-delige reeks te vullen over dit onderwerp.

Van de algemeen directeur van SQS had ik meer diepgang verwacht.
Maar ja, ik ben dan ook geen expert

Klassiek voorbeeld is nog altijd een komma, die vergeten was in een Fortran-programma voor een Apollo raket. Vlucht mislukte dus.

Haha. PaVake en Henri helemaal eens.

Hier kan ik ook een bijbel overschrijven.

Best leuk om te lezen maar te veel inkoppertjes.

Ik vraag me af hoe interessant de volgende blogs verder in deze serie gevolgd worden als je met de eerste zo`n valse start maakt! Maar goed, ik ben benieuwd naar de volgende.

@heren H, R en R,

Zo te lezen kan ik nu ook afleiden wat een foutje in een blog voor impact heeft. Beetje positiever echter voor iemand die zijn nek hier voor het eerst uitsteekt had makkelijk gekund.

@Maarten,

Het is niet de eerste blog van Wilbert, zonder deze dubbel te tellen omdat precies hetzelfde verhaal ook bij BlogIT staat, zou het wel de eerste keer zijn als hij gaat reageren op zijn eigen stukjes. Betreffende het stukje zelf en de gebruikte voorbeelden is het ook nog maar de vraag of het verlies enkel en alleen te danken is aan een softwarefout. Ik vermoed dat het hier over foutje van Knight Capital in augustus vorig jaar en de Facebook IPO gaat.

@Maarten,
Het is niet het eerste artikel van Wilbert op deze site over aan de software gerelateerde zaken (testen, fouten etc). Bovendien hij is niet de eerste die zijn nek hiervoor uitsteekt, ik heb al eerder van andere schrijvers hieromtrent op deze site gelezen.
Persoonlijk maak ik uit de reacties hierboven op dat iedereen deze slappe introductie lastig/niks vindt.

Wat meer lading in het eerste deel van je verhaal kan geen kwaad zijn. De benoemde zaken hierboven weet iedereen al, ik zou eerder en zeker in het eerste deel van mijn opinie met een stukje van mijn verhaal/visie/idee komen.

@H en E,

in essentie bedoel ik dat opbouwende kritiek of suggesties beter werken voor een auteur dan, wat ik toch wel vaak tegenkom negativistisch. Ook al is dat vaak lastig, maar iets -, of -- is met een beetje moeite wel stimulerend voor de auteur te vertellen.

@M

Het is geen negativisme waaruit ik reageer maar een cynisme omdat dit soort stukjes meer marketing dan opinie bevatten. En het is natuurlijk aan de auteur om wel of niet de discussie aan te gaan, een leeswijzer te geven door meer duidelijkheid te verschaffen. Want uiteindelijk heb ik het idee dat een groot deel meer een vertaling is van andere stukken die ik hierover gelezen heb dan een opinie.

Maar misschien is dat Wilbert niet aan te rekenen maar het PR bureau dat deze stukjes op zoveel mogelijk platformen lijkt te plaatsen als onderdeel van de 'content marketing' strategie. Want in eerdere reactie had ik al een aantal andere zoektermen gegeven die in Google trouwens meer dan 1 miljoen hits opleveren. En hierin zitten een paar heel interessante stukken die duidelijk maken dat er meer lessen te leren zijn dan alleen maar testen.

Mijn vraag is namelijk of dat ene algoritme wat voor een verlies van $440 miljoen zorgde uiteindelijk nu wel of niet ontdekt was door testen. Ik denk namelijk van niet omdat het erop lijkt dat er namelijk wel getest is maar direct in een productieomgeving, iets wat trouwens wel vaker gedaan wordt. En omdat software fouten min of meer onvermijdelijk zijn ben ik benieuwd waar volgende opinie over zal gaan hoewel ik het eigenlijk al kan raden.

@all.
Auteur houdt het simpel.
Dat zouden meer mensen moeten doen

Inhoudelijk mag dit artikel niet sterk zijn, het maakt wel de discussie los. Wellicht is de reden dat het een inleidend stukje is en dat opzettelijk wat lichter is gehouden.

Voor de schrijver nog een aantal interessant punten mocht deze inspiratie nodig hebben.

Qua fouten kan je je afvragen of de gemiddelde gebruiker inmiddels niet is gewend dat computers fouten hebben en dat je daar maar mee moet leren leven. De gemiddelde 1.0 versie tegenwoordig heeft vaak nog meer fouten dan je van een beta versie zou mogen verwachten.

Maar bij de gevallen van medische technologie, vliegtuigen waar het toch fout ging waren er altijd redelijk zware eisen gesteld aan de kwaliteit van de software en waren deze wel degelijk uitgebreid getest maar toch ging het fout.

In diverse laboratoria opstellingen en een enkel praktijk geval zijn er wel degelijk projecten die een 100% werking garanderen alleen blijven deze voorbeelden vaak op de plank liggen.

@hk: Als het per se simpel moet is NuJij wellicht de site voor jou ;-)

Gekheid, maar van de reactie van Ewout wordt ik heel blij en zet me aan het denken.

Als "platform" vind ik dit soort artikelen als incident geen bezwaar, maar als trend verwaterd het wel de waarde van de site, een reden waarom ik nauwelijks meer op bijvoorbeeld een webwereld.nl kom. Niet dat alle artikelen daar slecht zijn, er zit soms hele goede tussen, maar ook veel rommel met dito reacties waardoor ik mijn interesse verloren ben en de goede artikelen missen dan maar voor lief neem.

Reza had een paar keer al wat auteurs aangesproken op het niet reageren op eigen artikelen waardoor de auteurs alsnog overstag gingen en er *wel* een goede discussie volgde.

Nouja laten we hopen op een spetterend vervolg van dit artikel waarbij alle kritiek verstomd. Kritiek geven mag toch? Houdt ons wellicht scherp, zolang het maar onderbouwd is en geen reageren om het reageren.

Kijk, weer een voorbeeld van een artikel waarin de afwezigheid van de auteur, een stuurloze discussie veroorzaakt heeft. Laten we het een keer hebben over de kwaliteit van de artikelen en ook de site!

@Henri, leuk dat je mijn actie gewaardeerd hebt! En leuk te zien dat een collega opiniehouder dit waardeert terwijl de redactie met 2x sterren minder waardering getoond heeft!


Zolas eerder gezegd, ik ben ook benieuwd naar het volgende artikel in deze serie!

@Ewout

Eigenlijk is het een taak van de redactie om dit soort (te oppervlakkige) verhalen direct terug te sturen naar de auteur.

@ Reza
als je uitrekent wat er aan ** uitgedeeld is tussen oktober 2012 en een paar weken geleden dan is dat in ~97% van de gevallen 3* de rest is of 2 en soms soms 4, kortom:

@Redactie schaf het ***dom af, u doet er niets mee gezien de scorecijferontwikkeling over de afgelopen maanden. Neem dan die tijd die daardoor "vrijkomt" voor een initiële kwaliteitsbeoordeling van wat dus wellicht geplaatst wordt.

Dat voorkomt "advertorials", te oppervlakkige stukjes en geeft wellicht ook nog zinvolle reacties, waardoor het geheel beter gewaardeerd zal worden door de lezer en wellicht daarna door de adverteerder.

@Maarten,
Het mee eens! Al lang roep ik dat de kwaliteit van deze site op verschillende punten verbeterd moet/kan worden. Deze hoeft niet perse geld te kosten als er maar een doordacht beleid ingevoerd is.
Computable.nl heeft alles om deze site interessanter te maken. (http://www.computable.nl/artikel/nieuws/ictbranche/4673648/2379258/computable-werft-magazineabonnees.html#4677083)

En wat betreft de sterren, tja als ik er gek op was dan had ik al lang geleden die op de grille van mijn auto NIET ingeruild voor een italiaanse schoonheid! :-)

waar software fouten toe kunnen leiden ...
een discussie over *** en de kwaliteit van de artikelen in computable


Ik weet zeker dat de auteur dit nooit bedacht heeft kunnen hebben :D

@PaVaKe

Software fouten is alleen maar een inperking van het begrip "fouten" door er software voor te zetten. Software op zich is niet echt fout, het is meestal de volgorde die niet goed is of de gedachte er achter, dus de stap naar sterren is eigenlijk maar een hele kleine, want dat is namelijk ook fout zoals het ingezet wordt.

Auteur beschouwt softwarefouten als nooit helemaal te voorkomen.
Ik denk dat dit niet waar is.
Belangrijk daarbij is te bedenken wat je als uitgangspunt kiest voor de te ontwikkelen software. Als dit goedgekeurde requirements zijn en, op basis daarvan, een goedgekeurd FO, dan kan het zo zijn dat de software feitelijk foutloos wordt gerealiseerd, maar uiteindelijk toch niet doet wat de gebruiker er van verwachtte. Iets dat afwijkt van de verwachting is dus niet per definitie fout. Hooguit fout beschreven.
Software die een verkeerd algoritme bevat kan verkeerde input hebben gekregen. Zeker bij bedrijfskritische applicaties is het van belang dat dit stap voor stap wordt gecontroleerd en, na realisatie, stap voor stap, wordt getest.
De eerste reeks controles moeten uitsluiten dat verkeerde input wordt geleverd. De tests moeten uitsluiten dat verkeerd geprogrammeerde software in productie wordt genomen. Zoals Numoquest al zei: het is I/O

Het 100% uitsluiten van fouten is een kostbare zaak, want arbeidsintensief, maar zeker niet onhaalbaar en bovendien afhankelijk van de complexiteit van het te ontwikkelen programma. De vraag zal uiteindelijk altijd zijn welk risico je bereid bent te lopen.

Heel veel problemen zijn terug te voeren op het vakgebied Human Error. Ik liep hier voor het eerst tegen aan toen ik een afstudeeronderzoek deed naar de risico's van spreadsheetgebruik binnen een organisatie.
Ray Panko is de goeroe op dit gebied. Zijn website ziet er niet uit, maar bevat wel interessante artikelen: http://panko.shidler.hawaii.edu/HumanErr/

@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

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 !

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×