Hoofdcategorieën

[RSS] Index » Nieuws » Core » Software » Oproep tot 'professionalisering' programmeursberoep

Oproep tot 'professionalisering' programmeursberoep

Door Harm Hilvers, woensdag 16 mei 2007 20:50
Bron: Trouw, submitter: VelhaChica, views: 24.429

Gemiddeld kosten fouten in software Europa en de VS rond de 200 miljard euro per jaar. Daar blijft het echter niet bij: bugs in software hebben ook mensenlevens gekost. Voor Trouw reden om te betogen dat er regels moeten komen voor het programmeursvak.

Zoals iedere tweaker weet, maakt ieder elektronisch apparaat gebruik van chips die op hun beurt weer voorzien zijn van allerlei software. In veel gevallen werkt die software zoals het hoort, maar helaas niet altijd. Zo moest Mercedes 1,3 miljoen auto's terugroepen om software te vervangen, reden in Twente enkele weken geen treinen in verband met problemen in de applicatie, stopte een Amerikaanse Mars-robot met werken vanwege een softwarefout en ontplofte de Ariane V door een aantal bugs in de programmatuur. Volgens Chris Verhoef, hoogleraar Informatica aan de Vrije Universiteit te Amsterdam, is het dan ook vreemd dat er geen wetten zijn die voorschrijven dat de auteur van programmacode daarvoor een licentie moet hebben. Verder hoeven de projectmanagers niet te beschikken over officiële papieren, wat tot een gebrek aan professionaliteit kan leiden in de automatisering.

Ondanks dat ook de overheid last heeft van fouten in software, de Belastingdient krijgt bijvoorbeeld veel kritiek te verwerken vanwege softwarefouten, doet ze er niet het juiste aan, aldus Verhoef. Er worden topmanagers vervangen, maar die kunnen er vaak ook maar weinig aan doen, aangezien het probleem zich bij de softwareontwikkelaars bevindt. Bas Linders, voormalig hoofdredacteur van Automatiseringsgids, is het met Verhoef eens en opperde twee jaar terug het idee om een Ict-Effect Rapportage in het leven te roepen. Hierdoor zou er beter nagedacht worden over de positieve en negatieve effecten van ict-investeringen. Volgens Linders wordt het dan ook hoog tijd voor een professionaliseringsslag in de softwareontwikkelsector, te beginnen met de ict-opleidingen. Verhoef is al tevreden als de overheid een inventariserend onderzoek zou laten doen om het probleem helder te krijgen.

Volgende 23:18
Vorige 18:38

Categorieën

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 233 reacties zichtbaar2330 Neutraal: 232 reacties zichtbaar232+1 Meerwaarde: 77 reacties zichtbaar77+2 Verplicht leesvoer: 16 reacties zichtbaar16
«  1  2  3  4  5  6  »

Door Floor, donderdag 17 mei 2007 08:16

Score: 0
Domme en makkelijke opmerking.
Ik denk dat Microsoft de zaken wel redelijk in orde heeft. Ook met de certificering van de microsoft partners is een goede zet. Ik ben het overigens wel volledig eens dat het hoog nodig is om de ICT te "professionaliseren". Helaas zie je te veel idioten zich bezig houden met de verkeerde zaken. Dit gaat op voor beide partijen: als opdrachtgever heb je de verplichting om duidelijk over te brengen wat de bedoeling is, als leverancier heb je de plicht om helder te krijgen wat de opdrachtgever bedoeld en duidelijk te zijn of iets wel of niet kan. Vooral met dat laatste wordt nog veel te makkelijk omgesprongen. Alles gaat zolang er maar betaald wordt. Maar wat vergeten wordt is dat maatwerk ten alle tijden moet worden voorkomen. Liever een standaard pakket dat voor 1000 klanten moeten worden onderhouden dan 1 waar veel maatwerk inzit. Maatwerk is buggevoelig, duur en belemmerd de ontwikkeling.

Door arjankoole, donderdag 17 mei 2007 10:18

Score: 0
Liever een standaard pakket dat voor 1000 klanten moeten worden onderhouden dan 1 waar veel maatwerk inzit. Maatwerk is buggevoelig, duur en belemmerd de ontwikkeling.
Het probleem met je opmerking is alleen dat de meeste bedrijven dusdanig andere bedrijfsprocessen hebben, dat je in de meeste gevallen wel maatwerk nodig hebt.

De situatie die je omschrijft zou inderdaad veel idealer zijn.

Door Floor, donderdag 17 mei 2007 13:02

Score: 0
Het probleem is dat veel bedrijven niet beseffen dat met de implementatie van nieuwe software (ERP pakketten bijv) de procedures moeten worden aangepast. Ze willen vasthouden aan de oude manier van werken maar investeren ondertussen veel geld voor nieuwe software om efficienter te kunnen werken. Vervolgens beginnen medewerkeers te klagen dat ze op zus en zo manier willen werken en daar begint het maatwerk met alle bovengenoemde risico's en nadelen.

Ieder bedrijf is uniek maar dat geldt niet voor elk bedrijfproces. Wanneer je als bedrijf in staat bent om aan te passen (optimaliseren) rond software dan zal de software ook doen waarvoor het is aangekocht.
Updates en nieuwe ontwikkelingen van de software kunnen dan sneller, tegen veel lagere kosten en vooral met veel minder risico worden doorgevoerd. Bugs zullen veel sneller naar boven komen omdat veel meer bedrijven/mensen met dezelfde software werken. Ook loont het beter testen van software door de fabrikant omdat de kosten hiervan per klant lager zijn.

Je opmerking dat de situatie veel idealer zijn kan worden gecreerd door een goed software huis. Je kan dan denken aan modules die aan de software worden gekoppeld waardoor toch een "maatpakket" ontstaat.

Door timera, woensdag 16 mei 2007 20:55

Score: 0
Hmm en raad eens wie die licenties wilt uitgeven in opdracht ? $$

Door progster, woensdag 16 mei 2007 20:57

Score: 2
In amerika is er zo al een systeem als ik mij niet vergis, ict bedrijven krijgen daar een rating van 1-5 naargelang de professionaliteit van hun ontwikkel proces. De overheid gebruikt er enkel bedrijven met een minimum score van 3/5 (er is op de moment nog geen bedrijf met 5/5 als ik me niet vergis).

Enkele weken geleden was een prof van ons er over bezig, kan er niet zo direct een bron van vinden :)

Door Jungian, woensdag 16 mei 2007 20:59

Score: 1
Dat is geen Amerikaans systeem. Dat is ITSM :)
Kort stukje op Wikipedia hierover : http://nl.wikipedia.org/wiki/IT_Service_Management

[edit]

Aangezien de poster hieronder weggemod is :

iedereen die CMM schreeuwt moet nog eens goed nadenken. Het is 1 van de vele modellen om de volwassenheid van een bedrijf vast te stellen.

Hogere scores staan bij CMM overigens niet voor een beter eindproduct, slechts voor het (op een bepaald niveau) procedureel handelen van een bedrijf.

Door Bobco, woensdag 16 mei 2007 21:07

Score: 0
Ahem, CMM zul je bedoelen...

Door Jungian, woensdag 16 mei 2007 21:10

Score: 1
En dat wordt gebruikt bij ... ITSM. Als je denkt dat CMM het enige volwassenheidsmodel is moet je je misschien even inlezen

Door mashell, donderdag 17 mei 2007 12:32

Score: 0
iedereen die CMM schreeuwt moet nog eens goed nadenken.
Done. Het is inderdaad CMM. Dat ITSM waar jij zo trots op bent is voor systeembeheerders (read your own wiki). Het artikel gaat over software ontwikkeling, daar is CMM of CMMI of automotive spice of wat dan ook actueel.

Door Jungian, donderdag 17 mei 2007 17:44

Score: 0
Jij moet echt eens een boek gaan lezen over volwassenheidsmodellen en ITSM in plaats van deze nonsense neerplempen. ITSM heeft ook geen reet te maken met systeembeheer. ITSM heeft ALLES te maken met het inrichten en monitoren van processen, organisatiebreed en per proces.

CMM is één van de vele volwassenheidsmodellen, meer niet. Een (hoge) score van 5 in het CMM is juist slechter voor het uiteindelijke resultaat, dan 3, aangezien er compleet volgens de specs/afspraken gewerkt wordt, waardoor bugs e.d. vrolijk meegeprogrammeert worden.

Moraal van mijn betoog dus : aan het CMM alleen heb je niet.

Door Guru Evi, donderdag 17 mei 2007 22:50

Score: 0
ITSM heeft ALLES te maken met het inrichten en monitoren van processen, organisatiebreed en per proces.
Klinkt bij mij meer als nog een reden om een extra laag hoger management en project managers toe te voegen die eigenlijk niets toevoegen aan het volledige proces, maar toch hun zakken vullen. Net zoals SoX, ISO en weet ik wat nog allemaal.

Ik heb 'voor de grap' een examen voor de certificatie van Project Manager (2005) afgelegd (het was een proef-examen, het echte examen kost teveel geld) en ik was geslaagd zonder enig boek te openen, gewoon common sense.

Volgens mij moet er helemaal geen certificatie zijn van programmeurs. Er zijn zoveel certificaties voor vanalles en nogwat en blijkbaar kan iedereen die zomaar krijgen. Het probleem met certificaties in de industrie en ons educatiesysteem in het algemeen is dat er teveel wordt gekeken naar pure kennis en nagenoeg niet naar methodes om problemen op te lossen.

Inderdaad, de project managers en hoger management zijn meestal wel inept als het om nieuwe media gaat, maar het product moet koste-wat-het-kost morgen uit de deur. Dan is het de programmeurs fout niet dat er fouten en gaten worden geprogrammeerd. Lees eens "The Cathedral and The Bazaar" (kun je ook gratis als e-book downloaden)

Door kidde, vrijdag 18 mei 2007 00:57

Score: 1
Het probleem met certificaties in de industrie...
Toch zijn er industrie-certificaties die zeer goed werken: Zo mogen max. 3 lassen van een fotolasser worden afgekeurd per jaar. Maakt deze meer fouten, is hij geen fotolasser meer.
Dat gaat er zo streng aan toe, omdat fotolassers bijvoorbeeld een 400 bar stoomleiding of een brug in elkaar moet lassen, en het is gelijk duidelijk dat veiligheid (dus kwaliteit) dan voorop staat.
Helaas werkt het bij programmeurs niet zo: Daar staat productiviteit en kwantiteit voorop lijkt het wel, omdat het vaak minder snel duidelijk is hoe mensen hier de dupe van fouten kunnen worden dan bij bv. petrochemische installaties met giftige / explosieve stoffen etc.

Het zou misschien goed zijn om een nieuwe categorie 'kwaliteitprogrammeurs' in het leven te roepen net zoals er lassers en fotolassers zijn, zijn er dan programmeurs en kwaliteitsprogrammeurs. Als in software van deze kwaliteitsprogrammeurs meer dan x fouten (bufferoverflows etc.) per jaar per regels code gevonden worden, raken ze hun speciale titel kwijt en worden ze weer gewoon programmeur. Gezien het geringe aantal ongevallen in chemische installaties (in NL) lijkt dit systeem goed te werken.

Verder moet de nadruk in de softwarewereld ook meer op kwaliteit komen te liggen. In de industrie is er sinds 1987 al een systeem voor kwaliteitsbeheersing, de ISO 9000 serie (in de trand van CMM niveau 4 en 5, zo lijkt het). Met enige aanpassingen is deze ook voor de software-industrie bruikbaar. Belangrijk hierbij is dat alleen 3de partijen de certificaten kunnen verlenen (als bij ISO 9001)

Door ptap, vrijdag 18 mei 2007 07:27

Score: 0
Het zou in ieder geval een hoop hopeloze Word/Excel macros schelen, want die vallen er natuurlijk ook onder.

Door ]Byte[, vrijdag 18 mei 2007 12:33

Score: 0
Op zich een leuk streven, maar wat is dan de definitie van "kwaliteitsprogrammeurs"?
Ieder bedrijf zal zeggen dat ze uitsluitend kwaliteitsprogrammeurs in dienst hebben.
Ik denk dat ze betere controle kunnen uitvoeren door de goede mensen nooit bij 1 bedrijf te betrekken.

Voorbeeld:
Ik ben ooit bij een bedrijf gevraagd om een acceptatietest te doen voor een compleet nieuwe omgeving die de leverancier wilde opleveren.
(de klant had zelf de kennis niet in huis)
<span style="color:#786562">* ]Byte[ vraagt ook nooit aan de bakker of zijn eigen brood goed smaakt :Y)
</span>
Ze hebben toen voor de verschillende diciplines een aantal mensen van buitenaf aangetrokken om dit te doen.
Resultaat:
Alle deelsystemen waren afgekeurd!
En dan heb ik het niet over dat er geen labeltje op een patchkabel zit die is vergeten, maar serieuze prio 1 zaken waardoor men niet in productie kan gaan.
Dan weet je gelijk hoe het er aantoe gaat... Projectleider helemaal over de z.... (die voor diezelfde toeleverancier werkt...)
Dat is toen tot 3 keer toe op rij gebeurd, waardoor de klant afscheid heeft genomen van die leverancier.
Als PL het werk van je eigen werkgever en mensen binnen je eigen team afkeuren bij een klant geeft gegarandeerd situaties van belangenverstrengeling.

Door Motrax, woensdag 16 mei 2007 21:06

Score: 0
Die rating is Capability Maturity Model (CMM), dat is geen ITSM.

Door YaPP, woensdag 16 mei 2007 21:10

Score: 0
In amerika is er zo al een systeem als ik mij niet vergis, ict bedrijven krijgen hier een rating van 1-5 naargelang de professionaliteit van hun ontwikkel proces.
Bedoel je niet http://nl.wikipedia.org/wiki/Capability_Maturity_Model?

Die methodiek heb ik op de HBO in Enschede moeten leren. Er zijn dus wel degelijk regels voor het programmeervak in Nederland.

De praktijksituatie kan in het bedrijfsleven wel anders zijn, en dat verschilt ook per situatie. In een bedrijf met 5-12 man ga je anders om met projecten, dan in een bedrijf met 100 man, of een bedrijf waarbij mensenlevens op het spel staan.

Trouw snijd best een goed punt aan, aan softwareontwikkeling kan veel verbeterd worden. Alleen zeggen dat er geen regels zijn is kort door de bocht, en neigt naar populairisme.

Door flowerp, woensdag 16 mei 2007 21:43

Score: 0
Die methodiek heb ik op de HBO in Enschede moeten leren. Er zijn dus wel degelijk regels voor het programmeervak in Nederland.
Het zijn niet echt regels in de zin dat je ze moet naleven. Er is geen enkele instantie die er op toe ziet.

Door Wimw, donderdag 17 mei 2007 17:07

Score: 0
Het probleem met al deze regels, CMM en de diverse ISO-standaarden voorop, is dat het louter gaat over reproduceerbaarheid en traceerbaarheid. Als je een lopende-bandfaciliteit hebt om troep te maken en dat goed op papier vastlegt, voldoe je aan alle standaarden. Met software-kwaliteit heeft dat weinig te maken, met verjuridiseerde bureaucratie des te meer. Het jammere is dat daardoor de aandacht afgeleid wordt van de werkelijke inspanningen om de kwaliteit van het ontwikkelproces te vergroten. Daarmee zijn al grote vorderingen geboekt in de vorm van een aantal best practices (reviewing, versiebeheer, unit-testing, stakeholder involvement - om er een paar te noemen). Dat er echter nog geen standaard ligt is er vooral aan te danken dat deskundigen zonder accountancy-achtergrond onderkennen dat verschillende projecten een verschillende aanpak vereisen.

Door melgers, woensdag 16 mei 2007 21:10

Score: 1
Ik denk dat progster CMM bedoeld. Er zijn inderdaad niet veel organisaties die level vier of hoger halen.

http://en.wikipedia.org/wiki/Capability_Maturity_Model

Door Horemheb, woensdag 16 mei 2007 21:34

Score: 1
CMM(i) gaat vooral over hoe het software ontwikkelings proces georganiseerd moet zijn. Over hoe de programmeur uiteindelijk zijn code schrijft en welke opleiding/kwaliteiten hij moet bezitten vertelt CMM(i) je niets.
Ik heb ervaring met een Indisch software bedrijf dat een CMMi 4 certificaat heeft en waar de kwaliteit van het afgeleverde werk om van te huilen is. Iedereen kan al de regeltjes van een CMM(i) implementatie volgen, of er dan goede software uitkomt hangt uiteindelijk van veel meer af.

Door Moolie, woensdag 16 mei 2007 22:59

Score: 1
Inderdaad, ik heb precies dezelfde ervaring. Ik heb een tijdje gedetacheerd gezeten bij een bedrijf dat voor ProRail werkt. ProRail stelt logisch gezien ook diverse eisen aan zijn leveranciers, maar dit heeft (bij het betreffende bedrijf) nog niet geleid tot knappe software.

Er moest bijvoorbeeld iets veranderd worden aan de applicatie die als een trein een gebied binnengereden komt daar een treinnummer aanhangt. Wat blijkt: de applicatie had geen en mocht geen kennis hebben van de dienstregeling waarmee dat te bepalen was |:(. Er worden daar echt honderden uren besteedt aan problemen die iedere tweaker in 2 uur oplost, alleen omdat de software bagger in elkaar steekt.

Het is mij volstrekt duidelijik waarom er zoveel fout gaat op het spoor. CMM is geen garantie voor succes, daar heb je ook nog goede software architecten / programmeurs voor nodig.

Door Freakertje, donderdag 17 mei 2007 16:53

Score: 0
NASA, om er maar eens één te noemen.. Er waren er nog een paar :)

Door Lighteye, woensdag 16 mei 2007 21:00

Score: 1
Mja wat heb je aan (top) managers die geen regel code kunnen lezen. Die mensen zorgen alleen maar voor meer werkdruk i.p.v. mee te (kunnen) werken. Dat is imho meer iets wat aangepakt moet worden waar je op korte termijn snel resultaten kunt boeken. Op de lange termijn is classificering wellicht een goed idee.

Door J.J.J. Bokma, woensdag 16 mei 2007 21:18

Score: 2
De managers vertellen ons weer dat ze voorkomen dat die programmeurs allerlei toeters en bellen inbouwen die ze zelf o zo mooi vinden maar het merendeel van de gebruikers niet kan of wil gebruiken.

Ik werk al heel wat jaartjes freelance, en door zelf en programmeur en manager te zijn snap ik beide kanten van het verhaal.

Door flowerp, woensdag 16 mei 2007 21:54

Score: 2
De managers vertellen ons weer dat ze voorkomen dat die programmeurs allerlei toeters en bellen inbouwen die ze zelf o zo mooi vinden maar het merendeel van de gebruikers niet kan of wil gebruiken.
Mee eens. Een clubje dat puur en alleen uit developers (architecten, designers, programmeurs) bestaat verzand te vaak in technische details. Managers zijn wel degelijk nodig.

Echter, is het nodig om 3 managers op elke developer te hebben?

Dat lijkt soms wel de situatie waar we heen gaan. Software developen is gewoon moeilijk. Er komt zeer veel bij kijken en mensen die zich er mee bezig houden moeten niet alleen talent en aanleg hebben, maar ook de bereidheid kunnen opbrengen om veel te leren.

Zeker niet iedereen kan deze discipline opbrengen, maar ze willen wel allemaal 'mee doen'. Tel daar nog eens bij op dat over het algemeen een manager hoger in aanzien staat en meer verdient dan de hoogste opgeleide en meest ervarene hard core developer en je hebt het perfect recept voor een ramp.

Hordes mensen, die eigenlijk te weinig capaciteiten hebben om echt iets te kunnen, willen allemaal manager of 'brug persoon' worden. Studies als Informatiekunde, Sociale Informatica, BWI en tig varianten daarop zijn populairder dan ooit.

Begrijp me niet verkeerd, een echt goede manager is goud waard, maar aan hele hordes Informatiekunde-achtige mensen zit niemand (IMHO) te wachten.

Door Starfish, woensdag 16 mei 2007 22:26

Score: 2
Ik snap wel een beetje wat je wilt zeggen, maar kijk uit dat je niet generaliseerd.

Ik heb zowel HBO Bedrijfskundige Informatica als WO Informatiekunde (tm Master) gedaan - weet dus redelijk goed wat er ongeveer speelt.

Bij beide studies zag ik *voor mijn gevoel* redelijk wat meelopers (leve projectgroepen) en totaal niet-technische mensen. (Word opstarten ging nog net). Soms hadden iemand totaal geen aanleg, een andere was puur voor de dot-com hype en het grote geld maar wat gaan doen met 'Business & ICT'... mensen die het wel even allemaal zouden doen.

Ongeveer 1 op de 10 zou ik op technisch gebied goed tot zeer goed durven te noemen.

Uiteindelijk denk ik toch dat er per persoon gekeken moet worden naar diens C.V. en persoonlijkheid. Sluit niet iemand uit puur op basis van een studie die mensen met 'te weinig capaciteiten' zou leveren.

(Zelf durf ik toch wel te stellen dat ik op technisch gebied best wat in huis heb. Na eerste sollicitatie direct als programmeur aan de slag gegaan voor een wetenschappelijke organisatie. Daar zijn ze dusdanig tevreden over mijn werk dat ik al 2 verlengingen van mijn contract heb gekregen.)

Oh en Bij informatiekunde zaten er ongeveer 10-20 mensen in mijn lichting, dus die hordes vallen wel mee ;)

Door flowerp, woensdag 16 mei 2007 22:49

Score: 1
Ik heb zowel HBO Bedrijfskundige Informatica als WO Informatiekunde (tm Master) gedaan - weet dus redelijk goed wat er ongeveer speelt.
Natuurlijk, en ik bedoelde dus inderdaad ook niet dat elke persoon die Informatiekunde heeft gedaan een nutteloze persoon is. Het feit dat jij simpelweg dit artikel leest en er ook nog op reageert geeft al aan dat je een bovengemiddelde betrokkenheid bij de ICT hebt ;)

Die hordes zie ik in de praktijk echter wel. Wij zijn al tijden (zoals zo velen) op zoek naar goede developers, maar de kandidaten met een Informatiekunde opleiding (of 1 van die velen varianten daarop) die zich aanbieden is bijzonder groot. Ook gespecialiseerde bureaus als Progressive of Computer Futures, proberen ons steeds van dergelijke personen als developer aan te smeren. 1 of 2 (goede!) personen met een dergelijke opleiding hebben we zeker kunnen gebruiken als brug persoon, maar als developer zijn ze natuurlijk niet in te zetten.

Door timonb, donderdag 17 mei 2007 11:26

Score: 0
Het begrip managers wordt te pas en te onpas gebruikt. Een manager managet de bedrijfsvoering, ofwel hij zorgt dat het bedrijf blijft draaien door de juiste mensen op de goede plek in te zetten, door de financiën in orde te houden, door te zorgen dat er uberhaubt gewerkt kan worden enz.

Maar hij is en blijft uiteindelijk eindverantwoordelijk voor werk dat hij uitbesteed. Hij besteedt zijn werk uit aan projectmanagers, architecten, programmeurs, designers enzovoort. Dus hij moet al deze mensen in goede orde aansturen en zorgen voor een goed eindproduct.

Een programmeur is verantwoordelijk voor de taak programmeren, een designers is verantwoordelijk voor het designen en een manager is verantwoordelijk voor het managen van het bedrijf. Als de programmeur, designer of manager een fout maakt betekent dat een berisping of exit. Zo simpel is het!

Door Michaelm, woensdag 16 mei 2007 22:06

Score: 0
Dan krijgen die managers wel erg vet betaald voor hun simpele functie die iedere gek kan.
En als zo'n bedrijf dus zegt dat ze de opdracht wel binnen de veel te korte termijn af kunnen krijgen dan lijkt het mij toch ook dat zoiets van de manager afkomt.
En dat dit dan uiteindelijk bakken met geld kost kan men dus ook voor een groot deel aan die managers toeschrijven.
Het probleem met managers is dat ze het verschil tussen theorie en praktijk niet kennen.

Door roy-t, donderdag 17 mei 2007 00:24

Score: 1
Er is een Universitaire studie: technologiemanagement waarbij je managers krijgt die ook kunnen coden.

(en raad eens wie zich ingeschreven heeft voor die studie)

Dat soort mensen zijn perfect voor een professioneel ontwikkel team.

Door johanw910, donderdag 17 mei 2007 08:47

Score: 1
Onzin, programmeren leer je pas echt in de praktijk. Die lui die tijdens hun studie ook eens een "Hello, world" in elkaar gezet hebben en dan denken dat ze er alles van af weten zijn vaak vreselijk om als manager te hebben. Dan nog liever een die er niks van af weet en dat van zichzelf ook weet.

De beste managers zijn vaak mensen die eerst 10 jaar als programmeur gewerkt hebben en zich nog steeds als meewerkend voorman opstellen. Zo iemand weet waar hij over praat en krijgt ook respect van de developers.

Door Horemheb, donderdag 17 mei 2007 11:22

Score: 0
Amen! Er zit een hemelsbreed verschil tussen wat je leert op de universiteit en de ontwikkeling van een complex project in een bedrijfssetting.
Een studie kan een goede basis zijn, maar ook niet veel meer dan dat.

Door flowerp, donderdag 17 mei 2007 12:00

Score: 1
Amen! Er zit een hemelsbreed verschil tussen wat je leert op de universiteit en de ontwikkeling van een complex project in een bedrijfssetting.
Dat valt nog behoorlijk mee. De 2 vullen elkaar simpelweg aan. Zeggen dat het 'niet meer' dan een basis is, is misleidend, het suggereert dat je het achterwege kan laten en dat de praktijk belangrijker is. Bij een huis is een fundament ook niet meer dan de basis. Je woont niet in je fundament en je ziet het niet. Zullen we het daarom maar voortaan weglaten!?

De beste mensen zijn meestal de mensen die EN een goede opleiding hebben genoten EN een aantal jaren praktijk ervaring hebben opgedaan.

Ik merk dit nu zelf heel concreet. Ik heb HBO informatica gedaan, en als je -echt- oplet bij de lessen en niet als een sukkel meeloopt met je projecten, dan leer je er gewoon zeer veel. Van heel veel technieken die ik toen leerde maak ik ondertussen dankbaar gebruik. Daarnaast ben ik al een tijdje met een Informatica Master opleiding bezig in de avonduren. Kennis die ik 's avonds op doe kan ik bij wijze van spreken 's ochtends al gebruiken; het zet me aan om in bepaalde andere richtingen te denken, om voor een bepaalde aanpak te kiezen waar ik eerder niet over nagedacht had.

Natuurlijk is niet alles direct toepasbaar. Ik heb een vak over de theorie achter neurale netwerken gedaan. Nu heb ik momenteel in het project waaraan ik werk zelfs geen toepassing voor een kant en klaar neuraal netwerk, laat staan voor de theorie erachter. Maar stel dat ik over een tijdje op een project zit waar dat wel zo is, dan heb ik meteen alweer een voorsprong.

Mensen die geen scholing hebben gehad, en alleen in de praktijk geleerd hebben, hebben vaak wel vrij eenzijdige kennis. Ze zijn helemaal gespecialiseerd in de technieken die toevallig bij het bedrijf gebruikt werden en meer niet.

Door c0d1f1ed, donderdag 17 mei 2007 01:50

Score: 2
Wat men nodig heeft zijn software-architecten: Ingenieurs die zowel projecten kunen managen als de eigenlijke technische problemen begrijpen (en kunnen oplossen). Ze vormen de lijm tussen de hogere managers en de lagere programmeurs.

Door Horemheb, donderdag 17 mei 2007 11:25

Score: 1
Een software architect zou zich moeten bezighouden met de architectuur van de systemen binnen een bedrijf. Richting aangeen en een plaatje maken op strategisch en conceptueel vlak. Het echt managen van projecten is niet onmiddelijk iets dat ik met een architect associeer. Daar zijn poject managers voor nodig. Een goede project manager heeft natuurlijk de nodige technische kennis.

Door mashell, donderdag 17 mei 2007 12:43

Score: 0
Richting aangeen en een plaatje maken op strategisch en conceptueel vlak.
Dat vind ik nou juist 1 van de oorzaken van het probleem. Architect is trouwens een beschermde titel (bouwkundige titel). De Architect overlegt met de opdrachtgever hoe het gebouw er uit moet zien, hoe het is ingedeeld. Maar hij maakt ook de bouwtekening en rekent de constructie door zodat het echt gebouwd kan worden. Bij software architecten blijft het vaak op het klant niveau steken. De bouwtekening (interfaces, timing requirements, data structuren) komt niet van de softwareachitect.

Door Dizzy Grizzly, donderdag 17 mei 2007 08:52

Score: 2
Ik zelf ben een oude rot in het programeer vak. Maar de heer Linders is wel heel populair bezig maar blijkbaar zonder kennis en overzicht van de realiteit. De enige resultaten die zijn zogenaamde 'vakdiploma' om het maar zo te noemen zullen bereiken zijn:
1) prijs van software bij enkele honderden procenten verhogen.
2) Belemmering van instroom dan nieuwe potentieel goede programeurs door de instap drempel nog hoger te maken dan die nu al is.
Kan zo nog wel even doorgaan. Maar probeer beknopt te zijn, Kan dit volledig onderbouwen maar wegens beknoptheid vraag ik gewoon om gezond verstand als getuige.
Verder is de stelling dat programeurs verantwoordelijk zijn voor bugs wel heel simpel. Software met een rampen impact zoals in de voorbeelden gegeven zijn meestal geen individueel werk maar groeps projecten. Dit is een dure aangelegenheid die ook economisch verantwoord moet blijven. Vandaag staat de stelregel dat op elke progammeur minsten 1 tester moet zijn. Er zijn ook deadlines (helaas) die succes of falen bepalen. Je mag aannemen dat 99% van alle vaklui met of zonder 'vakdiploma' geen rampen op hun geweten willen hebben. Maar een software systeem binnen reele tijd klaar te krijgen is ook van vitaal levensbelang. En zeer gekompliseert. Soms zijn alle individuele programma onderdelen gewoon perfect maar blijkt in de praktijk dat de samenwerking van die onderdelen onder niet voorziene omstandigheden in een bepaalt zogenaamde 'environment' niet werkt zoals beoogt. Een project dat meer 3 jaar duurt is meestal al verouderd voordat het op de markt komt, Dit voornamelijk daar de technologie (zowel software als hardware) zo snel verandert. Programeurs moeten constant bijscholen. Moet dan ook weer hun 'vakdiploma' herzien worden daar die niet meer volstaat aan de tand der tijds (enkele maanden)? En wat garandeerd dat dat 'vakdiploma' met alle voors en contras rampen voorkomen?
Er gebeuren ook heel vele goede dingen door de dynamic van de vooruitgang. Laat die politiek aub niet door populistisch onrealistische beschouwingen met regulering de liberalisatie van de programmeer kunst tegen houden. In mijn inzicht is de oplossing van het kwaliteits probleem niet alleen bij de individuele aanpak van de voetsoldaat (de programmeur) maar door de meer investeren in regulering van het testen van de software. Ook moeten diegenen die deadlines opstellen verantwoordelijk worden gehouden voor hun beslissingen om overhaast een product te leveren. Programmeren lijkt een physiek makkelijk beroep maar de stress is enorm. Maar dan nog, laten we reeel zijn, is ieder met een rijbewijs is een perfecte automobist? Mogen kinderen niet meer programmeren daar ze niet aan de normen voldoen? Met dit soort welbedoelde ideen van de heer Linders vraag ik mij af of hij wel voldoende gediplomeert is om dat soort uitspraken te doen.

Door tjerkw, donderdag 17 mei 2007 10:57

Score: 1
Je maakt veel goede punten maar je moet weten dat elke persoon die een beetje kan programmeren zichzelf programmeur noemt ( Ik bedoel hiermee die visual basic gasten :-)

Een persoon die een groot software project tot een succes kan brengen moet ook verstand hebben van het hele process, en daarnaast kennis hebben van correct testen en eventueel het formeel valideren van de software( Met bijvoorbeeld spin+promela: www.spinroot.com )

Ik denk dat goede regels op dit vakgebied heel belangrijk is zodat we beter onderscheid kunnen maken in de kennis van een bepaald persooon.

Ook is dit goed voor het programmeurs beroep in het algemeen. Het heeft nu nog een laag aanzien en door managers worden ze veelal als typisten gezien. Kijk maar eens op bijvoorbeeld de IBM site: ze praten alleen over Risk Management, Business Process Management, bla bla bla... Uiteindelijk bedoelen ze de software die ze verkopen.. maar de managers ( met weinig technische kennis ) beslissen en daarom dat geblaat.

Door Horemheb, donderdag 17 mei 2007 11:31

Score: 1
Ik mag hopen dat je als bedrijf je kandidaat programmeurs eerst een beetje ondervraagd / test om te kijken welk niveau ze hebben. Zo zorg je dat je enkel mensen aantrekt die weten wat ze doen, ongeacht hun diploma. Daar heb je geen licentie voor nodig.
Als je dan toch iemand zonder de gewenste capaciteiten aantrekt dan is dat volledig je eigen schuld en moet je de gevolgen maar dragen.

Door vbmot, donderdag 17 mei 2007 12:12

Score: 1
Als ik alle code die ik schrijf moet gaan valideren met formal methods als Promela en B dan vertrek ik morgen nog uit dit vak om hamburgers bij McDonalds te gaan bakken :P Bij kritieke systemen is het misschien nog wel aanvaardbaar, maar anders kost het vooral veel tijd en frustratie.

Door flowerp, donderdag 17 mei 2007 12:16

Score: 1
Ik mag hopen dat je als bedrijf je kandidaat programmeurs eerst een beetje ondervraagd / test om te kijken welk niveau ze hebben.
Geloof me, je wilt niet weten wat voor totale onbenullen je langs krijgt af en toe. Mensen die zich doodleuk Advanced Java Programmer noemen, en niet eens op papier 1 simpele class kunnen schrijven.

Ik kan daar nog steeds niet bij, de meest simpele, belachelijke vraag: schrijf een functie waarin je 2 getallen meegeeft en die als resultaat de som terug geeft.. Iets als int som(int a, int b) { return a+b; }; dus.

80% van de 'programmeurs' kan dit niet!!!

Sommige beginnen iets te stamelen van: "Ja, dan moet je uhhh, een applet zoeken, ja! Een applet die zoiets kan! en die moet dan op een of andere manier op een HTML pagina komen. Nee, ik zou niet zo weten hoe of welke applet, daar moet ik echt documentatie voor hebben." |:(

Helen dagen heb ik verspild aan nutteloze sollicitatie rondes. Eigenlijk wil je iemand na 2 minuten alweer wegsturen en zeggen dat ie totaal ongeschikt is, maar uit beleefdheid maak je toch maar even tenminste een half uurtje vol en zegt dat je later terug belt.

Ik geloof best dat er mensen zijn zonder papiertje die heel capabel zijn, maar vanwege bovenstaande ervaringen kijk ik het liefst naar iemand die goede papieren kan laten zien, zodat ik tenminste de garantie heb van een bepaald basis niveau.

Door tjerkw, vrijdag 18 mei 2007 13:07

Score: 0
Klopt nu kost het nog veel tijd,.. maar in de toekomst ( idealiter ) krijg je voordat je gaat compileren eerst een validatie check over je code. Deze geeft aan waar er fouten in de coden zitten en waar deadlocks voorkomen.

Dus nee dan kost het je geen extra tijd.

Door mashell, zaterdag 19 mei 2007 11:21

Score: 0
Zoiets kun je met Lint nu ook al, moet je alleen even je build process aanpassen. Maar het kost wel extra tijd (alle extra werk kost extra tijd), de je misschien later in de bugfixing fase wel 3x terug verdiend.

Door elteck, donderdag 17 mei 2007 13:02

Score: 0
Ik denk dat je het volgende wel kunt stellen:

De meeste bugs betreffen ongewenst gedrag van een programma dat zich in een onvoorziene toestand bevind.

M.a.w. de meeste programmas doen wel waar ze voor gemaakt zijn, maar de situaties waar ze niet voor gemaakt zijn, of die niet voorzien waren, daar doen de hardnekkigste/gevaarlijkste bugs zich voor.

Hoe "proffesioneel" iemand ook is, zeker bij complexere programmas is het (bijna) niet te doen om alle mogelijke situaties te overzien. Testen is volgens mij de enige manier om al die mogelijke problemen te vinden. Dus ja, investeren in testen en ontwikkelen van methoden om zo compleet mogelijk te testen, zijn noodzaak.

Door Floor, donderdag 17 mei 2007 13:20

Score: 0
Ik kan je betoog goed volgen en ik geloof best dat alles goed te onderbouwen is. Maar in je betoog heb je het over deadlines, economische haalbaarheid enz enz.

Het is juist de taak van de overheid om te zorgen dat er verantwoordelijkheidsgevoel ontstaat waardoor bijv. langere testtrajecten ontstaan.
Zo werkt de millieu problematiek in theorie ook (hoewel in de praktijk millieu = kostenbesparing vaak als enige motivator geldt). Om het tij te keren, minder werkdruk, beter testen enz enz kan alleen worden bereikt wanneer het economisch aantrekkelijk wordt. Wanneer dit alleen bereikt kan worden door bedrijven verantwoordelijk te maken software die men uitbrengt dan mag dit zeker aangekaart gaan worden. Wie anders? De klant die het pakket koopt? Ik ben van mening dat menig bedrijf te weinig verantwoordelijkheid neemt (nam) om software goed te testten alvorens te releasen.

Door hjkhlukgoug, donderdag 17 mei 2007 17:30

Score: 0
Ik ben het in grote lijnen wel met je eens. Overigens staat in het artikel al een fantastisch argument dat foutloze software ontzettend moeilijk te voorkomen is. De sonde die naar mars is gestuurd is namelijk ontwikkeld tegen kosten die ongeveer 100(!) keer hoger liggen dan gebruikelijk is bij software voor business toepassingen. Dat er dan nog steeds fouten worden gemaakt toont al aan dat fouten in software praktisch gezien nooit uitgesloten kunnen worden.

Door HellPunk, vrijdag 18 mei 2007 08:40

Score: 0
Fouten kan je nooit uitsluiten, maar je kan met een degelijk testtraject de kans op fouten wel zo klein mogelijk maken. De verantwoordelijkheid voor bugs mag niet louter en alleen bij de programmeurs liggen. Als je als manager je software niet laat testen, dan ben je fout bezig.

Door mad_dog, woensdag 16 mei 2007 21:00

Score: 1
Heel erg mooi dat zulke dingen eindelijk eens bespreekbaar worden gemaakt.

De prof van mijn afstudeerrichting (technischie informatica - information architecture - TUDelft) zegt altijd het volgende:

Als een gebouw/brug instort wegens een ontwerpfout dan breekt de hel los
Als een vliegtuig naar benden stort wegens een ontwerpfout dan breekt de hel los
Als een softwareproduct crasht is dit normaal.

Ik zou hier nu een betoog kunnen gaan houden dat software vrijwel foutloos kan worden geschreven (zoals mijn prof dat graag doet), maar ik ben bang dat dat niet overtuigend genoeg zal zijn...

Door Horemheb, woensdag 16 mei 2007 21:09

Score: 1
Software met zekerheid bugvrij maken is alles behalve eenvoudig. Jouw prof zal waarschijnlijk wel mooie theorien en methoden klaar hebben om de juistheid van een programma te verifieren. Maar tenzij je voor de NASA ofzo werk zal geen enkel bedrijf er ook maar aan denken om die dingen toe te passen.
Kost, en misschien nog belangrijker time-to-market zijn nu eenmaal een pak belangrijker dan volledig bugvrije software.

Door n4m3l355, donderdag 17 mei 2007 00:01

Score: 0
Ik vind dat een beetje frapant.. De analogie wat mad_dog aangeeft is vrij duidelijk er is geen ruimte voor fouten in de bouw-wereld of in de aviatie-wereld, daarintegen in de IT-wereld wordt het ge-accepteerd.
Ik wil niet zeggen dat in de bouwwereld geen fouten optreden, maar als er iets instort rollen er koppen en ben je financieel aansprakelijk. Als mijn windows ermee kapt, accepteer ik dit. Software producenten zouden net zo goed aansprakelijk moeten zijn voor verloren tijd. En tot op zekere hoogte is dit ook wel zo bij specialistische software, maar vaak genoeg accepteren we ook fouten die in software zit wat niet geheel terrecht is.
Ik snap wel dat goed ontwikkelde software tijd kost en dus ook geld. Maar met de marges die bijv MS erop na houdt is er ruimte genoeg om eens een beetje kwaliteit af te leveren en als MS van dit soort marges erop na houdt, zullen andere producenten dit net zo goed doen.

Door Parasietje, donderdag 17 mei 2007 01:56

Score: 1
Als jouw windows crasht, en je dit veel tijd kost, dan moet je migreren naar een stabieler operating system.

Het is doodsimpel: ben je bereid om meer te betalen voor betere stabiliteit? Ben je bereid om daar features voor op te offeren? In het geval van bruggen: ja, absoluut! In het geval van software lijken veel bedrijfsleiders het belang van stabiele software en hardware te onderschatten. High availibility cluster voor EUR 10.000? Nah, doe toch maar 1 enkele server voor EUR 2000.

Daar komt nog eens bij dat bruggenbouw niet zo snel evolueert. Bruggen worden gebouwd met jarenlange ervaring in die technieken. Analoog wordt bij de NASA nog steeds 8-bit processors uit 1980 gebruikt. Oude, bewezen technologie. Als jouw bedrijf de verloren tijd zo belangrijk vindt, gebruik dan WordPerfect 8.0 onder DOS. Een NetWare server, en HALLO STABILITEIT! Maar iedereen vindt features en vooruitgang belangrijker dan stabiliteit.

Door timonb, vrijdag 18 mei 2007 13:05

Score: 0
Wat je vergelijkt zijn appels en peren. Je kunt een vliegtuig, een brug en een stukje software op een computer niet vergelijken.

Bij de eerste twee kan een potentieele levensgevaarlijke situatie ontstaan. Als bijv. Windows crashed zat dat niet er toe leiden dat er een levensgevaarlijke situaties ontstaat!

Je zult dus een vergelijking moeten maken met software waarbij ook een potentieele levensgevaarlijke situatie kan ontstaan. Denk bijvoorbeeld aan de software in vliegtuigen of in de ruimtevaart. Daar worden geen bugs getollereerd! In de reguliere software worden deze wel getollereerd.

Door RedLizard, donderdag 17 mei 2007 00:26

Score: 1
Als de klant van de softwareontwikkelaar bereid is om consessies te doen aan te stabiliteit om zo de kosten/ontwikkeltijd laag te houden, waar heb je dan nog programmeurscertificaten voor nodig? Software KAN foutloos gemaakt worden als je daar om vraagt, alleen heeft niemand er het geld voor over. Blijkbaar nemen klanten genoegen met minder.

Door Def1ant, woensdag 16 mei 2007 21:18

Score: 1
Het is natuurlijk makkelijker om een brug veilig te maken, dan software 'bug' free :P

Met het eerste gelden zoveel veiligheidsfactoren, zoveel positieve afrondingen, dat je met bv 75% van het materiaal de brug net zo veilig in de praktijk kan gaan maken als met de 100%.

En zoals Horem zei, Kost, en misschien nog belangrijker time-to-market zijn nu eenmaal een pak belangrijker dan volledig bugvrije software. Klopt gehelemaal: immers kan je makkelijk een patch loslaten in een later stadium waardoor je product weer 'normaal' werkt.

Door Green.Velvet|IA, woensdag 16 mei 2007 21:21

Score: 0
Als een gebouw/brug instort wegens een ontwerpfout dan breekt de hel los
Als een vliegtuig naar benden stort wegens een ontwerpfout dan breekt de hel los
Als een softwareproduct crasht is dit normaal.
Ik stel me die vraag al jaren. Zowel voor specifieke software waarvan de klant soms vierkant de boom inkan als het moederbedrijf overkop gaat of weigert verantwoordelijkheid te nemen bij zware gevolgen van fouten, maar vooral voor software als Windows waarvan niemand weet hoeveel financiele schade het al veroorzaakt heeft wereldwijd door zijn onstabiliteit.

En nee dit is geen MS bashing, maar iedereen zal moeten toegeven dat MS software gekend is om vroeg of laat een keer onderuit te gaan, vaak met grote gevolgen voor bedrijven om de boel recht te trekken.

En ik begrijp al jaren niet dat MS daar ongestraft mee weg komt. Vooral als de fout gekend is, en ze er achteraf een patch voor maken. Dan zijn ze IMHO toch best schuldig aan de geleden schade veroorzaakt door die bug.

Door YaPP, woensdag 16 mei 2007 21:34

Score: 1
Ben het met je eens! De volgende quote hangt nog altijd in mijn hoofd: "in de ICT industrie kunnen dingen uitgehaald worden die in geen andere sector mogelijk zijn". Ik zal graag de bron ervan willen vinden.

In denk dat hier wel een kern van waarheid in zit. Vermoedelijk komt dit omdat bij ICT het product heel abstract is. Weinig mensen hebben er ook kennis van. Je kunt daardoor met slechte support een hoop mensen om de tuin leiden, en veel gebruikers accepteren het. Terwijl ze dat nergens anders zouden doen. :P

Door Wim-Bart, woensdag 16 mei 2007 21:43

Score: 1
En nee dit is geen MS bashing, maar iedereen zal moeten toegeven dat MS software gekend is om vroeg of laat een keer onderuit te gaan, vaak met grote gevolgen voor bedrijven om de boel recht te trekken.
Geen MS Bashen. Ik weet niet in welke eeuw je leeft, maar bij de juiste architectuur, ontwerp en bouw van een ICT infrastructuur (Alles behalve de applicaties) is sinds Windows 2000 SP4 een Windows omgeving stabiel te noemen.

Het probleem met instabiele Windows omgevingen ligt vrijwel nooit aan de Windows implementatie of het Windows OS, mits men natuurlijk rare zaken gaat doen en buiten de scope van wat door MS wordt ondersteund.

Verder liggen de meeste problemen vaak op hele andere niveau's, waaronder drivers, firmware van harddisks, raid controllers, san switches, systemen en andere componenten. Een ICT infrastuctuur is een keten van van producten waarbij de stabiliteit wordt bepaald door de zwakste schakel en dat is meestal niet het Microsoft Windows OS maar alles wat daaraan is gekoppeld op hardware en software niveau.

Veel zaken hangen af van de wijze van implementatie zoals door Infra-ontwerpers en bouwers wordt gedaan aan de hand van specs vastgesteld door de Infrastuctuur architecten. Daarnaast is de selectie van bijbehorende producten een grote invloedsfactor, een zelf samengestelde server zal nooit de stabiliteit bereiken die een professioneel apparaat zal hebben waar 100den uren resources in zitten en testen op los zijn gelaten inclusief de gecertificeerde onderdelen zoals kaarten, disks en andere zaken.

In de praktijk merk ik en mijn collega's dat de meeste oorzaken van instabile ICT omgevingen vaak ligt aan:
Verkeerde Oracle/SQL Server implementaties;
Instabiele SAN en Netwerk Componenten (Firmware en kabels);
Verkeerd of slordig geschreven applicaties;
Fout gesized SAN of netwerk (bijvoorbeeld gebruik van grotere SAN LUN's dan 500GB wat (on)officieel niet door MS wordt ondersteund).

Dus om Windows af te doen als instabiele factor is een grote uitspraak, overigens niet vergetend dat ook Windows zijn/haar nukken heeft en je meestal moet wachten op de eerste Service Pack. Maar dat geldt ook voor Firmware, drivers en applicaties.

Door Green.Velvet|IA, woensdag 16 mei 2007 22:06

Score: 0
OK, laten we de focus ruimer nemen zoals jij omschrijft en het hele arsenaal ICT apparatuur in zijn geheel als mogelijke oorzaak van een enorme breakdown nemen.

Heb jij OOIT al geweten dat als de oorzaak van de problemen gekend is, en het blijkt een ontwerp of productiefout te zijn, dat het bedrijf dat schade leed dit kan verhalen op de fabrikant van het ICT onderdeel ?

Gelijk het Windows is, een RAID controller, een reeks UPS'en, whatever....

Ik blijf het merkwaardig vinden...

Als een architekt een rekenfout maakt en er vallen doden nadat zijn ontwerp ineenstort, dan zal HIJ verantwoordelijk gesteld worden.

Blijkt echter dat die architekt geen fouten maakte, maar dat zijn ontwerp software iets foutief berekende, dan is er plots niemand meer 'verantwoordelijk'.

Ik begrijp die 'logica' al jaren niet.

Door worldcitizen, woensdag 16 mei 2007 23:52

Score: 1
@Wim-Bart en @Green.Velvet

Deze alleen @Green.Velvet
Heb jij OOIT al geweten dat als de oorzaak van de problemen gekend is, en het blijkt een ontwerp of productiefout te zijn, dat het bedrijf dat schade leed dit kan verhalen op de fabrikant van het ICT onderdeel ?

Nee dus, niet bij Microsoft je kunt hier alleen maximaal de prijs van de software terug krijgen, zie de license overeenkomst. (Onder)

Lees deze pdf eens.
http://download.microsoft...875-8153-889cf5105718.pdf
(Deze is er recent is nml van Vista).

Vooral deze passage:

<quote>
25. LIMITATION ON AND EXCLUSION OF DAMAGES. You can recover from Microsoft and its
suppliers only direct damages up to the amount you paid for the software. You cannot
recover any other damages, including consequential, lost profits, special, indirect or
incidental damages.
This limitation applies to
· anything related to the software, services, content (including code) on third party Internet sites,
or third party programs; and
· claims for breach of contract, breach of warranty, guarantee or condition, strict liability,
negligence, or other tort to the extent permitted by applicable law.
It also applies even if
· repair, replacement or a refund for the software does not fully compensate you for any losses; or
· Microsoft knew or should have known about the possibility of the damages.
Some states do not allow the exclusion or limitation of incidental or consequential damages, so the
above limitation or exclusion may not apply to you. They also may not apply to you because your
country may not allow the exclusion or limitation of incidental, consequential or other damages.
</quote>

Nog even eruit lichten:
25. LIMITATION ON AND EXCLUSION OF DAMAGES. You can recover from Microsoft and its
suppliers only direct damages up to the amount you paid for the software. You cannot
recover any other damages, including consequential, lost profits, special, indirect or
incidental damages.
<snip>
</snip>
It also applies even if
· repair, replacement or a refund for the software does not fully compensate you for any losses; or
· Microsoft knew or should have known about the possibility of the damages.

Kijk eens naar het bold stukje.

Dit is wat je accepteerd als je de license agreement accepteerd.

Door CodeCaster, donderdag 17 mei 2007 02:59

Score: 0
Het antwoord op je stelling staat boven je ook al omschreven.

Microsoft kan niet garanderen dat hun systeem (Windows) blijft draaien wanneer er brakke software op uitgevoerd wordt. Ook kunnen ze niet garanderen dat je door hardwarefouten geen gegevens verliest.

Garandeert jouw autofabrikant dat je auto blijft rijden als je door een kuil in de weg rijdt? Garandeert jouw autofabrikant dat je auto blijft rijden als je tegen een boom aan stuurt?

Door Kalief, donderdag 17 mei 2007 09:58

Score: 0
Blijkt echter dat die architekt geen fouten maakte, maar dat zijn ontwerp software iets foutief berekende, dan is er plots niemand meer 'verantwoordelijk'.

Kul. Het maakt een rechter niets uit op welke manier die architect de foute berekening maakte, uit zijn hoofd of met een computer. De architect is niet verantwoordelijk voor de foute software maar wel verantwoordelijk én aansprakelijk voor (het gebruik van) de foute uitkomst. De softwarebouwer is wel verantwoordelijk voor zijn foute software, maar slechts beperkt of niet aansprakelijk.

Door tjerkw, donderdag 17 mei 2007 11:01

Score: 0
Het gaat niet om het foutief berekenen van iets.. het gaat om fouten in de software die tot deadlocks of race conditions gaan. Of om fouten die bepaalde eigenschappen niet nakomen ( voorbeeld eigenschap: uiteindelijk zal het stoplicht op groen gaan staan ).

Dit is zeer moeilijk na te gaan met software die meerdere concurrente processen draaien die data delen.

Door Wim-Bart, vrijdag 18 mei 2007 04:17

Score: 0
@Green.Velvet:
Heb jij OOIT al geweten dat als de oorzaak van de problemen gekend is, en het blijkt een ontwerp of productiefout te zijn, dat het bedrijf dat schade leed dit kan verhalen op de fabrikant van het ICT onderdeel ?
Dat is het kromme van de situatie. Veel fabrikanten geven zogenaamde compatibility lijsten aan van soft/hardware implementaties maar proberen altijd onder de claims uit te komen als het fout gaat.

In mijn opinie is een fabrikant altijd aansprakelijk tot het e.o.l. van een product, zeg 5 jaar na levering. Als voorbeeld een harddisk, een klant kan er toch niks aan doen dat deze een verkeerde firmware had. Alleen zijn bedrijven zeer laks om gebruikers te informeren en te helpen. Hoe kleiner de klant hoe meer vuil je voor de fabrikanten bent.

Ik zou zo een 3-tal situaties kunnen noemen waarbij een fabrikant schuldig is aan problemen met de infrastructuur. Alleen kan ik dat nu niet omdat ik dan een aantal juridische processen kan beïnvloeden wat ik nu liever niet doe. Maar helaas is het zo dat vele fabrikanten hun verantwoording (willen) ontlopen en alleen maar denken aan de kosten en aandeelhouders waardoor je als klant gewoon aan de kant staat.

Microsoft is wat dat betreft één betere uitzonderingen, die zeggen gewoon dat er een bug is, brengen binnen een korte of lange tijd een fix uit en dan is het weer opgelost. Een aantal andere niet nader te benoemen (hardware) fabrikanten echter worden pas wakker als ze opeens de inkoop van een overheidsbedrijf aan de telefoon krijgen en er over mogelijke claims wordt gesproken. Dan kunnen ze opeens wel rennen.

Door Horemheb, woensdag 16 mei 2007 22:43

Score: 1
Als een architekt een rekenfout maakt en er vallen doden nadat zijn ontwerp ineenstort, dan zal HIJ verantwoordelijk gesteld worden.

Blijkt echter dat die architekt geen fouten maakte, maar dat zijn ontwerp software iets foutief berekende, dan is er plots niemand meer 'verantwoordelijk'.

Ik begrijp die 'logica' al jaren niet.
Heel simpel als je software koopt dan zit daar een licentie bij. In die licentie staat dat het bedrijf achter de software niet aansprakelijk is voor dit soort schade.
Als je echt de leverancier hiervoor verantwoordelijk wil houden dan wil je gaan naar een wereld waar een licentie op office 25.000 euro ofzo kost.

Door flowerp, woensdag 16 mei 2007 23:20

Score: 1
Als je echt de leverancier hiervoor verantwoordelijk wil houden dan wil je gaan naar een wereld waar een licentie op office 25.000 euro ofzo kost.
Toch kost bijvoorbeeld een (complex) stuk speelgoed, wat onder alle omstandigheden veilig moet zijn voor kinderen, ook niet 25.000. Ondanks dat er daar wel degelijk zeer strenge regels voor gelden.

Misschien moeten we eens wat meer aansturen op een wereld waarin Office niet 10.000 features heeft, maar slechts 1000 die wel allemaal echt stabiel werken.

Door maartsen, woensdag 16 mei 2007 21:21

Score: 2
Ik vind je prof wel erg kort door de bocht.
Bruggen bouwen we al duizenden jaren en zelf dan storten nu nog bruggen in.
Vliegtuigen bouwen we al 90 jaar en nog storten ze neer.

Nu ontwikkelen we software pas een jaar of 40. Van die 40 jaar komt er elke 5 jaar wel een nieuwe tool uit. Bij bruggen is de laatste ontwikkeling al zeker 150 jaar uit en de eerste straaljagers waren ook niet de meest betrouwbare. Elke nieuwe tool moet opnieuw worden aangeleerd (leerproces dus problemen en bugs).

Daarnaast kan ik als ongetraind persoon zo een experimenteel vliegtuig. Wie gaat me tegenhouden??

Trouwens is certificering een garantie voor beter personeel?? Het bekende verschil tussen theorie en praktijk.

Door Mic2000, donderdag 17 mei 2007 00:08

Score: 0
Ik ben het helemaal met je eens! Je kan niet iets nieuws uitvinden als je nooit fouten maakt(praktisch gezien). De beste uitvinden komen door kronkels in het leven, dingen die je liever anders zou willen hebben. Dus van dit andere perspectief ben ik het er mee eens dat die prof niet gelijk heeft.

Door J.J.J. Bokma, woensdag 16 mei 2007 21:22

Score: 1
Clueloze prof dan. Een brug is geen stuk software.

- slijt software door veel gebruik? Nee
- kan je een brug copieeren met minimale kosten?
- kan je een brug on the fly updaten?

Goh, er is heel wat mis in de bouwwereld dan, misschien kan je prof eens na gaan denken, samen met Trouw, over regeltjes in de bouw.

Tenslotte, als een vliegtuig naar beneden stort door een softwarefout breekt ook de hel los.

Door fevenhuis, woensdag 16 mei 2007 21:50

Score: 0
Software "slijt" door OS veranderingen (patches/service packs) en installaties andere (evt. vergelijkbare) software en hardware/driver veranderingen.

Door tjerkw, donderdag 17 mei 2007 11:08

Score: 0
Er zijn veel analogien tussen de bouwkunde en de informatica. (kort samengevat) Beide beginnen met een probleem. vervolgens doe je requirements analyse. En op het eind kom je met een product dat voldoet aan je requirements.

Of het nu een fysiek ding is ( een brug )
Of een complex software systeem.

De basis is hetzelfde.

Het probleem is alleen dat in de Bouwkunde zeer goede regels en theorien zijn waardoor ze het bijna foutloos kunnen maken. In de informatica zijn deze theorien nog in de maak.
Denk bijvoorbeeld aan 'System validation' en andere formele methoden. Aan mijn universiteit zijn hele vakgroepen bezig met onderzoek naar deze problemen.
En ik moet zeggen, ze kunnen nu al een model van een software systeem maken waarme ze kunnen bepalen of er deadlocks of property violations voordoen. Niet slecht al zeg ik het zelf.

Door tjerkw, donderdag 17 mei 2007 11:14

Score: 0
Het gaat hier om de correcte ontwikkeling van een product.. niet het uiteindelijke product zelf.

Als je kijkt naar de ontwikkeling van een brug en een stuk software vindt je veel overeenkomsten.

( Ik had nog meer getypt maar die tweakers.net reactie werkt niet altijd even goed.. opeens was alles weg! )

Door flowerp, woensdag 16 mei 2007 21:26

Score: 2
Als een softwareproduct crasht is dit normaal.
Inderdaad, het geeft de grote onvolwassenheid van deze industrie aan. Als ik (als developer) zie hoe laks men software bouwt, dan is het eigenlijk een zeer groot wonder dat software nog zo stabiel is als het momenteel is.

Als lead programmer is 1 van mijn taken het bewaken van de kwaliteit van sourcecode, maar het is vaak dweilen met de kraan open. Bekende good practices worden keer op keer genegeerd, en als je er wat van zegt dan kijkt men je negen van de tien keer aan alsof je de grootste zeur bent. Simpele voorbeelden ten over.

Deze week nog; in een Java project schrijft een programmeur code die over een collection itereerd. Deze is shared tussen threads. Tijdens deze iteratie kan een andere thread er wat in schrijven. Volgens de API mag er tijdens een iteratie geen 'structural modification' plaatsvinden. Ik zie dit, loop naar de persoon toe en zeg dat dat niet mag. Krijg ik een grote mond terug en wordt er gezegd dat het allemaal niet zo erg is, dat het in 99% van de gevallen wel goed gaat en dat die 1% toch niet voorkomt in de praktijk. |:(

Door Eric Oud Ammerveld, woensdag 16 mei 2007 21:38

Score: 0
@flowerp

Wat betreft zulke geintjes als een iteratie tussentijds (extern; buiten de functie tak) beinvloeden.
Zo'n programmeur moeten ze het toetsenbord ontnemen.

Als programmeur moet je altijd zorgen dat je een reproduceerbare situatie creeert die in geen enkele vorm afhankelijk mag zijn van een evt. uitzonderings aanroep zoals ik begrijp uit jou verhaal.

Het rotzooien in een iteratie is gevaarlijk, zeker als het de structuur van de iteratie zelf betreft.

De kracht van een iteratie zit hem in de herhaling welke na compilatie door de CPU zeer snel kan worden afgehandeld. Het runtime aanpassen van een iteratiestructuur is vragen om problemen.

De kern van een iteratie is dat deze (net als database transacties) serializeerbaar moet zijn.

Dit is vergelijkbaar met het gebruiken van een globale variabele in een iteratie die afhankelijk kan zijn van de iteratie zelf en waarmee de uitkomst afhankelijk wordt van de CPU kracht en het moment dat een iteratie ingegaan wordt. In een woord smerig.
Als de uitvoering van meerdere parallelle processen van deze iteratie "toevallig" (kwestie van tijd) samenvalt krijg je de gekste dingen.

Door Mr_Light, woensdag 16 mei 2007 21:50

Score: 0
Wat eric hierboven zegt vond ik te offtopic.
[toevoeging1]
in de zit dat we wel heel specifiek over een probleem gaan inzoomen wat een beetje het accent wegneemt.
[/toevoeging1]]

Als jij lead developer bent maar geen mandaad krijgt is het tijd om op te stappen. (het is simpel om te zeggen ik weet het)
[toevoeging1]
Het management (waar in mijn ogen de lead developer onder valt, maar de praktijk wil nog wel eens anders zijn) moet de lead developer in zijn taken ondersteunen, als deze een slechte beoordeling geeft mag daar best wat mee gedaan worden.

mentaliteit laat zich vaak beïnvloeden door dingen met impact, als je zegt dat i anders morgen wel thuis kan blijven lost het zich meestal snel op.
[/toevoeging1]]

feit is wel dat je het werk zo onmogelijk gemaakt word en dat het probleem zelf niet echt met code te maken heeft.

Het proces zal onafhankelijk van de wel of niet hebben van een goede mentaliteit, door duidelijk aan te geven waar iedereen staat en wat er van hem verwacht word (ok, indirect word er dus een bepaalde mentaliteit worden verwacht) lost het zich vanzelf op.

te minste dat is mijn ervaring.

@eric zou je "Dat je iets kan programmeren op een manier die je in gedachten hebt betekent lang niet altijd dat deze manier de correcte manier is." voor mij iets verder kunnen toelichten?

Door Eric Oud Ammerveld, woensdag 16 mei 2007 22:04

Score: 0
@ Mr_Light

Dat je iets kan programmeren op een manier die je in gedachten hebt betekent lang niet altijd dat deze manier de correcte manier is.

Wanneer een mede programmeur (of dit nu een lead programmeur is of niet) dit opvalt en je hier op aanspreekt moet je programmeur genoeg zijn om je eigen fout toe te kunnen geven dan wel een verklaring te vragen als je niet snapt wat je collega bedoelt.

Ik ben het absoluut met je eens dat dit meer een mentaliteit probleem is dan een softwarematig probleem en een dergelijke mentaliteit moet je als lead programmeur hard aanpakken om de applicatie en code die wordt opgeleverd zo schoon en correct mogelijk te houden.

Wat betreft het off-topic punt; ik denk dat deze situaties juist aangeven hoe belangrijk een controle op de programmeur is en hoe belangrijk het is als programmeur te luisteren naar anderen om je applicatie zo stabiel en robuust mogelijk te maken.

[toevoeging]
@ Mr_light

Als reactie op je verzoek om toelichting:
Er zijn meerdere wegen die leiden naar rome.
Als programmeur is het van belang om tijdens het programmeren te zorgen voor zo gunstig mogelijke condities voor het systeem waar je op programmeert gezien dit te allen tijde in je voordeel zal werken.

Zaken die hierbij o.a. komen kijken zijn:
1. Systeembronnen (CPU kracht; gebruik van CPU registers en aangepaste instructies voor je hardware; gebruik bijv. van intern geheugen en harddisk rekening houdend met bijkomende performance aspecten als seektimes e.d.)
2. Veiligheid en robuustheid (basale functies hebben het meeste baat bij correcte afhandel