En dan die over het paard getilde ict-r die vindt dat hij recht heeft op een riant salaris, en er een puinzooi van maakt.
Als iemand een baan kiest om dat die goed betaalt, kun je niet verwachten dat die ook naar behoren wordt vervuld.

Daar ben ik het grotendeels mee eens, maar wil wel een nuance aanbrengen: we zijn in die 70 jaar enorm veel beter geworden in het goed ontwerpen, vinden (testen op) en voorkomen van bugs in gewenste functionaliteit.

Het ontwerpen, ontwikkelen en testen van systemen, met weinig (en vooral met aantoonbaar) geen ongewenste functionaliteit, staat nog in haar kinderschoenen. Reden: we hebben er onvoldoende geld voor over.

Ik mis de menselijke fouten van beleidsmakers en overheden.

Sommigen krijgen ook een riant salaris voor het onderhouden van een website, terwijl ze de hersens hebben van een garnaal opgevuld met zaagsel. Onveilige log-ins, onveilige IDs tracking, verkeerde configuraties, oude en ongepatchte CMS, verlaten code, oude code vanwege kostenbesparingen, enzovoort enzovoort. Heeft de baas dezelfde hersenopbouw gaat de onveiligheid nog een tijd ongeremd door. Cerf heeft gelijk, algeheel technisch zijn we met sprongen vooruitgegaan, individueel hebben we het niet bij kunnen houden en zijn we enorm "verdommelijkt", gedeeltelijk uit gemakzucht, gedeeltelijk vanwege slechte en verkeerde opleiding, De slimmerik wordt overal meestal als bedreiging gezien (voor de status quo, het verdienmodel, vanwege het risico op het slimmer maken van anderen, en geeft nog maar een paar duizend andere redenen op). Daarom moet Cerf constateren wat ie constateert. Helaas, pindakaas! De Govert Flinckjes blijven jaloers op de Rembrandtjes.

Arbeiders worden gewoon betaald naar gelang de vraag en het aanbod. Dat IT-ers goed betaald worden heeft gewoon te maken met een stijgende vraag met een maar beperkt aanbod, en niks anders. Slecht personeel heb je overal, van plantsoenendienst tot advocatuur, volgens mij het salaris daar weinig mee van doen.

En een neiging om te bouwen wat je qua voorstellingsvermogen aankan, waardoor al je bevattingsvermogen opgaat aan de gewenste functionaliteit, zodat de veel lastiger definieerbare ongewenste functionaliteit (wat een systeem moet doen is begrensd, wat het niet moet doen is onbegrensd) nauwelijks of niet aan bod komt. Als je degelijke systemen wilt bouwen dan bouw je bescheiden systemen zonder fancy toeters en bellen.

Ook bestaat het effect dat ontwikkelaars die dingen razendsnel af hebben goed scoren bij gebruikers en management. Dat ze ook een opeenstapeling van complexiteit en veel bugs produceren lossen ze op door even slagvaardig de bugs die ontdekt worden te verhelpen. In plaats van dat iemand zich afvraagt wie die bugs eigenlijk heeft geproduceerd (die snelle ontwikkelaar) scoort hij opnieuw door het systeem snel weer aan de praat te krijgen. De hogere onderhoudskosten worden als een gegeven geaccepteerd terwijl je eigenlijk zou moeten concluderen dat het systeem onaf in produktie is gegaan en dat die snelle ontwikkelaar helemaal niet zo goedkoop werkt. Het is geen kwestie van het geld er niet voor over hebben, het is een kwestie van niet snappen waar men het aan uitgeeft.

Ik heb me in omgevingen met dat soort mensen soms vertwijfeld afgevraagd of ik zelf niet eens minder grondig moest worden. Ik was niet razendsnel klaar, ook niet razend traag, maar wat ik maakte was zo stabiel dat het menigeen nauwelijks opviel dat het er was, het deed gewoon wat het moest doen en werd daardoor vanzelfsprekend en onzichtbaar. Het wrange is dat je meer opvalt en gewaardeerd wordt door fouten te maken en ze te herstellen dan door ze om te beginnen al niet te maken. Ik heb de stellige indruk gekregen dat er managers waren die mij daardoor vooral als een kostenpost zagen terwijl brokkenpiloten op handen werden gedragen, wat gelukkig in balans werd gehouden door een uitstekende reputatie onder collega's die wel zagen wat ik waard was waar die managers dan weer niet omheen konden. Zolang dat soort coginitieve dissonantie alom voorkomt vrees ik dat het aanmodderen blijft.

Het eerste wat je tegenwoordig geleerd krijgt bij informatica opleidingen is dat je code niet meer blind uit je hoofd moet leren. Veel code is op het internet te vinden, ga niet het wiel opnieuw uitvinden. (Het is de reden dat ik geen vertrouwen meer heb in dat papiertje)

Het is volgens mij de reden dat er niet alleen niet geleerd wordt van fouten, maar dat die fouten ook gewoon klakkeloos gekopieerd worden.

De theorie over hoe het hoort is in de loop der jaren vooruit gegaan, maar ik vraag me af of het de ontwikkelingen in de complexiteit van computersystemen heeft kunnen bijhouden. In de praktijk zie ik kwaliteitszorg vaak als ondergeschoven kindje van de softwareontwikkeling. "Agile" is tegenwoordig populair, maar hoe waarborg je dat een "Agile team" goede kwaliteit oplevert?

Ik durf het haast niet te zeggen. Maar volgens mij heb je gelijk.

De theorie mag vooruit gegaan, de complexiteit is dusdanig toegenomen dat de ketens nauwelijks meer te overzien zijn. Dan mag het testen (eg ISTQB) wat aanpak betreft verbeterd zijn het eindresultaat laat veel meer hiaten open dan vroeger in de eenvoudigere ketens. De kopieerdrift zoals cjkos beschrijft helpt mee om de fouten ongecontroleerd over te nemen. Met het Agile werken komt dan het argument dat iemand anders vast wel de controles al gedaan heeft .. moet je geen tijd meer aan spenderen.

Maar als je in je eerste jaar hoort: "Leer javascript maar een beetje van het Internet". Hoe kan dat dan goed gaan?
Wie waarschuwt er dan voor inline javascript, wie checkt waar third party code allemaal toegang heeft? Wie zorg dat de SRI hashes goed worden gegenereerd. Wie klopt de juiste HTTP response headers in?
Als je later allerlei versies jQuery libraries (meestal erop gezet vanaf het moment van installeren) tegenkomt met veilige en af te serveren code op een en dezelfde website. Waar zijn we dan mee bezig? Met alleen naar code fouten en SQL onveiligheidjes bekijken komen we er niet, er moet flink software 'gedebugged' worden, gedeobfusceerd, uitgepakt, getest en gechecked.
Sommigen weten heus wel wat ze komen doen en zijn hun gewicht meer dan waard op de werkvloer, maar anderen tasten maar een beetje in het duister waar het "best practices" betreft. Lees deze mensen is in, stuur ze naar een beveiligingscursus.
Later leren ze het elkaar wel. "De man van negen uur leert het de man van tien uur wel" en zorg dat diegenen die ze tegenwerken niet zoveel invloed hebben. (Kostenbewaking, marketing etc. die mensen, die van toeten noch blazen weten). Er is nog een hele lange weg te gaan. We doen hier allemaal aan bewustwording en meer kunnen we niet doen.

"Je bent het slachtoffer van een hacker."
Of
"Je hebt een laag gevoel van verantwoordelijkheid omtrent klant privacy en slechte houding richting bugtesten en veiligheid".

Dat klinkt natuurlijk al heel anders. Terwijl het soms op hetzelfde neer komt. Zelfs met de beste beveiliging kan iemand gehackt worden, maar dat is dikwijls ook anders. Aangezien security volledig gaat over lagen maken van beveiliging en risico beperken en schade minimaliseren als er toch iets gebeurd. Is het wel degelijk mogelijk iemand grotendeels zelf verantwoordelijk te stellen voor vrijwel elke schade die er is.

Dan gaan we toch enigzins de goede richting op, aangezien men nu soms al wettelijk verplicht is melding te doen als ze gehackt zijn. Het is natuurlijk wel jammer, dat zulke verantwoordelijkheid afgedwongen moest worden.

Neem aan dat het hier gaat om een MBO-opleiding. Daar moet je het inderdaad ook niet hebben van de les stof, maar voornamelijk van stages en het bedrijfsleven zelf. Bij het afstuderen mogen ze vaak een webshop bouwen, of order systeem. Dat natuurlijk zo lek als een mandje is. Want daar is nooit iets over gezegd. MBO applicatiebeheerder opleidingen zijn slechter dan slecht, eigenlijk vaak nog niet eens de naam waardig.

Dermate slecht dat ze eigenlijk per direct opgedoekt zouden moeten worden, omdat ze op alle vlakken falen. Men leert niets of te weinig over:
- Security
- Git/Subversion
- Object georiënteerd programmeren
- Bugtesten/debuggen met stacktraces en breakpoints
- Applicatie profiling
- Geautomatiseerd testen

Bron: zelf meer dan 20 stagiaires mogen begeleiden uit verschillende scholen.

Eerder dat bedrijf dat denkt ICTers voor de helft van het geld te kunnen krijgen met een certificaat meer maar met 20 jaar minder ervaring :)
Je krijgt waar je voor betaald..

Eens, veel weten wel dat het werkt maar niet waarom.
Een zelf oplossend vermogen is vaak 0, erg triest.
Maar goed, bedrijven kiezen daar zelf voor omdat die mensen een stuk goedkoper zijn dan de oudere, meer ervaren mensen.

Adobe en Oracle. De grootste foutenmakers.

Ik denk dat je een fout maakt; je bedoelt vast Macromedia en Sun's MySQL.
Maar weet; als je wijst naar een ander, dan wijzen er doorgaans 3 vingers in je eigen richting.
Ik persoonlijk maak nooit fouten, ik ontdek nieuwe mogelijkheden.

IF you pay peanuts, you get monkeys is een veel gehoorde kreet in ICT en daarnaast de vraag wat kost security ?

Jij hebt informatica gestudeerd?

Waar cjkos naar verwijst is een gangbaar dogma in aanpak met projecten. Dan zou de informatica studie iets anders beweren? Dan heb je de gangbare klacht dat de studie niet levert wat in de praktijk nodig is. Welke optie je ook kiest de mens blijft het proleet.