Ben ik aansprakelijk voor de fouten in mijn software?

bug-fout.pngEen lezer vroeg me:

Ik heb als freelancer een stukje software gemaakt voor een groot bedrijf. Nu melden ze me dat er een bug in zit waardoor ze maanden aan data kwijt zijn, en ze willen mij aansprakelijk stellen voor de schade! Ik werk eigenlijk altijd zonder algemene voorwaarden, omdat ik niet houd van dat formele gedoe, maar nu maak ik me toch wel zorgen. Kunnen ze zomaar een grote claim indienen?

Dat zou zomaar kunnen inderdaad. Wanneer een leverancier geen algemene voorwaarden hanteert, dan geldt de wettelijke regel voor aansprakelijkheid. Die zegt dat de ontwikkelaar aansprakelijk is voor alle schade, als de fout hem te verwijten was. Daarvan is kort gezegd sprake als hij niet de gebruikelijke mate van zorg heeft betracht die een normaal ontwikkelaar in acht zou nemen.

Het zal dus aankomen op de aard van de fout. Was dit een zeer subtiele moeilijke fout of juist een triviale bug die de vraagsteller gewoon had moeten ontdekken bij het testen? En zit de fout wel in de door hem geleverde code, of zit het hem in de interactie tussen zijn code en die van het bedrijf? In het laatste geval is het moeilijk de ontwikkelaar te verwijten dat de fout er zat.

Ik moet zeggen dat ik schrik van hoe veel programmeurs blijken te werken zonder algemene voorwaarden, of met een generiek modelletje van de Kamer van Koophandel of van een op internet gevonden concurrent dat dan net niet de clausules heeft die je wilt. Of die wel aansprakelijkheid uitsluit maar dan zó ver gaat dat de clausules ongeldig zijn (“Leverancier is te allen tijde nergens voor aansprakelijk”).

<reclame style=’schaamteloos’>Het starterspakket voor softwareontwikkelaars van mijn bedrijf zou hier goed geholpen hebben.</reclame> De ICT~Office voorwaarden zijn ook een gratis optie, hoewel die dan weer zó eenzijdig zijn dat grote klanten ze vaak direct afwijzen. Maar in gevallen als deze helpen ze wel: vorig jaar kon een ontwikkelaar een schadeclaim pareren van 300.000 euro dankzij de algemene voorwaarden.

Meelezende ontwikkelaars: Hoe zijn jullie gekomen tot de algemene voorwaarden die je nu hebt?

Arnoud

41 reacties

  1. Dan nog moet de schade wel reëel zijn. Misschien ben je verantwoordelijk voor de bug, maar het bedrijf had dataverlies over zo’n enorme periode kunnen voorkomen door fatsoenlijke backups. Mij lijkt dus dat de verantwoordelijkheid van de leverancier beperkt blijft tot bijvoorbeeld dataverlies

  2. Wat ter bescherming van de programmeur in kwestie ook nog geldt is wel dat er een correcte verhouding moet zijn tussen de ontstane schade en hetgeen de programmeur hiervoor aan gage heeft ontvangen.

    Ik kan mij een voorbeeld herinneren uit de juris prudentie wat ging over een casus tussen een kraanverhuurbedrijf en een aannemer. De kraan viel om en richtte heel wat schade aan. De aannemer heeft de schade proberen te verhalen op het kraanverhuurbedrijf maar de rechter wees dit af. De ontstane schade stond niet in verhouding tot de paar honderd euro die het kraanverhuurbedrijf in rekening bracht.

  3. @Bram: Klopt, dat is het Vliegtuigvleugel-arrest. Met de kraan werd een vliegtuigvleugel overgeladen, en door een kapotte bout viel het ding en dat leverde zo’n 50.000 euro schade op. In beginsel is de verlader aansprakelijk voor schade bij het uitvoeren van zo’n klus, maar in dit geval niet, vond de Hoge Raad. Aansprakelijkheid kan worden beperkt als deze onredelijk is om toe te rekenen, met name wanneer

    het falen van het werktuig aan de wederpartij een schade kan berokkenen van een dergelijke omvang dat het, gezien de in verhouding daartoe geringe hoogte van de door de schuldenaar genoten contra-prestatie, onredelijk zou zijn de schuldenaar het risico daarvan te doen dragen;

    Ook speelde mee dat de andere partij (de vliegtuigbouwer, Fokker) zich prima had kunnen verzekeren tegen dergelijke schade maar dat niet had gedaan. Maar dat is bij softwarefouten zo goed als onmogelijk.

  4. Ik vind de opmerking van 2. Richard wel interessant. In hoeverre is de ontwikkelaar nog aansprakelijk voor dataverlies als het bedrijf zelf niet eens aan fatsoenlijke back-ups doet? Ze hadden vast geen maanden dataverlies geleden als ze netjes elke week een back-up van de data hadden gemaakt.

  5. Zelf werk ik niet freelance maar ben gewoon een loonslaaf. Dat geeft wat meer zekerheden. Ik heb vaak genoeg samengewerkt met freelancers en merk dat ze het financieel niet echt beter doen dan loonslaven. Okay, als ze werken verdienen ze goed. Alleen, iedere vrije dag die je wilt hebben is een dag zonder winst. Huisarts-bezoek, tandarts, e.d. is allemaal op eigen kosten. En daarnaast moet je er altijd rekening mee houden dat je na je opdracht een nieuwe werkgever nodig hebt, dus sparen voor een eventuele lange overbruggings-periode… Kortom, ik vind het niet al te aantrekkelijk werk, freelance… Heb in het verleden wel aan open-source projecten gewerkt, waarbij ik eigen code heb vrijgegeven onder de “gebruiken op eigen risico” licentie. (En niet veel meer dan dat eigenlijk.)

    Maar om terug te komen op deze zaak… Maanden aan data weg? Hoe kan dat? Data beschadigd en de dagelijkse/wekelijkse backup ook beschadigd? Ook belangrijk, heeft de freelancer meegewerkt aan een bestaand project of een nieuw project opgeleverd? Meewerken aan een bestaand project betekent dat er een andere persoon als projectleider verantwoordelijk is geweest. En natuurlijk: wat is er nou fout gegaan? Want alle data van de afgelopen maanden weg? Da’s net zo’n duidelijke foutmelding als: het scherm doet het niet meer.

  6. @SpacyRicochet De wet kent het concept “eigen schuld” waarmee de hoogte van de schadevergoeding kan worden ingeperkt. Vaak kijkt de rechter dan naar de mate waarin het eigen handelen bijdroeg aan de schade. Zo zou hij bijvoorbeeld een 50/50 verdeling van de schade redelijk kunnen achten vanwege eigen nalatigheid.

    Als je als klant mag verwachten dat de softwareleverancier ook de backups maakt, dan gaat “eigen schuld” niet op. Ik mag bij een SaaS-dienstverlener verwachten dat ie mijn ingevoerde gegevens backupt. Als dan blijkt dat hun backups zes maanden oud zijn, dan kan ik ze gewoon aansprakelijk stellen voor de schade.

  7. Maanden data weg kan eigenlijk alleen als software de data corrupteerd zondar dat men dit merkt en de backups dus ook al maanden niet meer kloppen.

    En tenzij je SaaS gebruikt is het dus gewoon je eigen verantwoordelijkheid om je data te backuppen. Als bedrijf zou ik zeggen periodiek een full backup en dagelijks een incremental backup van je data. Hoe vaak je een full backup doet hangt er vanaf hoe snel je data van je backup terug wil halen. Ik ken ondernemingen die ieder weekend een full backup doen en iedere maand. Je bent dan hoogstens de data kwijt tussen het onstaan van de corruptie en het ontdekken daarvan.

  8. Ik kan helaas niet in detail aangeven waardoor de data is kwijtgeraakt, want ik heb natuurlijk de anonimiteit van de vraagsteller te respecteren.

    Laten we zeggen dat het inderdaad een SaaS dienst is, waarbij de vraagsteller een extensie had gemaakt die consequent een foutje in ingevoerde data doorvoerde. Denk dan aan iets als een afrondings- of conversiefout waardoor getallen subtiel incorrect zijn maar niet zo evident dat je dat bij testen merkt. Een voorbeeld daarvan is rekenen met geldbedragen in floating point variabelen.

  9. Ik weet niet wat er met mijn post #2 is gebeurd. Er is een stukje weggevallen en nu is de betekenis nogal veranderd. Die had als volgt moeten eindigen: “Mij lijkt dus dat de verantwoordelijkheid van de leverancier beperkt blijft tot bijvoorbeeld dataverlies over de periode van de laatste dag.

    Als het inderdaad gaat om (logische) fouten in accounting dan wordt het wel tricky. Je mag van een stuk accounting software wel verwachten dat er correct geteld wordt. Zelf probeer ik altijd SOX achtige mechanismen te maken die bijvoorbeeld de oorspronkelijke waarde van gewijzigde records opslaat. Heeft me al vaak genoeg gered (“database leeg? Ja, die is dus geleegd om 10:15 door user jjansen, hier was de oorspronkelijke data en nu beter opletten he”).

  10. Als het een SaaS-dienst betreft, wie levert dan deze dienst? Indien de freelancer deze dienst aan het bedrijf levert dan is dat dikke pech voor de freelancer, volgens mij. Maar ben je dan wel een freelancer of een dienstverlener? Als het bedrijf zelf de SaaS heeft overgenomen van de freelancer dan valt het beheer ervan ook onder de taken van het bedrijf. En dat is inclusief het maken van backups van de data op de SaaS server.

    Maar goed, een extentie die een kleine fout aan data toevoegde die maandenlang niet is opgemerkt? Als het niet opvalt, hoe kostbaar kan het foutje dan zijn? Of heeft de freelancer voor UBS gewerkt en zijn ze 2.3 biljoen Euro kwijt? 🙂 Hoeveel is een grote claim uiteindelijk?

    Volgens mij kun je je als freelancer verzekeren tegen dit soort schadeclaims. Lijkt mij ook heel verstandig voor alle freelancers. Geen idee waar je dan moet zijn, maar het lijkt mij wel erg verstandig…

  11. @Richard: weet niet wat er met je tekst gebeurd is, misschien was je vergeten de <b> tag te sluiten?

    @Wim: Het bedrijf draaide de software op een eigen server, met de extensie van de developer erop. Die extensie heeft maandenlang gedraaid en dus maanden aan data subtiel stuk gemaakt. Dan zijn de backups dus ook corrupt.

    Verzekeren tegen ICT-fouten is verdomde moeilijk en in ieder geval behoorlijk duur.

  12. Denk dan aan iets als een afrondings- of conversiefout waardoor getallen subtiel incorrect zijn maar niet zo evident dat je dat bij testen merkt

    Het is effectief eeingelijk niet mogelijk voor ontwikkelars om foutloos te programmeren. Alle enigzins omvangrijke software bevat dus diverse fouten. Zeker fouten die niet in een test zijn op te sporen zijn dus eingelijk onvermijdelijk. Hoe had de programmeur deze fouten ooit moeten kunnen vinden in zijn programmatests als het de gebruikers die het programma dagelijks gebruiken maandenlang is ontgaan.

  13. Mijn vraag hier is “wat is er door de opdrachtgever gespecificeerd?” Als de opdrachtgever nalatig is geweest in het specificeren van de gewenste nauwkeurigheid (of afrondingsrichting) is zij mede-schuldig.

    Ik ken uit eigen ervaring nog een gevalletje afrondprobleem, veroorzaakt door een specificatiefout: Bij buitenlands geld transacties voor een bank wordt afgerond op hele centen (natuurlijk altijd in het voordeel van de bank.) Nu stond bij het maken van het dagoverzicht gespecificeerd dat dezelfde rekenmethode “koers maal totaal buitenlands valuta, afronden in het voordeel van de bank” toegepast moest worden. Gelukkig grepen de accountants in voordat het systeem vol in productie was en ze duizenden centen moesten corrigeren.

  14. @hAl: Omdat iedere knuppel die programmeert, weet dat floatingpointrepresentaties fundamenteel ongeschikt zijn voor geldbedragen? 2.0000000000+2.0000000000 is niet noodzakelijkerwijs 4.0000000000 in de meeste talen. Terwijl 200+200 wel 400 is en je dat prima kunt omzetten naar 4,00 als je het op het scherm zet.

    @Bram: Ik denk dat zo’n top tien zó algemeen wordt dat je er weinig aan hebt. Is het Van Genk-arrest (dat je bij maatwerk soms broncode kunt opeisen) belangrijker dan het Runescape-arrest (dat virtuele goederen te stelen zijn) of dat arrest van laatst dat rechters niet mogen googelen?

    Misschien is ’t handiger als je gewoon ons boek Software koopt 😉 Daar staan ze allemaal in.

  15. @Arnoud Niet iedere programmeur weet dat omdat het ook niet in alle programmeer talen zo werkt. Verder is de mogelijke afwijking in floating pointberekeningen die veroorzaakt wordt door het floating point mechanisme zo kleine dat het op normele bedragvelden met twee cijfers achter de komma’s vrijwel nooit significante uitwerking zou moeten hebben.

  16. @Arnoud, kortom, de freelancer heeft een product (extensie) geleverd aan het bedrijf. Of heeft hij deze samen met het bedrijf ontwikkelt? Ik denk namelijk dat dit ook meetelt, want bij samen ontwikkelen heb je ook samen schuld. Maar als hij gewoon een maatwerk-product heeft opgeleverd dan is hij meer een producent, geen freelancer.

    Qua verzekeren denk ik dan aan een BeroepsAansprakelijkheidsVerzekering. (BAV) Maar dat is een zakelijke verzekering en dan ben je als freelancer eigenlijk een eenmans-bedrijf met eventueel een KvK inschrijving en andere zaken. Je kunt misschien als freelancer zonder “officieel bedrijf” ook je Wettelijke Aansprakelijkheidsverzekering aanspreken voor de schade. Want je zou kunnen stellen dat de freelancer voor deze opdracht een soort uitzendkracht was en niet een zakelijke partner. Ofwel, is de freelancer in dit geval wel of geen ZZP‘er? Is hij betaald per uur of per product? Een BAV blijkt inderdaad wel EUR 1.000 of meer te kunnen kosten en is eigenlijk onbetaalbaar voor een ZZP’er.

    Betreffende de fout, hoe ernstig kan dit zijn en om wat voor soort data gaat het uiteindelijk? Hebben honderden klanten hierdoor maandelijks een paar centen teveel of te weinig overgemaakt? Of is een wetenschappelijk onderzoek met maanden werk compleet waardeloos geworden? Ofwel, het soort data lijkt mij mede te bepalen hoe de verantwoordelijkheid uiteindelijk ligt. Als het supergevoelige data is die absoluut correct moet zijn dan had het bedrijf toch een zwaardere onderzoeks-plicht gehad. Dan hadden ze beter moeten testen.

    Overigens, belastingtechnisch lijkt het mij dat de freelancer de schade van zijn omzet kan aftrekken en dus minder belasting hoeft af te dragen.

    Even terug naar de BAV. Volgens mij biedt RVS een ZZP/BAV verzekering voor 30 Euro per maand. Zitten vast addertjes onder de grond maar kan het voor een freelancer niet een optie zijn om naar een dergelijke verzekering te zoeken? (Voor deze freelancer dus te laat, maar voor de overigen?)

  17. @hAL, ik kan tot in detail ingaan op de risico’s van het gebruik van IEEE 754 floating point rekenwerk in financiële toepassingen, maar dat valt buiten het bestek van deze blog. (En Arnoud, in IEEE is 2.0 + 2.0 gelijk aan 4.0; gehele getallen binnen het mantissa-bereik hebben een exacte representatie; maar 2.10 + 2.01 != 4.11) Maar zelfs als je bedragen in centen bijhoudt betekent het berekenen van BTW dat je even heel goed moet nadenken hoe je je BTW bedrag op centen afrondt zodat je geen last met de belastingdienst krijgt.

  18. @Arnoud, 2.0000000000 + 2.0000000000 is in ALLE talen ALTIJD 4.0000000000! 🙂 Maar als je andere getallen als voorbeeld neemt klopt het wel. Werken met floating-point getallen is altijd lastig omdat dergelijke getallen bestaat uit de mantisse, het grondtal en de exponent. Voor computers is het grondtal altijd 2 dus het enige dat je moet bewaren is de mantisse en de exponent. Eigenlijk met 2 als mantisse en 0 als exponent, of 1 als mantisse en 1 als exponent. En 4 noteer je als 4, 2, of 1 in de mantisse en 0, 1 of 2 als exponent. Het is in het begin lastig maar als je eenmaal floating-points begrijpt kun je heel wat afrondingsfouten voorspellen.

    Waar uiteindelijk de problemen kunnen ontstaan is in de hoeveelheid geheugenruimte die je hebt voor de mantisse en exponent. Hier is de IEEE 754 standaard voor ontwikkeld en deze wordt door zo’n beetje alle talen ondersteund. (Ik zou niet weten welke het niet ondersteunen!) Het Single datatype is 32-bits lang, waarvan 8 bits voor de exponent. Zowel mantisse als exponent hebben een teken-bit waardoor de exponent varieert van -127 t/m 128. De mantisse is ergens tussen de -8 miljoen en +8 miljoen. Afrondingsfouten zullen zich dan zeker voordoen bij getallen buiten dit bereik omdat grotere getallen niet meer in de mantisse passen. (Bedenk wel dat je ook achter de komma moet meetellen dus bij bedragen is het bereik maar tussen de +/- 80.000 Euro. Dergelijke fouten kunnen ook ontstaan indien je berekeningen gaat uitvoeren met dergelijke getallen waarbij het eindbedrag of tussenresultaat over deze grens heen gaat. Afrondingsfouten komen ook voor bij delen en worteltrekken en bij dergelijke berekeningen gaat het al vrij snel fout. Je moet dan ook goed rekening houden met het bereik van de gekozen datatypes en het soort berekeningen dat je gaat uitvoeren.

    Doordat floating-points zo enorm generiek zijn zou iedere programmeur dus goed moeten begrijpen hoe ze werken en waar de beperkingen liggen. Je moet daarna ook gaan bepalen hoe groot de afrondings-fouten kunnen worden door het gebruik van dergelijke getallen. Dat bepaalt de betrouwbaarheid van de berekeningen. En of je nou met PHP onder Linux, Objective C op de Apple/iPad of VB.NET onder Windows werkt, floating-points zijn gewoon generiek. Dit is basiskennis, waarvan ik heb gemerkt dat veel programmeurs dit gewoon vergeten zijn of nooit hebben geleerd. Bij deze dus. 🙂

  19. Betreffende voorbeeldje van Mathfox, die klopt niet helemaal. Met exponent 0 krijg je voor 210 ‘11010010’ voor de mantisse, 201 wordt ‘11001001’ en past ook mooi in de mantisse. Zelfs 411 (110011011) past mooi in de mantisse van 24 bits. Alleen, het grondtal van de exponent is 2 terwijl wij een grondtal 10 gebruiken om 2.10, 2.01 en 4.11 weer te geven. En helaas, 10 is niet te verkrijgen als exponent van 2. Daardoor is er een kans dat Mathfox zijn bewering onjuist is. Even denken… Kun je 2.10 of 2.01 met een bepaalde exponent vermenigvuldigen (of delen) waardoor een geheel getal ontstaat? Helaas niet, dus heeft MathFox in dit geval gelijk. 🙂 Had hij 2.5 gekozen dan had het wel gekund. Maar 2.05 zou weer mis gaan. Maar 2.25 (x4) en 2.125 (x8) en 2.75 (x4) zouden weer wel passen in de mantisse met bijbehorende exponenten.

  20. De ICT~Office voorwaarden zijn ook een gratis optie, hoewel die dan weer zó eenzijdig zijn dat grote klanten ze vaak direct afwijzen.

    Hoewel de voorwaarden van ICT~Office vergeleken met een maatwerkoplossing heel goedkoop zijn met ???10,- ex btw, zijn ze niet helemaal gratis te gebruiken 😉

    Verder wederom een mooi artikel en tevens ’n eyeopener om als kleine part-time ZZPer toch ook eens budget te gaan maken voor een fatsoenlijke set algemene voorwaarden, een claim zoals de in de post genoemde is wel de nachtmerrie van iedere zelfstandige natuurlijk.

  21. @hAL #19

    Niet iedere programmeur weet dat omdat het ook niet in alle programmeer talen zo werkt.
    W ten Brink heeft al een mooie uitleg gegeven, nog even benadrukken: floating point representaties en de bijbehorende eigenschappen zijn eigenschappen van de processor(-architectuur) en niet van de programmeertaal. Hooguit heeft een bepaalde programmeertaal wel of geen floating point ondersteuning, maar ik ken geen enkele programmeertaal die wel floating point operaties ondersteunt maar dat op andere wijze dan bv IEEE 754 doet.

    Kortom: bij elke programmeertaal die floating point ondersteunt heb je met deze issues te maken. Ook in niet C-achtige talen!!

  22. @Richard Wat nog wel kan is dat een programmeertaal een Fixed-Point variabele kent. Enkele talen kennen een “Currency” of “Money” datatype dat eigenlijk een integer is, maar waarbij op de een of andere manier bepaald is hoeveel decimalen van die integer achter de komma staan. Bijna altijd 4 decimalen. Ook dit datatype is bij moderne processoren in de FPU ingebouwd. Het mooie van Fixed-point nummers is dat de opslag zonder afrondingsfouten gebeurt. Alleen bij berekeningen kunnen er afrondingsfouten optreden. Deze fouten treden vooral op bij vermenigvuldigen, delen, worteltrekken. Bij gehele getallen krijg je geen afrondingsfouten als het om vermenigvuldigen gaat. (Alleen weer wel een mogelijke overflow fout.)

    Volgens mij is er ooit een library geschreven voor het rekenen met nummers in de vorm van stringvelden. De precisie van dergelijke nummers is dan enorm, want de lengte van een string is vrij onbeperkt. Alleen, het rekenen met dergelijke “getallen” is niet erg comfortabel. (Traag!) Het is leuk als je zo PI tot op 10.000 cijfers achter de komma wilt uitrekenen maar in het algemeen minder bruikbaar.

    Ook interessant is overigens dat je in de FPU kunt aangeven hoe er precies afgerond dient te worden. Afronden gebeurt daarbij meestal naar een geheel getal dat het dichtste in de buurt zit, waarbij de voorkeur uitgaat naar de even getallen indien je precies tussen twee nummers in zit. Maar je kunt de FPU opdracht geven om op andere manieren af te ronden en ook vanuit de code is dit soms te bepalen. Dit kan soms hele aparte verschillen opleveren. 🙂

    Oh, ja… CPU’s en FPU’s bevatten ook bugs! De eerste Intel Pentium processoren hadden een mooie bug tijdens berekeningen. Echter, die bug trad zo zelden op dat het redelijk lang duurde voordat deze werd opgemerkt. Sindsdien zijn er wel meer bugs gevonden in de diverse hardware chips en diverse bugs worden tegenwoordig door het besturings-systeem afgevangen. Je praat dan ook eigenlijk over een enorme low-level bug die je alleen repareert door de hardware (processor) te vervangen…

  23. > @hAl: Omdat iedere knuppel die programmeert, weet > dat floatingpointrepresentaties fundamenteel > ongeschikt zijn voor geldbedragen?

    Dat dacht ik ook, en ik heb wel eens iets heel slims gemaakt om wel netjes te rekenen (weet niet meer precies, lang geleden), maar in de praktijk is het niet waar. Als je de 80 bits floating registers gebruikt van de 80387 (pardon? dinosaurus? ja, maar compatibel met 486 en alle pentiums) en dan netjes afrondt op centen, en vervolgens DIE opslaat, dan gaat het in de praktijk gewoon wel goed. Wel oppassen met helicopters in lires, maar dan nog.

  24. > Het Single datatype is 32-bits lang, waarvan 8 bits voor de exponent.

    Ja, maar intern werkt rekenen met 32 bits ook gewoon met 80 bits, zodat rekenen met 80 bits nog sneller is ook. Of was, toen ik het lang geleden testte; tegenwoordig is het allemaal zo extreem snel dat dat rekenen toch nooit de bottleneck is, ook niet bij bulkhoeveelheden data. Bij het rekenen gewoon altijd long double gebruiken in C(++), en voor variabele en databases opslaan in exacte centen, d.w.z. strings of BCD. De Cobol-manier dus, maar dat kan in C ook best.

  25. Hmm, nou maak ik me zorgen. Ik weet niet of mijn aanpak te ver gaat.

    Ik heb namelijk in mijn offertes en facturen staan:

    Garantie en aansprakelijkheid: Er zijn geen afspraken gemaakt over garantie. Opdrachtnemer aanvaardt geen enkele aansprakelijkheid.

    Zo laat ik impliciet ruimte vrij voor klanten om (uiteraard tegen meerprijs) hier verandering in te laten brengen. Het zijn overigens geen kleine letters, maar staan net zo groot op de factuur/offerte vermeld, als al het andere.

    Wat is je mening hierover, Arnoud?

  26. Was dit een zeer subtiele moeilijke fout of juist een triviale bug die de vraagsteller gewoon had moeten ontdekken bij het testen?

    Of had de QA-engineer die de opdrachtgever had moeten inhuren de bug moeten ontdekken?

    Met andere woorden, als je een freelancer inhuurt voor een complexe opdracht (want vrijwel alle software projecten zijn complex), moet je ermee rekening houden dat er fouten worden gemaakt.

  27. @nl-x: Ik zou erbij zetten “behoudens bij opzet of grove nalatigheid van Opdrachtnemer”. Die uitzondering geldt namelijk altijd. Een beperking van aansprakelijkheid die óók deze situaties probeert uit te sluiten, kan door de rechter als geheel ongeldig worden verklaard. Niet altijd, sommige rechters redeneren “iedereen weet dat die uitzonderingen gelden dus dat moet je er impliciet bij lezen” maar anderen zijn strikt en zeggen “de clausule sluit het niet uit, dus de clausule als geheel is bij deze ongeldig”. Met die bijzin is dat argument niet meer mogelijk.

  28. Ik denk dat “je had het bij het testen moeten ontdekken” vreselijk moeilijk te controleren is. Wat is een realistische verwachting? Misschien is het mogelijk om 100 vergelijkbare stukjes software te vinden en te kijken of die het goed doen, maar dat lijkt me lastig.

  29. De manier waarop de fout werd ontdekt geeft een indicatie van de moeilijkheidsgraad van de fout. Als het iets is wat gewoon maanden over het hoofd is gezien dan is dat een hele andere situatie dan wanneer de fout pas na maanden data verzamelen pas zichtbaar wordt. Ik denk hierbij aan de FPU-bug die Intel in de eerste Pentium-processors had geintroduceerd maar die vrij lang onopgemerkt werd omdat de foute resultaten maar weinig afweken van de juiste waardes. Een domme fout van Intel maar lastig op te sporen omdat de fout maar af en toe optrad. Aan de andere kant, als de software dagelijks een lijst getallen met daaronder een totaal genereert en regelmatig wijkt het totaal een cent af van de som van de bedragen dan had je iedere dag tijdens het testen al even de totalen kunnen narekenen en dus vroegtijdig de fout ontdekken.

    Een eenvoudig te vinden fout had tijdens het testen ontdekt moeten worden. De FPU fout is veel lastiger te ontdekken en dus meer de verantwoording van de freelancer.

    De manier waarop ze concludeerden dat de fout bij de freelancer vind ik ook belangrijk want hebben ze de code nageplozen en de fout in de code ontdekt? Of is het meer een aanname omdat hun eigen code foutloos is?

    Ik denk dat ook kan meetellen hoeveel fouten er in hun eigen code zit. Als de site van het bedrijf compleet foutloos is (ofwel, als varkens kunnen vliegen) dan kun je ook van anderen wel de ultieme perfectie verwachten. Maar als de site zelf ook regelmatig foutjes bevat, tja… Pot, ketel, zwart? Ofwel, hoe is de eigen kwaliteits-controle van dit bedrijf en hebben ze die ook toegepast op het werk van de freelancer?

  30. Ik snap wat je bedoelt. Maar sommige fouten zijn lastig op te sporen omdat de uitvoer er reëel kan uitzien. Een routine die mij het gemiddelde van een grote berg getallen meldt, kan er naast zitten maar als de uitvoer binnen mijn verwachting zit, ga ik niet nader onderzoeken.

    Verder zou je hier toch het “we hebben niets veranderd” principe kunnen gebruiken. Als de data corrupt blijkt vanaf de dag dat de extensie live ging, en na verwijderen daarvan de data weer klopt, dan is dat toch wel een sterke aanwijzing.

  31. Voor mijn werkgever werk ik aan software voor de financiele markt en ook daar moet je voorzichtig zijn want een klein foutje kan veel onkosten opleveren. Dat betekent dan ook dat we een “Quality Control” team hebben die alle code uitgebreid test. En als daar iets tussen zit dat een gemiddelde berekent over een berg getallen dan doen ze ook dat! (En hier komt een spreadsheet goed van pas!) Voor het testen hebben we speciale testcases die handmatig al zijn nagerekend en de software die ik vervolgens mag bouwen moet exact die waarde opleveren die ook uit de handmatige berekeningen komt. Pas dan is de code goedgekeurd. Als je software gaat testen dan is dat wel veel werk, maar je moet het nu eenmaal doen om zekerheid te krijgen over de werking ervan. Als je dat achterwege laat dan ben je tijdens het testen al enigszins nalatig. En als het dan ook nog eens maandenlang onopgemerkt fout blijft gaan wordt het steeds nalatiger.

    Overigens, als ik code oplever garandeer ik Quality Control ervan dat er een fout in zit. Wat de fout is en wanneer het fout kan gaan kan ik niet aangeven, maar er zit een fout in. Aan QC de taak om deze fout te vinden en te bepalen in hoeverre deze storend is voor het gebruik ervan. Misschien zijn twee tekstboxen niet helemaal recht onder elkaar. Of misschien zit er ergens een rekenfout. Ik weet het niet maar als QC deze niet vindt dan hebben ze of hun werk niet goed gedaan of de fout is niet storend in gebruik. In ieder geval, ik maak altijd duidelijk dat wat ik oplever nooit perfect is. Grappig genoeg is dit enorm frustrerend voor QC omdat ik desondanks maar erg weinig fouten blijk te maken. 🙂

    Het “we hebben niets veranderd” gaat hier denk ik niet op. Immers, de data zelf is veranderd. Belangrijk is dus dat de oorzaak van de fout eerst wordt opgespoord. Je zult dus met een test moeten aantonen dat de extentie de fout veroorzaakt. Daarvoor zul je deze moeten isoleren van de site en via b.v. unit testing delen aanroepen met data die via de site dus fout ging. Als de unit tests aangeven dat de extentie daadwerkelijk fout berekent, pech voor de freelancer. Maar als alles goed gaat in de extentie dan zit de oorzaak in de resr van de site of in de combinatie van site plus extentie.

    En nu wordt de gebruikte ontwikkel-omgeving ook belangrijk. Is het een extentie en website die in PHP is geschreven? Of in ASP.NET? Of Python? Of een combinatie van technieken? Heeft de gebruikte ontwikkel de mogelijkheid om unit tests uit te voeren en zijn deze ook daadwerkelijk uitgevoerd? En door wie? Wat waren de resultaten?

  32. Algemene voorwaarden? Die heb ik wel, maar die kan ik meestal niet gebruiken. Ik heb ze gebruikt toen ik gevraagd werd een cursus te geven van drie avonden. Maar bureaus die freelancers regelen voor grote concerns hebben een standaardcontract dat ze niet willen wijzigen. Veel te lastig om bij elke freelancer andere voorwaarden te hebben. En een mooie full-time klus wil je als freelancer niet laten schieten, dus doe je niet moeilijk.

  33. Maar bureaus die freelancers regelen voor grote concerns hebben een standaardcontract dat ze niet willen wijzigen.
    Het probleem hiet is eigenlijk niet dat grote concerns dergelijke standaard-voorwaarden hanteren maar dat freelancers daarmee akkoord gaan! Aan de andere kant, lang niet alle freelancers gaan accoord met dergelijke standaardvoorwaarden, ongeacht hoe mooi de opdracht is. Ze hanteren hun eigen voorwaarden omdat hun eigen voorwaarden voor de juiste bescherming zorgen in geval van schadeclaims van hun klanten. Het grootste gevaar dat je loopt als je als freelancer akkoord gaat met zo’n standaard-contract van een groot concern is dat een risico want heb je wel de tijd om rustig dat contract door te lezen? Voor je het weet teken je iets waarna je opeens verantwoordelijk bent voor alle ellende binnen een dergelijk bedrijf en verlies je erop… Ik zou dus nooit zomaar accoord gaan met zo’n standaard-contract.

  34. Het opstellen van je eigen algemene voorwaarden hoeft ook niet iets definitiefs te zijn. Je kunt er meerdere maken. Je kunt er flexibel in zijn. En inderdaad kan heel veel kopzorgen voorkomen. Claims waar je van te voren zeker niet “accoord” mee zou willen gaan.

    Ps. Voor al je ict-vacatures, kijk eens op jouw ictvacature.

    -edit Arnoud: doe eens niet, zo’n Ps.-

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.