Mag ik weigeren aan prutswerk te programmeren?

| AE 2284 | 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

Deel dit artikel

  1. Laten we vooropstellen dat civielrechtelijk bij schade (die overigens zeer aanzienlijk kan zijn) door slechte kwaliteit van de software en/of ontwikkelproces in principe de werkgever verantwoordelijke is tenzij er sprake is van bewuste roekeloosheid een de zijde van de werknemer.

    In ken nog geen Nederlandse zaken maar het is wel aardig om dit artikel te lezen: http://tinyurl.com/2cnwaly

    Daarnaast kan er sprake zijn strafrechtelijke gevolgen, immers bij dood door schuld kan een medewerker mededader zijn…

    Ik zou voor de beoordeling terug willen grijpen op de formulering van het RBC-Brinkers arrest: http://internetrechtspraak.wikispaces.com/file/detail/rbc-brinkers.pdf

  2. Een werkgever zal zeker open staan voor opbouwende kritiek mbt het geleverde werk. probeer het ook te benaderen vanuit het voordeel dat het de werkgever oplevert: goede code kost minder onderhoud en geeft minder risico op claims. Daarnaast is object ge?rienteerde programmatuur makkelijker herbruikbaar.

    Veranderingen brengen in een organisatie kost tijd en geduld, maar als je gaat voor de gewenste kwaliteit zullen je collega’s ?n je werkgever dat zeker op prijs stellen!

  3. Lekker weggaan. Je hebt duidelijk niet de support van management. Lelijk gaan doen tegen collega’s of management levert scheve gezichten en verstoorde relaties. Er zijn genoeg (maar niet overdreven veel) bedrijven waar kwaliteit hoog in het vaandel staat.

    Als je niet weg wilt, denk er dan eens aan om presentaties te geven aan het einde van een werkoverleg, of maandelijkse technical meetings te organiseren. Dat doen wij ook, en dat is leerzaam en leuk. Je moet alleen niet de illusie hebben dat je een bedrijf veranderd zonder management support.

  4. Aan de mensen hier die zeggen “ga bij een ander werken”, volgens mij heeft de plaatser een moreel conflict en weglopen lost dat niet op. Het is hetzelfde als dat je het niet eens bent met Nike die schoenen door kinderhandjes laat maken, dat je zegt “nou, dan koop jij geen Nikes”. Dat is niet de oplossing. Wat dit bedrijf doet is fout en schadelijk voor zichzelf, haar klanten en het imago van de hele branche.

    Als je het probleem echt wil verbeteren, moet je heel veel geduld hebben en vooral rustig blijven. Het gaat niet van de ??n op andere dag veranderen, en als je je boos gaat maken, neemt niemand je straks nog serieus. “Die maakt zich overal druk om” zeggen ze dan, en dan krijg je niks meer gedaan. E?n probleem tegelijk dus (niet alles ineens willen veranderen), en begin met die dingen waarvan collega’s zich het meeste kunnen voorstellen dat het oplevert. Dan gaan ze zich vanzelf hopelijk meer druk maken over de troep die ze verkopen. Begin niet met OO of iets dergelijks, dat is pas voor later. Laat ze eerst maar nadenken over kwaliteit, en laat de managers inzien dat kwaliteit geld is.

  5. De eerste vraag die bij me op komt is: Hoe komt het dat je daar werkt? Blijkbaar is de kwaliteit niet zoals jij het wilt en is er geen mogelijkheid om dit te verbeteren. Had je dit van tevoren niet gezien/besproken?

    Aan de andere kant, heb je de mogelijkheid om zelf wel OO te gaan werken? Laat ze de voordelen zien. (veiligheid hoeft niet beter te zijn dan bij procedureel) Een praatje is leuk, maar daadwerkelijke resultaten zeggen veel meer. Je moet de voorbeelden duidelijk maken, de rest ziet waarschijnlijk alleen maar kosten.

    Dit is een uitdaging voor je of een ramp. Als je het als uitdaging ziet kun je een leuke tijd tegemoet, anders gaat het je waarschijnlijk slopen.

  6. Ai! Als software ontwikkelaar voel ik mij op mijn tenen getrapt door deze discussie! 🙂 Slechte programmeurs? Of is er gewoon sprake van een dissidente programmeur die zich niet aan de stijl wil houden die binnen een bedrijf gebruikt wordt. Als je vindt dat procedurele PHP te onveilig is, leg dit dan voor bij je collega’s en bespreek de voor- en nadelen. Denk niet meteen dat de rest een stelletje dombo’s zijn simpelweg omdat ze het oneens zijn met jouw mening! Al programmeer ik dan zelf in Delphi/WIN32 en C#, ook ik merk wel grote verschillen in de kwaliteit van de code die mijn collega’s opleveren. Soms heb ik het idee dat ze dachten “Waarom makkelijk doen als het ook moeilijk kan?” en ik heb wel eens discussies gestart over de “Job Security Index” die stijgt naarmate je code schrijft die anderen niet kunnen begrijpen. Collega’s die weer eens complexe, onbegrijpelijke code schrijven vraag ik dan regelmatig of ze hun JSI hebben willen verhogen. Heb ook wel eens aangegeven dat een ander team meestal geen tijd besteedt aan het documenteren van hun code voor of desnoods na het schrijven van de code. En dat heb ik tevens aangekaart bij het management, met een waarschuwing dat hierdoor vrij slechte code kan ontstaan. En omdat er inderdaad bij dat team wel eens het een en ander mis gaat, heb ik een deel van het management wel weten te overtuigen van het nut van documenteren. In ieder geval dusdanig overtuigd dat mijn eigen team zonder problemen documentatie kan maken. (En tot verbazing van management zijn wij niet langer bezig met het schrijven van code en documentatie dan andere teams met alleen code!) Het zal alleen lang duren voordat het gehele management is overtuigd.

    Maar even terug naar het onderwerp: procedurele PHP is onveiliger dan OO-PHP? Zeker weten? Kun je dat aantonen? Besef je wel dat veiligheid niet wordt geregeld door de programmeertaal maar door de personen die deze omgeving gebruiken? Het is best een stevige bewering die je maakt! En je kan best gelijk hebben, maar kun je het aantonen? Probeer mij maar te overtuigen dat je gelijk hebt! Heb wel enige PHP kennis maar zou totaal niet weten waarom OO het geheel nou opeens veiliger zou maken.

    De benaming “prutswerk” is onnodig grievend. Als jij zo over de code denkt moet je bij jezelf afvragen of je wel bij dit bedrijf wilt werken. Het is duidelijk dat jij je niet thuis voelt bij hun manier van programmeren.

    Betreffende werkweigering… Tja, dat heb ik twee keer in mijn carriere gedaan, in beide gevallen om vergelijkbare kwesties. In de eerste situatie moesten we zoeken naar een manier om een applicatie te beveiligen. Ik bood een mooie, werkende oplossing aan maar een “prutser” die vriendjes was met de manager vond het niets en stelde een waardeloze alternatief voor. En die moest ik dan bouwen! Mooi niet dus, want ik kan niet de verantwoording nemen voor wat ik van tevoren al als onveilig heb opgemerkt. En ik had ook genoeg argumenten om aan te geven waardoor het onveilig was! Mijn ervaring met beveiliging sprak daarbij ook nog eens in mijn voordeel waardoor management het niet aan durfde om die andere ontwikkelaar zijn code te laten uitwerken, simpelweg omdat ze er grote twijfels over hadden gekregen. (En die prutser werd twee maanden later ontslagen omdat hij teveel fouten bleef maken.) In de tweede situatie ging het om de beveiliging van een web service die door een ander team was opgezet. De beveiliging ervan was zo lek als een mandje en de manier van aanroepen was dusdanig complex dat ik -samen met collega’s- het management voor een blok stelde: de beveiliging moest beter en de web service moest beter opgezet worden, anders konden wij niet verantwoordelijk gehouden worden voor de beveiligings-problemen die absoluut zouden ontstaan wanneer wij het geheel ingebouwd hadden. We wilden het wel inbouwen, maar de verantwoording voor als de aanroep mis ging zou dan niet bij ons team liggen.

    Uiteindelijk is die web service dus ook fors verbeterd. En eigenlijk hebben we niet werk geweigerd, we hebben de verantwoording voor ons werk geweigerd. Een klein maar erg belangrijk verschil!

    En ja, ik durf de discussies over veilige code best aan te gaan. En als ik het mis heb, ben ik niet te beroerd om dit toe te geven. Maar dan moet je wel met goede argumenten komen en niet zeggen dat “procedurele PHP gelijk staat aan prutswerk”. Dat is namelijk geen argument!

  7. Ik ben het hier wel met Wim eens. Een oude manier van programmeren gelijk onder de maat te noemen is natuurlijk geen argument. En geen benul van veiligheidsrisico’s hebben kan natuurlijk ook nog worden gelezen als ‘houdt niet dagelijks de security nieuwssites bij’ wat ook niet nodig is voor afdoende veilige code. Dit kan altijd later door de security expert afgevangen worden. Daarbij zal het bedrijf toch alleen maar klachten van gehackte en kapotte programma’s krijgen van haar klanten?

    Mocht de vrager wel daadwerkelijk gelijk hebben en op zijn werkvloer de enige zijn die geen prutser is, ga dan inderdaad solliciteren bij andere bedrijven. Er is vast altijd leuker werk te vinden en prutsers blijven niet lang in de markt.

  8. Mijn ervaring is dat 100% van de programmeurs die alles zo netjes en veilig mogelijk willen doen, zich 0% aantrekken van wat de klant wil of van wat goed is voor de klant. De claim die aan de basis van de lezersvraag staat, te weten “ik vind de risico???s voor onze klanten onaanvaardbaar”, lijkt me dan ook bijzonder twijfelachtig.

  9. Branko, ik voel me door jouw opmerking op mijn tenen getrapt. Bij een iedere toepassing hoort een zekere mate van beveiliging die afhankelijk is van het beoogde gebruik van het programma door de klant. Veiligheid en auditing eisen horen in overleg met de gebruikers opgesteld te worden. Ik sta achter de woorden van Wim ten Brink en geef hem de suggestie “peer reviews” in te voeren op zijn afdeling. Vertel de programmeurs dat een collega de code nog eens gaat nalopen op rariteiten… verlaagt de JSI alleen al door de dreiging (en de review vangt ook weer een handvol luizen.) O ja, de originele poster: zou het helpen als een aantal van je collega’s een cursus “modern PHP” gaan volgen?

  10. @MathFox, binnen mijn eigen team vinden er regelmatig peer reviews plaats, mede ook om het gehele team goed op de hoogte te houden van de nieuwe ontwikkelingen. We hebben wel regelmatig te maken met de noodzaak om te presteren onder enorme tijdsdruk maar in het algemeen redden wij het prima. Ik heb verder gemerkt dat ik toch wel een der meest ervaren programmeurs binnen mijn team ben. (De meeste jaren ervaring.) Daardoor ben ik het gehele team soms vooruit aan het trekken als het gaat om nieuwe technieken leren te begrijpen. Door gewoon nieuwe technieken te gebruiken in mijn eigen werk, waarbij ik tevens voor goede documentatie zorg, heb ik gemerkt dat de rest van het team ook opeens beter gaat programmeren! Dit is natuurlijk ook een mogelijkheid: in de PHP code zou je je eigen werk op de OO methode kunnen schrijven terwijl de rest nog procedureel bezig blijft. Wel zorgen dat je je eigen code goed documenteert en uitlegt hoe ze het kunnen gebruiken. Door je kennis te delen met het team is de kans aanwezig dat ze jouw voorbeeld gaan volgen, mits het ook duidelijk is dat jouw systeem beter werkt.

    Natuurlijk is het delen van kennis in tegenspraak met de JSI. Immers, als jij de enige bent met bepaalde, nuttige kennis ben je erg waardevol. Zodra je collega’s dit ook weten gaat hun JSI omhoog en de jouwe omlaag. Daarom zijn sommige programmeurs juist bang voor documenteren, simpelweg omdat het hun JSI in gevaar brengt.

    Betreffende de beveiliging: dit is natuurlijk per applicatie verschillend. Sommige applicaties moeten nu eenmaal beter beveiligd worden dan andere programma’s. De beveiliging moet overeen komen met het doel van de applicatie. Een applicatie zoals dit Blog hoeft niet al te veilig te zijn. Er staat geen gevoelige informatie op. En mocht de data van deze site verloren gaan dan heeft Arnoud vast nog ergens een recente backup liggen. Toch, Arnoud? 😉

  11. Gewoon voor jezelf beginnen. Als je voor een baas blijft werken moet je je kunnen aanpassen aan je omgeving.

    Je kunt wel proberen je omgeving te veranderen maar dat is een questie van de zeeeer lange adem en lukt alleen (een beetje) als je echt goed bent (niet alleen in programmeren). En ook dan moet je je dus “voorlopig” kunnen schikken.

    Dat gezegd hebbende is de kwaliteit inderdaad vaak droef. Klopt.

  12. Ach, zo lang het niet zo erg is als “Mijn OV-fiets” zal het wel meevallen ;).

    Wat een mooie vraag voor dit blog is: Stel dat deze lezer meewerkt aan software waarvan hij weet dat (bijv.) allerlei persoonsgegevens gemakkelijk toegankelijk zijn. Kan hem dan niet iets aangerekend worden?

    Misschien dat een CYA actie wel handig is, zoals formele brief met bezwaren.

  13. Arthur’s reactie uit #1 (helaas in de spamfilter blijven steken) zegt het correct: de werknemer is in principe nooit aansprakelijk voor fouten in code die het bedrijf uitlevert. Pas bij kwade opzet of bewuste roekeloosheid kan dat anders liggen. Slordigheid of incompetentie zijn het risico van de werkgever, niet de werknemer.

    Dit geldt ook bij mogelijke wetsovertredingen: de werknemer zou dat moeten signaleren als hij het merkt, maar ik denk dat ook dit uiteindelijk de afweging van de werkgever is en daarmee zijn juridische aansprakelijkheid. Het kan niet zo zijn dat een werkgever iets doordrukt en de werknemer die het bouwt, daarvoor opdraait.

  14. @Arnoud, het lijkt mij dat je als werknemer wel duidelijk moet maken aan je werkgever dat de door de werkgever gewenste code niet conform de veiligheids-eisen is en dat je daar -als werknemer- dus ook niet de verantwoording voor nam. Bij mijn huidige werkgever heb ik dus ooit om die reden werk geweigerd omdat de gewenste aanpassing een enorm beveiligings-lek zou introduceren, wat ik onacceptabel vond. Ik wou het wel inbouwen, maar op voorwaarde dat ik van management -op papier- een verklaring kreeg dat deze code op hun verantwoording werd ingebouwd en dus tegen mijn advies in. (De email discussie hierover was overigens al voldoende, maar ik moest ze toch serieus op andere gedachten brengen.) Uiteindelijk hebben ze dus wel geluisterd.

  15. Bedankt voor Arthur’s reactie! Ik was al verbaast dat ik die gemist had voor ik zelf postte. Interessant.

    Toch zou het nuttig kunnen zijn h.e.e.a. op te schrijven zodat het (later) duidelijk is dat Lezer geen kwade opzet had en niet roekeloos bezig was.

    Anders krijgt hij misschien het verwijt dat hij wist dat het slecht geprogrammeerd was, maar expres niks heeft gezegd.

    Het is dan wel goed om dat op een positieve manier te formuleren en niet om later een I-told-you-so dansje te kunnen doen.

  16. @all

    Wat een boeiende discussie!

    Ik ben een beetje twee-talig omdat ik ?n (ICT) jurist ben en ook nog steeds onderwijs geef op HBO nivo op gebied van software engineering (ontwerpen, bouwen en testen)

    Mijn eerste reactie was vooral een juridische, daarnaast vind zie ik helaas genoeg organisaties die op een JBF of met KMA methode software ontwikkelen. Er is helaas geen silver bullet maar ik denk dat methoden en technieken en review en inspectie bij het maken software artifacten tot betere kwaliteit en lagere kosten zal leiden. Niet alleen OO technieken, daar is ook de nodige wetenschappelijke kritiek op…

    Als laatste punt blijft natuurlijk staan of een individu zich kan vinden in een bepaalde bedrijfscultuur en aanpak bij software ontwikkeling. Niet blijven hangen maar leuke baan zoeken waar je wel past!

  17. @Arnoud, 15: Ik denk dat het een “goed programmeur” betaamt om aan het management aan te geven wanneer een gekozen oplossing tot veiligheidsrisico’s leidt. Ik denk dat Wim’s vraag om een verklaring van het management “zwart op wit, op papier” extreem is, ik zou de email discussie naar een prive-adres geforward hebben (CYA). naar mijn mening zou dat voldoende moeten zijn om civielrechtelijke veroordeling te voorkomen.

    Strafrechtelijk liggen de zaken anders. Deelname aan een criminele organisatie ligt om de hoek (en hoe voorkom je dat je daarvoor veroordeeld wordt). Een voorbeeld: Je krijgt als programmeur de opdracht de kassa’s bij je bedrijf te herprogrammeren zodat ze 20% minder omzet aangeven (belastingfraude). Wat is de correcte handelswijze (als programmeur in loondienst) als je baas er op staat dat je die wijziging aanbrengt?

  18. @Arthur, voor mij is het al weer 20 jaar geleden dat ik in de klas zat en heb sindsdien mijn kennis vooral door zelfstudie en korte cursussen kunnen verbeteren. Mijn ervaring is dat er een groot kwaliteits-verschil zit met hoe men in de les leert programmeren en hoe het er uiteindelijk in de praktijk aan toe gaat. Het belangrijkste verschil zit hem vooral in de focus. Bij ICT-opleidingen en cursussen ligt de focus vooral op het opleveren van kwalitatief hoogwaardige code. In de praktijk ligt de focus meer op prestatie en is het belangrijker dat het product werkt en op tijd opgeleverd wordt en minder op de kwaliteit van de code. Het bedrijfsleven betaalt niet voor mooie code maar alleen voor het resultaat. En dat wekt vooral bij beginnende ICT’ers toch de nodige frustraties op, omdat er naar hun mening veel te slordig wordt gewerkt. Voor de vraagsteller zie ik het juist als een interessante uitdaging om aan te tonen dat zijn OO-voorkeur een beter alternatief is dan de huidige methode die men volgt. Zeker als je net binnen een bedrijf bent aangenomen is dat een mooie uitdaging om meteen de processen te verbeteren in overleg met je collega’s waarbij ook duidelijk moet zijn dat deze “nieuwe” methode een duidelijke verbetering moet zijn. En dat is best een uitdaging. Maar als je die uitdaging niet aan durft is het alternatief gewoon zoeken naar een andere werkgever waar je wel je ei kwijt kunt.

  19. @MathFox, wat ik deed was ook extreem, maar wel noodzakelijk. De manager van mijn team gaf mij wel gelijk, maar had nog iemand boven zich staan die ook overtuigd moest worden. Het feit dat ik hierom vroeg gaf al aan dat ik deze kwestie zeer serieus nam. (En ja, ik had de gehele mail-discussie ook netjes thuis als backup, inclusief print-outs.) Sowieso is mijn werkgever een vrij informeel bedrijf dus op deze manier was ik wel erg formeel bezig. Maar daar was het ook veel te belangrijk voor. (Want het ging om klant-informatie met rekeningnummers, NAW gegevens BSN nummers, informatie over salaris en werkgevers, leningen en nog veel meer.) Het ging er ook niet om dat ik “veilig” was, maar dat management op andere gedachten werden gebracht. En dat werkte en achteraf heb ik groot gelijk gekregen met mijn koppigheid!

    Maar management kon op dat moment mijn bloed wel drinken! 🙂

    Daar waar het gaat om strafbaarheid… Tja, stel dat ik meewerk aan een applicatie die fraude mogelijk maakt. Dan ben ik gewoon mede-schuldig aan die misdaad. Mijzelf kennende zal ik mijn werkgever duidelijk maken dat ik aan zoiets absoluut niet wil meewerken. Als men duidelijk criminele software wil ontwikkelen zou ik tevens bewijs hiervan verzamelen en aangifte doen, maar nog niet meteen bij mijn werkgever weggaan. (Tenzij in overleg met politie wordt besloten dat ik dat beter wel doe!)

  20. Branko, ik voel me door jouw opmerking op mijn tenen getrapt.

    Je voelt je door mijn ervaring op je tenen getrapt?

    Vertel de programmeurs dat een collega de code nog eens gaat nalopen op rariteiten…

    Waarbij “rariteiten” achterhaalde jaren-tachtig-methodologi?n als OOP zijn? Als de vragensteller de mogelijkheid had om zijn manier af te dwingen, had ‘ie dat toch al lang gedaan?

  21. @Arnoud, een beter voorbeeld van wat MathFox aangeeft: een bedrijf dat illegale software gebruikt om zelf producten mee te maken en te verkopen, waarbij in de code ook spyware wordt ingebouwd die de werknemer moet onderhouden. Er wordt veel malware geproduceerd en de productie hiervan gebeurt steeds professioneler. Tja, een collega van mij gaf eens een presentatie waarin een plaatje zat verwerkt met het woord “iStockPhoto” erdoorheen. Heb toen wel op komische wijze gevraagd wat hij bedoelde met die tekst in het plaatje. Hij gaf toen zelf wel aan dat hij nog een beter plaatje moest vinden maar daar nog niet aan toe was gekomen. Werd kort erna ook meteen gefixed.

    Maar ik heb wel het idee dat er bedrijven op professioneel niveau bezig zijn om malware te produceren. Of ze dit doen door middel van personeel of door het inhuren van freelance programmeurs weet ik niet, maar er wordt best veel geproduceerd.

    Ik moet opeens terugdenken aan een zaak die volgens mij ruim 20 jaar geleden speelde, waarbij een programmeur mee had gewerkt aan een financiele applicatie die miljarden kleine transacties verwerkte. Hij zorgde er hierbij voor dat alle bedragen op 1 cent naar beneden werden afgerond en het afrondings-verschil werd vervolgens op zijn eigen rekening bijgeboekt. Dat heeft maanden gedraaid waardoor deze man miljoenen halve centen verdiende. En bij elkaar was het wel een mooi, klein fortuin.

  22. @Wim, iets moeten inbouwen dat spyware kan zijn lijkt me echt risico van de werkgever. Daarvan zou ik nog wel durven verdedigen dat jij niet kunt overzien of dit legaal is of niet. “Silent install” is op zichzelf een legitieme behoefte. Misschien wordt er via een papieren contract wel opt-in vergaard of gaat de applicatie ergens de markt op waar dit wel legaal is.

  23. @Arnoud, het hangt natuurlijk ook af van de specificaties die de werknemer ontvangt. Toch zou ik als werknemer extra voorzichtig zijn met dergelijke zaken. Daarom bezoek ik dit blog ook zo graag, zodat ik weet wat er wettelijk gezien nog net toelaatbaar is! 🙂 Maar een beetje programmeur is niet dom. (Okay, ik ken uitzonderingen op die regel!) Als er in de specificaties staat dat je code moet schrijven waarmee je via een WiFi netwerk wachtwoorden kunt stelen dan moet er toch een lampje gaan branden. Als je code schrijft die duidelijk miljoenen emails gaat versturen over obscure SMTP servers dan moet er ook een lampje gebruiken. Als je in de code ziet dat ingevoerde gebruikersnamen en wachtwoorden niet alleen worden gevalideerd maar ook nog eens naar een webserver van het bedrijf worden verstuurd moet ook een lampje branden. En natuurlijk kan er een legitieme toepassing voor zijn, maar laat een werkgever dit eerst maar eens uitleggen voor je eraan gaat werken…

  24. Ik denk dat de discussie beetje afdwaalt maar dat is niet erg. Natuurlijk wordt er software geproduceerd voor minder gewenste (moreel, ethisch) dan wel strafbare en verboden doelen. De digitale wereld is echt niet anders dan de niet digitale wereld.

    Als ik slimme zware crimineel zou zijn, (ik ben dat niet en werk er ook niet voor!!) dan zou ik me omringen met experts op ICT gebied en die aan me binden door riante beloning en andere middelen zoals b.v. de Russische of Italiaanse maffia dat doet.

    Er zal ook altijd wel een schemergebied zijn waar het niet zo duidelijk is, een website voor Palm-Invest, een programma waarmee je beveiliging kunt omzeilen enz. (dit laatste is overigens in aantal landen wel strafbaar).

  25. Nou ja, afdwalen… 🙂 Uiteindelijk gaat de vraag vooral om in hoeverre een werknemer verantwoordelijk gehouden kan worden voor de code die hij zelf schrijft. En dan hebben we het niet over fouten in de code maar meer beveiligings-problemen en illegale toepassingen. En dan vooral het schemergebied van het toelaatbare. Zelf werk ik dus voor een bedrijf dat niet zelf gevoelige informatie van personen bewaard. Wel maken wij software voor andere bedrijven en die andere bedrijven beheren dan met onze software de klantgegevens van honderden, zoniet duizenden klanten. Voor die bedrijven is beveiliging dus vrij belangrijk! Maar ons product wordt geadverteerd als eenvoudig, trendsettend, het nieuwste van het nieuwste en beveiliging is iets dat op pagina 5 van de brochures wordt vermeldt. Bij wijze van spreke dan. En niet dat ons product onveilig is, want het voldoet goed aan veiligheids-eisen en we laten regelmatig een extern bedrijf een audit uitvoeren op de code en de beveiliging van onze pakketten wordt goed getest. Maar de realiteit is gewoon dat veiligheid niet verkoopt! Veiligheid is in de software business vaak meer een bij-effect. We kunnen onze producten als de meest veilige ter wereld aanbieden en enorme garanties aanbieden, maar dat verkoopt gewoon niet. Wat bedrijven vooral zoeken in software is een product dat hun veel werk uit handen kan nemen. Veiligheid is vaak een ondergeschoven kindje.

  26. Ik moet opeens terugdenken aan een zaak die volgens mij ruim 20 jaar geleden speelde, waarbij een programmeur mee had gewerkt aan een financiele applicatie die miljarden kleine transacties verwerkte.

    Ja, dat kwam in 1983 aan het licht. Dat was ene Gus Gorman.

  27. Stel, programmeur A werkt voor bedrijf B, en als zodanig ontwikkelt hij een website voor bedrijf C. C heeft klanten D. A ontdekt daarbij dat de manier waarop er in B geprogrammeerd wordt er voor zorgt dat de persoonsgegevens van D niet goed beschermd worden.

    De eerste actie lijkt mij om het management van B te informeren, en voor te stellen hoe het beter kan. Maar wat wordt de volgende actie, als het management van B geen verandering doorvoert?

    Mag A (anoniem) C inlichten over de problemen? Of misschien een anonieme publicatie doen om D te waarschuwen? Mag A een demonstratie geven van een concreet veiligheidslek, als bij de demonstratie geen echte schade ontstaat?

    En ontslag nemen mag natuurlijk, en is misschien ook wel verstandig bij zulke grondige meningsverschillen, maar dat lost het probleem natuurlijk niet op.

  28. @Corn?, een leuke vraag maar ik kan alleen aangeven wat ik dan zelf zou doen, en in het verleden dus ook gedaan heb: aangeven bij management dat de beveiliging onvoldoende is en dat ik dus niet de verantwoording neem voor de code die ik vervolgens moet ontwikkelen op basis van een slecht ontwerp. Bij een heel slecht ontwerp zal ik zelfs helemaal niet meewerken. En als ik dus niet hoef mee te werken aan de bouw ervan vind ik het prima. Het is immers een risico voor de werkgever.

    Mocht mijn werkgever dit werkweigering vinden dan escaleert het wat mij betreft helemaal tot aan de kartonrechter waarbij ik zal zorgen dat ik hele goede argumenten heb voor mijn beslissing, dat ik dit heb beslist in het belang van mijn werkgever maar dat mijn werkgever dit om wat voor duistere reden dan ook tegen mijn advies in gaat. Maar dan moet ik wel eerst mijzelf ervan overtuigen dat ik absoluut gelijk heb. Als ik twijfel over mijn beslissing doe ik gewoon mijn werk.

    Ontslag nemen is geen goede oplossing voor dit soort zaken, tenzij je werkgever duidelijk met iets crimineels bezig gaat. Bij criminele acties van de werkgever gewoon bewijs verzamelen en aangifte doen bij de politie. Als de politie dan aangeeft dat je beter meteen ontslag kunt nemen, doe je dat, en anders gewoon even afwachten. Je staat namelijk flink steviger als je ontslagen wordt!

  29. @Wim ten brink #24: Ik heb ooit gehoord dat dat dit bij de voormalige postbank speelde. Het zou gaan om renteberekeningen die inderdaad op een cent naar beneden afgerond werden, waarbij dus de gemiddelde halve cent per rentebetaling op een persoonlijke rekening van een ontwikkelaar werd gestort. Misschien is het een urban legend, misschien is het waar. Vast staat dat er ooit ontwikkelaars zijn geweest (en nog steeds natuurlijk) die het probleem van de halve centen van rentebetalingen op moeten lossen.

    Terugkomend op het gestelde probleem: Ik heb ooit ook in de positie van de vraagsteller gezeten: Kwam al in mijn proeftijd tot de conclusie dat er op technisch en managementvlak flinke problemen waren. Ik mistte de technologische drive en zag flinke organisatorische problemen. Ik was na drie weken klaar om thuis te blijven zitten. Ben toen toch overgehaald om te blijven, met het verhaal dat het management ook de problemen signaleerde, en daar samen met mij graag iets aan wilde doen. Na 10 maanden en minimale verandering van de situatie had ik het echt gezien. Bij mijn huidige werkgever heb ik het wel enorm naar mijn zin.

    Als je een goed verhaal hebt (dat blijkt niet uit de quote in het artikel overigens, dat hebben anderen al geconcludeerd), snij de problemen aan bij je collega’s, door het probleem toe te lichten, te masseren, stimuleren, motiveren en daarna doe je precies hetzelfde bij management. Uitleggen, masseren, stimuleren, motiveren. Begin met ??n collega die je respecteert en meer senior is dan jij, bespreek dit soort zaken met hem zonder negatief te gaan doen. Het helpt je gedachten te vormen wat er nou precies mis is en het is een belangrijke reality check. Misschien heb jij wel theoretisch perfecte oplossingen en zijn je collega’s enorm van het afsnijden van bochten omdat dat op dat moment de praktische oplossing is. Lightning talks zijn een goede manier om kennis uit te wisselen of even vijf minuten te ranten op iets kleins.

    Mijn ervaring met jonge ontwikkelaars op HBO niveau is dat ze in hun Java-OOP werkelijkheid zitten die ze van leraren heben geschoenlepeld gekregen als de perfecte oplossing voor alle problemen. Waar meer dan 30 regels code in ??n method direct gerefactord moet worden naar iets wat dan ‘beter’ is. Ik zeg niet dat Object Oriented Programming niet goed is, ik zeg alleen dat het geen religie is. Slechte OO code kan v??l erger zijn dan slechte procedurele code.

    Kun je de organisatie waar je werkt niet be?nvloeden, dan heb je volgens Cal Evans twee opties: Zorg dat je achter de gekozen oplossing staat, of wegwezen. Vacatures genoeg.

    Dan is er nog de situatie dat je iets ongeoorloofds zou weten of moeten doen. Beloofde veiligheid van gegevens volgens een PCI DSS certificering waar in de praktijk niet aan voldaan wordt, malware, spyware of z?lfs het maken van een tell-a-friend tool die niet aan de regels voldoet. Dan word het weer een juridisch verhaal (jeeh, back on topic!) en dan moet Arnoud het maar zeggen…

  30. @casper: Je stelling “Mijn ervaring met jonge ontwikkelaars op HBO niveau is dat ze in hun Java-OOP werkelijkheid zitten die ze van leraren heben geschoenlepeld gekregen als de perfecte oplossing voor alle problemen. Waar meer dan 30 regels code in ??n method direct gerefactord moet worden naar iets wat dan ‘beter’ is. Ik zeg niet dat Object Oriented Programming niet goed is, ik zeg alleen dat het geen religie is. Slechte OO code kan v??l erger zijn dan slechte procedurele code:”

    Kan je wat mij betreft niet zo algemeen stellen, zeker als je mijn eerdere bijdrages leest. Ik heb bij twee HBO instellingen lesgegeven en nergens wordt OO (vaak ivm Java) als een soort religie uitgedragen

    Ik kom zelf uit de school van Algol (68) Fortran, C, C++ Cobol en zal nooit stellen dat OO hemel op aarde is. Studenten moeten naast coderen in een taal vooral leren hoe je een probleem analyseert, een ontwerp maakt en uiteindelijk tot code komt. Daarbij is betrouwbaarheid, inzichtelijkheid, een verifieerbaarheid belangrijk.

    refactoring doe je niet bij bepaald aantal regels maar als de complexiteit van de code een herziening vraagt. Dat was vroeger in de jaren 80 het geval, nu nog steeds…

    Veel HBO onderwijs in OO talen is vaak helemaal niet OO, ik heb daarom voorkeur voor talen als BLue-J, Alice2, Lua, Python om ze dat aan te leren. Dit naast talen zoals Haskell.

    Tenslotte geloof ik zelf in de MDD aanpak, code genereren uit een model met talen als Ruby of tools als Cathedron of Mendix.

    zoals ik al eerder stelde, Silver Bullets bestaan niet…

  31. @Casper, zelf heb ik aardige verbeteringen in de code kunnen doorvoeren door voor nieuwe modules gewoon te bouwen op mijn eigen ervaring en gewoon mijn eigen werk-methodes te gebruiken. Dat betekent dus dat ik documenteer wat ik ga doen en achteraf hoe het uiteindelijk geworden is. Code probeer ik vooral leesbaar te houden door de methodes klein te houden en bij voorkeur op een logische manier te groeperen. Ik maak tevens veel gebruik van de nieuwste features die mijn ontwikkel-omgeving levert, ook al zijn die nog onbekend bij mijn collega’s en pionier ook graag met nieuwe technieken. En op die manier trek ik de rest van het team voort door allerlei nieuwe ontwikkelingen en draag ik bij tot de kennis-verbetering binnen het team zelf. Ik vertrouw ook niet op een enkele methode om te ontwikkelen, simpelweg omdat iedere situatie weer zijn eigen oplossing vereist. OO is maar een middel om een bepaald doel te bereiken, het is geen doel op zich. Beveiliging is belangrijk, maar het is een investering die het wel waard moet zijn. De data van je DVD collectie is leuk, maar bevat geen gevoelige informatie. Veel bescherming heeft dat niet nodig. Maar je internet-bankieren software met tan-codes en zo, ja… Die moet je goed beschermen. De truuk is ook om altijd gewoon een balans te vinden. Als je een theoretische perfecte oplossing kunt schrijven binnen de tijd die er voor staat, gewoon doen! Maar in de praktijk moet je gewoon accepteren dat je tevreden moet zijn met minderwaardigere oplossingen simpelweg omdat de deadline steeds dichter in de buurt komt. En het zijn vooral deadlines die ervoor zorgen dat code vaak minder goed in elkaar zit dan men zou willen. Maar ja, een perfecte oplossing duurt misschien wel een jaar om te schrijven, terwijl er andere methodes kunnen zijn die al binnen een maand gebruikt kunnen worden. En die tijdsdruk vind je dus terug in het product. En ook in de prijs, want als producenten enorm lang bezig zijn geweest met een product, dan wordt het product ook een stuk duurder. Uiteindelijk, als je moet kiezen tussen perfect en goed genoeg, is goed genoeg meestal al goed genoeg voor de meeste klanten.

    Ik ben de meeste programmeer-ervaring met Pascal/Delphi, maar heb daarnaast gewerkt met PHP, C++, C# en ook het oudere C, Visual Basic, Basic PDS (voor ms-dos!), SQL (sinds 1986!), COBOL, XSLT voor zover je dat een taal kunt noemen, ASP, ASP.NET, ColdFusion, Java, JavaScript, vbScript, Assembly en enkele DSL taaltjes. (En ik ben er vast nog een paar vergeten te noemen.) Ik pas mij dan ook gewoon aan, aan de mogelijkheden die de ontwikkel-omgeving en platform mij leveren. Als ik bedenk dat ik in 1982 al zat te programmeren op een programmeerbare rekenmachine en de ABC-formule erin had weten te krijgen in 42 instructies, dan denk ik dat ik best een knappe programmeur ben. 🙂 Gelukkig hebben mijn werkgevers vaak al snel gezien dat ik ook inderdaad enorm ervaren ben, zodat ik meestal wel mijn zin krijg.

    Maar de vraag is natuurlijk in hoeverre programmeurs ook juridisch op de hoogte zijn over wat er wel en niet mag in software. En nee, ik denk niet dat programmeurs tegenwoordig zelfs maar een beetje juridische informatie in hun opleiding meekrijgen. Dat zou anders best handig kunnen zijn! Het is ook eigenlijk geen noodzaak voor je werk als programmeur omdat die verantwoording eigenlijk ligt bij diegene die het ontwerpt. Maar ook die hebben vaak een beperkt juridisch inzicht. Ieder ontwerp zou eigenlijk ook door een jurist onderzocht moeten worden om beoordeeld te worden of alles wat de uiteindelijke code gaat doen ook daadwerkelijk legaal is. Maar ja, net als andere ontwikkel-stappen is dit een proces dat geld en tijd kost en niet bijdraagt aan de oplevering van het uiteindelijke product. En omdat de deadline snel dichtbij komt zie je vaak dat men al snel bepaalde stappen gaat overslaan in de hoop meer tijd te hebben om het product op de markt te brengen. Documenteren wordt overgeslagen, testen worden beperkt uitgevoerd, stress-tests worden overgeslagen, code audits gebeuren niet, enzovoorts. Het is helaas een bekend verschijnsel in de software ontwikkeling. En het ergste is, is dat als men weet dat men 6 maanden de tijd heeft, men vaak heel rustig begint met ontwerpen maken en de boel netjes op te zetten. Veel vergaderingen, veel aandacht aan wat de klant uiteindelijk wil en dan zijn er nog maar 3 maanden over en is er nog geen code geschreven. Paniek begint een beetje aan te komen en men gaat het tempo iets opvoeren. Een paar stappen worden overgeslagen, enkele proof-of-concepts worden geschreven en er is nog wat meer overleg. En dan is er nog een maand over en moet nog steeds 80% van de code geschreven worden en daarna nog getest worden! Dus in twee weken moeten de programmeurs als een gek code gaan kloppen waarna het test-team nog twee weken kan testen. Maar de programmeurs hebben uiteindelijk nog 5 weken nodig, en het testen levert ook nog veel bugs op zodat het geheel nog een maand extra nodig heeft. Het hele team balen, zwaar gestressed en dat terwijl ze zo relaxed begonnen. Gelukkig is dat op mijn werkplek al een stuk verbeterd en heb ik nu al een belangrijk deel van de code klaar die pas in maart volgend jaar opgeleverd gaat worden! Da’s nog eens vooruit werken! 🙂

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS