Tag: Programmeren

About Programmeren

Subscribe Feeds

Moet je als programmeur verstand van rechten hebben? #legaltechtuesday

Geplaatst op in Innovatie, 8 reacties

Vorige week blogde ik Moet je als jurist leren programmeren? en dat gaf vele leuke reacties, waaronder via Linkedin de vraag:

Vice versa, zou je ook kunnen stellen dat software ontwikkelaars enige basiskennis van de juridische praktijk moeten hebben ?
Grappig genoeg hoor je die een stuk minder vaak. Maar de observatie is een hele scherpe, ik denk zeker wel en zelfs méér kennis dan omgekeerd juristen van het programmeerveld.

Dit omdat software steeds vaker gewoon juridische dingen oplost, denk aan het bestellen van producten, het maken van afspraken, het vastleggen van contracten etc. Vaak zie je dat het daar juridisch nét rammelt, of naar Amerikaans voorbeeld gebouwd wordt. En dat is niet alleen irritant voor juristen die het toevallig zien (ik heb tegenwoordig speciale sloffen waar mijn tenen in kunnen krommen) maar ook gewoon kostbaar voor je klant.

Simpel voorbeeld: vrijwel iedere websitebouwer die een bestelformulier of aankoopscherm bouwt, zet daar een vinkje bij waarmee de algemene voorwaarden kunnen worden aanvaardt. Doet iedereen, zal wel moeten en de documentatie legt het ook niet uit. Maar het is fout: zo’n vinkje is helemaal niet nodig om mensen aan je voorwaarden te binden.

Over de AVG en hoe dat uitpakt, daar kan ik een boek over schrijven, zo veel fouten worden daarin gemaakt. Toestemming vragen waar dat niet hoeft, privacyverklaringen laten accorderen, plugins van derden neerzetten en denken dat dat zomaar mag, zo kan ik nog wel even doorgaan. Handig om te weten.

Maar het kan ook subtieler. Denk aan een site waar mensen dingen mogen posten. Natuurlijk kun je dan claims krijgen wegens bijvoorbeeld auteursrechtinbreuk, en daar moet je dan wat mee. (Ook trouwens met privacyclaims en andere dingen.) Maar dat betekent niet dat je zomaar alles weghaalt. Je houdt rekening met de rechten van je gebruikers, zoals wanneer ze een parodie posten of een citaat gebruiken en meer niet. Weten dat dit kan, lijkt me wel het minste dat je van een developer kunt vragen.

Natuurlijk hoef je als ontwikkelaar zeker niet een mr-titel te hebben. Ik denk dat het niet goed mogelijk is om én het IT-veld én het juridische veld allebei goed bij te houden, op het niveau dat beiden eisen als je het echt goed wil doen. Maar de basiskennis, ja die moet er zijn. Programmeren doe je niet in een vacuüm waar anderen juridische lucht in pompen.

Arnoud

Moet je als jurist leren programmeren? #legaltechtuesday

Geplaatst op in Innovatie, 11 reacties

Code as law. Met dat mantra is de toon gezet: steeds vaker speelt software en online dienstverlening een steeds belangrijker rol in de juridische praktijk. Software maakt beslissingen, software selecteert of wijst af. Of functioneert anderszins op onnavolgbare wijze. Ga er maar aan staan met een juridische analyse of claim: de mindset die hoort bij software en ICT ontwerpen, is een hele andere dan die hoort bij een aansprakelijkheidsstelling formuleren of een dagvaarding opstellen. Vandaar dat je steeds vaker leest dat advocaten en juristen moeten leren programmeren. Maar is dat wel echt zo nuttig?

Vooropgesteld: programmeren is gewoon leuk. Het is puzzelen, in logische volgorde instructies uitwerken en rekening houden met randgevallen waar niemand aan gedacht heeft. Wie wel eens een Lego Mindstorms robot heeft ingesteld, begrijpt meteen wat ik bedoel. (Zoekt u nog een Sint- of Kerstcadeau voor uw kind of neefje/nichtje?)

En het mooie is, programmeren lijkt ergens wel op contracteren of juridisch puzzelen. Want ook daar moeten logische stappen genomen worden, hindernissen geëlimineerd, randzaken ingeperkt en risico’s afgedekt. Dat het bij programmeren gaat om het risico dat een temperatuursensor 4000 graden aangeeft en bij contracteren dat een opdrachtnemer ziek wordt, dat is een inhoudelijk detail.

Toch zijn er ook wel verschillen. Juristen leren denken binnen het redelijke en billijke (art. 6:2 en 6:248 BW, bijvoorbeeld). Als een uitkomst al te bizar is, dan weet iedere jurist dat deze kan worden bijgesteld. Een boeteclausule die op zes ton uitkomt voor een overtreding van een half uur, dat wordt gegarandeerd gematigd. Bij de menselijke rechter inderdaad, want het contract komt op zes ton. En als je dit in software doet, dan komt daar ook gewoon spijkerhard zes ton uit. Computers zijn niet redelijk, zij rekenen alleen maar.

Deze verschillen maken dat het best interessant kan lijken om als jurist een cursus programmeren te doen. Als jurist en programmeur kan ik u vertellen: dat is ook zeker de moeite waard, alleen moet u wel vooraf bedenken wat u zou willen kunnen. Je hebt namelijk programmeren en programmeren: gaat het om het begrijpen van de basics, wilt u doorgronden hoe algoritmes (stappenplannen) opgebouwd worden en welke valkuilen daarbij komen kijken, wilt u een juridische dienst of app opzetten of iets anders? Dit zijn namelijk zeer verschillende cursussen.

Voor mij staat voorop dat de skill van het programmeren zelf niet zo heel belangrijk is. Programmeren is namelijk geen handeling op zich, zoals bijvoorbeeld schilderen of fotograferen. Het is een activiteit binnen een groter kader, namelijk applicatie- of dienstontwikkeling. Onderhoud en meegaan met nieuwe ontwikkelingen zijn essentieel. Tenzij je het dus houdt bij Mindstorms robots. Maar programmeren is niet iets dat je leert en daarna altijd onder je riem hebt; je moet het altijd bijhouden en opnieuw toepassen.

Wat je wél kunt leren van een korte cursus, zijn algemene skills en vaardigheden uit dit digitale domein. Een specifieke skill is bijvoorbeeld hoe je een groot algemeen probleem opdeelt in kleine blokjes, en daarna ieder deelprobleem oplost op een manier dat het aansluit bij het vorige en het volgende deelprobleem. Ook helpt programmeren u data beter te begrijpen – een waardevolle skill als u met zogenaamde artificial intelligence aan de slag gaat. Want u kunt wel om een verkeerde komma heen lezen in een dossier, uw robot paralegal slaat onverbiddelijk op hol van zo’n onnozele fout. Ook leert u door programmeren meer projectmatig denken, want software ontwerpen is te groot om even snel op een middag te doen.

Een alternatief dat steeds meer aan populariteit wint, is het zogeheten no-code programmeren. Hierbij hoeft de programmeur geen details van programmeertalen te kennen, maar heeft zhij een visuele interface waarmee dingen aan elkaar te knopen zijn. De computer heeft de benodigde programmeercode op de achtergrond paraat, maar valt u daar niet mee lastig.

Een heel simpel voorbeeld? Probeert u dan IFTTT (if this then dat) eens, een dienst waarmee u van alles aan elkaar kunt knopen. Van agenda’s tot e-mail tot Onenote of zelfs uw wasmachine, als die dat ondersteunt. Dat vereist enig logisch nadenken over wat u precies wilt, en vooral: omzetten naar specifieke, concrete instructies. Zo zou ik op warme dagen graag willen dat mijn zonwering op tijd dicht gaat. Vertalen naar instructies: Als de temperatuur om 13uur boven de 26 graden is, doe dan de zonwering omlaag. Tenzij in mijn agenda “afwezig” staat. Tenzij het regent. Tenzij … kijk, daar voelt u al een programmeur in uzelf omhoog komen.

Overweegt u programmeerervaring op te doen? Vraag u dan eerst af wat u eigenlijk zou willen bereiken. Koop een Mindstorms robot, puzzel met een no-code dienst zoals IFTTT en ga eens puzzelen wat uw eigen robot paralegal zou moeten doen. En beslis daarna.

Arnoud

Ben ik aansprakelijk voor de fouten in mijn software?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 41 reacties

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

Mag ik weigeren aan prutswerk te programmeren?

Geplaatst op in Innovatie, 36 reacties

ruine-rommel-kasteel-ingestort-veiligheid.jpgEen lezer vroeg me:

Ik werk sinds kort bij een bedrijf dat webapplicaties bouwt in PHP. Helaas moet ik constateren dat meer dan de helft van mijn collega’s echt te weinig verstand van zaken heeft. Men gebruikt procedureel PHP alsof het 1997 is (in plaats van het veel veiligere object-georiënteerde), men heeft geen enkel benul van veiligheidsrisico’s en documentatie ho maar. En nee, we onderhouden geen antieke applicatie van een belangrijke klant maar dit is code die vorig jaar geschreven is. Kan ik weigeren nog langer op deze manier door te gaan? Ik vind de risico’s voor onze klanten onaanvaardbaar.

Het kan zeker frustrerend zijn om ergens te werken waar men zwaar onder je eigen kwaliteitsstandaards werkt. Alleen, dat is geen reden om te stoppen met werken en te eisen dat het bedrijf haar standaards aanpast. Als er wettelijke regels worden overtreden, ja dan kun je denk ik wel terecht het werk neerleggen.

Dat is hier echter niet zo. Een bedrijf is vrij om procedureel PHP te gebruiken, en als ze onveilige applicaties oplevert dan krijgt ze daar wel claims over van haar klanten (hoop ik). Er zijn geen wetten of regels die je overtreedt door procedureel code te schrijven of niet-onderhoudbare code te maken.

Afgezien van een paar stevige gesprekken voeren met collega’s of de veiligheids-evangelist uithangen, zie ik geen mogelijkheden om te weigeren op deze manier door te gaan. Dit zal worden uitgelegd als werkweigering, en dat is grond voor ontslag. Het feit dat je het oneens bent met het beleid, is niet genoeg om het werk te mogen weigeren. De werkgever beslist hoe het werk verricht wordt, en zolang men redelijke beslissingen neemt, heb je die uit te voeren. Ook al vind jij ze onveilig, ouderwets of gewoon dom.

Arnoud