Oproep tot 'professionalisering' programmeursberoep

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.

Reacties (233)

[mad_dog]

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...

[flowerp]

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.

[J.J.J. Bokma]

"Als lead programmer "

Ah, dus nog nooit iets in de constructie gedaan? Ik ook niet hoor, maar ik weet er wel genoeg vanaf dat daar ook regelmatig op een gelijke wijze aangekloot word.

Alleen als je bij een brug een schroefje vergeet, gaat dat nog meestal prima (zelfs als je de helft vergeet), veel wordt overgedimensioneerd. Bij software gaat alles over een executiepad. Er is dan vaak geen redundantie. Verder werkt het binair en niet analoog. Je hebt dus niet dat iets langzaam uit elkaar valt (zoals bij constructies in de bouw), maar dat iets gewoon wel of niet werkt. Er is geen tussenweg.

Wat mij verbaasd (eigenlijk niet), is dat hier bakken met programmeurs (of "programmeurs") hun visie geven zonder deze simpele dingen zelf in te zien. Wellicht is dat een belangrijk om naar te kijken. Fouten worden nl. ook gemaakt door je eigen vak niet snappen.

Ik bedoel, heeft iemand de auto al uit de kast getrokken (de klassieke "analogie")?

[flowerp]

Fouten worden nl. ook gemaakt door je eigen vak niet snappen.

Dat, en gewoon geen liefde voor je vak hebben. Om dan maar met een leuke analogie te komen; daarnet was het programma van de smaakpolitie op TV. In zekere zin lijkt dat wel een beetje op de toestanden in de software industrie. Sommige mensen lappen gewoon elke regel aan hun laars in de keuken en doen maar wat, terwijl in andere keukens echt alles tot in de puntjes geregeld is.

Wat dit betreft heeft de keuken een beetje het zelfde probleem als de software. De klant kijkt niet mee in de keuken en het geleverde product ziet er op het eerste oog het zelfde uit. Zo kan men in de vieze keuken veel geld en tijd besparen en toch hetzelfde voor de maaltijd vragen.

Wordt er eens iemand echt ziek of komt er een officiële inspectie, dan heb je als beunhaas natuurlijk wel een probleem. Men gokt er dan op dat er toch bijna nooit iemand ziek wordt (ondanks onhygiënisch werken) en als het gebeurd dat ze dan niet de link naar jou leggen. Men neemt het risico dus voor lief.

Een serieus vakman verlaagt zich natuurlijk niet tot zulke praktijken, maar klaarblijkelijk is niet iedereen een vakman.

Vergelijk dit met de software industrie; men gokt er ook op dat de slecht geprogrammeerde randgevallen in de praktijk niet voorkomen en als het gebeurd dat men dan niet de link naar jou ligt (het was het netwerk, u heeft een virus, het is de schuld van Linux, etc). Ook hier laat een developer met liefde voor het vak het uit principe niet zo ver komen.

Het verschil is dat de keuken wel inspecties en regels heeft, maar de software industrie dit niet heeft. Ook lijkt het niet bekommeren om kwaliteit meer de norm dan de uitzondering hier.

[Eric Oud Ammerveld]

@ J.J.J. Bokma

100% mijn mening.

Als je programmeert is het je taak een executiepad te verzorgen waar niet van kan worden afgeweken.
Daarnaast indien in je programma op de een of andere manier toch van dit pad wordt afgeweken moet je in de code proberen een correcte afhandeling hiervoor te verzorgen en voldoende te loggen om de situatie te recreeren en evt. in een later stadium onderdeel van het executiepad te laten zijn.

Als je half programmeert lever je half werk.

[Mr_Light]

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?

[flowerp]

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)

Klopt, dat is inderdaad niet zo makkelijk en daarnaast hou ik ook niet zo van opgeven.

Als lead developer schipper ik wat dit punt betreft (code kwaliteit bewaking) tussen een team van programmeurs en een team van managers/commerciele mensen. Van de hoofd verantwoordelijke manager ben ik aangewezen om de kwaliteit van de code enigszins te bewaken, maar ik moet dat wel kunnen verantwoorden.

Af en toe is het dus inderdaad een lastige taak; van het management mag ik niet te veel uren in de kwaliteit bewaking laten stoppen en sommige programmeurs willen het liefst alleen code kloppen en nergens over nadenken. Als er wettelijke regels waren EN controles hierop (wat nu in de praktijk heel lastig is, maar stel dat dit kon), dan zou mijn werk een stuk makkelijker zijn, daar ik mensen er dan op kan wijzen dat de kwaliteitseisen niet mijn 'gezeur' zijn, maar wettelijk verplicht is.

Gelukkig is overigens niet elke developer zo als bovengenoemd geval. Er zitten ook zeker mensen bij die juist blij zijn dat ze van een 'ervaren' developer hints en tips krijgen over hoe ze hun source code kunnen verbeteren.

Eigenlijk zou ik de paar rotte appels er gewoon uit willen gooien, maar met het huidige tekort aan (java) developers is dat gewoon geen optie, zelfs al zou ik daar de bevoegdheid voor hebben.

[flowerp]

Ik ben het absoluut met je eens dat dit meer een mentaliteit probleem is dan een softwarematig probleem

Het is inderdaad een mentaliteits probleem. Sommige mensen zijn netjes, andere mensen zijn slorig. Het voorbeeld over de iteratie was een puur technische issue, waar de developer in kwestie wellicht gewoon niet op de hoogte van was (voor iemand die al 6 jaren met zijn vak bezig is vind ik dat wel heel slecht, maar dat terzijde).

Wat ik echter met grote regelmaat tegenkom is ook gewoon pure slordigheid en onverschilligheid. Complete classes worden copy-pasted, waarbij her en der dingen worden veranderd. Echter, alle comments van de oude class laten ze gewoon staan, en complete methods die in z'n geheel niet meer van toepassing zijn, laten ze ook staan.

Ook hier kan je vaak weer typische reacties verwachten; men stelt dat al die overbodige code toch geen kwaad kan omdat het niet wordt aangeroepen. Ze vergeten echter dat het maintenance zoals bug fixing en uitbreiding zeer veel moeilijker maakt.

Toevallig ook nog recent dit laatste zelf meegemaakt; voor een refactoring was het nodig om een flink stuk code aan te passen. Tijdens een meeting doe ik verslag hiervan, waarbij een andere programmeur z'n hand opsteekt en doodleuk zegt dat ik al die code niet had aan hoeven te passen, want die wordt toch niet meer gebruikt. (en nee, het van te voren controleren of elke regel en elke functie nog wel gebruikt wordt is bijna onbegonnen werk).

[Verwijderd]

Wat ik echter met grote regelmaat tegenkom is ook gewoon pure slordigheid en onverschilligheid. Complete classes worden copy-pasted, waarbij her en der dingen worden veranderd. Echter, alle comments van de oude class laten ze gewoon staan, en complete methods die in z'n geheel niet meer van toepassing zijn, laten ze ook staan.

Flowerp:

Even op antwoorden als zo een programmeur. Het is allemaal goed & wel om mooie, code te schrijven maar pvd! laat ons wel de tijd om deze zo mooi & deftig te schrijven.

Ik zie het ieder dag op mijn werk. Presteren, presteren, presteren. De projecten moeten vooruit gaan, de klanten staan aan te schuiven, en men brengt sneller klanten & nieuwe projecten aan, dan dat we kunnen volgen. Wat is het effect denk je? Idd, copy posten, bugs, slordigheden, etc. Zeker als je al op een 5 jaar oud framework werkt dat non stop gegroeid is, zonder een herevaluatie / hercodering.

En dan is de baas boos omdat hij klanten krijgt van de klanten ivm de bugs. Dit terwijl de programmeurs zelf vragende partij zijn van geld voor meer mensen ( onderbezet ivm de workload ), deftigere hardware ipv 4 jaar oude brol, en nog van die toestanden. En ja, zelf een Project Leider, de laaste hebben ze buitengesmeten, en nooit vergangen... *ieeeee*.

Hell, ik zou enorm blij zijn als de workload met 50% zakt, zodat men meer tijd heeft voor de actuale analyse, deftige coderen, rekening kunnen houden met eventuele conflicten, en deftige tests. Maar dat zien de bazen niet zo graag. Wat ze graag zien is ieder module die afgewerkt wordt, want iedere module, of aanpassing = $$$ in de kassa. En voor de loon moet je het niet doen, denk dat een kuisvrouw nog meer betaald word ;-)

Hell, we hebben al genoeg punten aangebracht om deze toestanden te verbeteren, maar het mes snijd langs 2 kanten he. Het zijn vaak niet de programmeurs, maar jammer genoeg de directie, die het nut niet inzien van investeringen, meer personeel, etc. Dat kost geld, en ja ... Maar de problemen geraken zo niet opgelost. En zijn de bazen verbaast ( en kwaad ) als af & toe de programmeurs rebelleren van frustraties, overdruk etc.

Zo een regels kan men proberen in te voeren... En wie gaat dat controleren? En jammer genoeg is programma a, niet programma b. Ofwel zijn de regels zo globaal, dat ze weinig nut hebben, ofwel specifiek, maar dan moet men regels voor enorm veel programmatische situaties. Fat chance...

[flowerp]

Je zou geautomatiseerde code-checking tools kunnen invoeren. Volgens mij is er op dit gebied voor Java al wel wat te krijgen.

Checkstyle: http://eclipse-cs.sourceforge.net/screen_shots.html

[flowerp]

Even op antwoorden als zo een programmeur. Het is allemaal goed & wel om mooie, code te schrijven maar pvd! laat ons wel de tijd om deze zo mooi & deftig te schrijven.

Als lead programmer ben ik naast dat 'lead' natuurlijk ook 'programmer'. Een niet gering gedeelte van mijn werkzaamheden is ook gewoon programmeren. Natuurlijk copy-paste ik ook af en toe een class en pas deze aan, maar daarbij heb ik wel het fatsoen om ook even de comments aan te passen en de niet van toepassing zijnde code weg te halen.

We hebben het hier niet over uren werk, maar eerder over minuten. Als het mij zelf lukt om mijn eigen tickets af te krijgen, waarbij ik wel alles netjes probeer te doen, -en- nog eens de code van mijn teamgenoten in de gaten hou, dan mag ik toch wel verwachten dat die anderen ook wat moeite doen?

Sterker nog, doordat ik zelf netjes werk, ben ik in veel gevallen sneller met aanpassingen en bug fixes (die natuurlijk ook in mijn code voorkomen).

Als ik naar het werk van enkele teamgenoten kijk kan ik wel huilen; een brei spaghetti omdat ze uit zichzelf nooit iets refactoren. Bij aanpassingen in code laten enkele personen 9 van de 10 keer alle oude code staan. 2 a 3 van die gevallen pik ik er dan nog tussen uit met mijn controles, maar dan staat er nog steeds -veel- rotzooi.

Jij komt nu wel leuk met het argument dat netjes code je tijd kost, maar je bezit waarschijnlijk nog niet het inzicht om te begrijpen dat dat je op de langere termijn juist tijdwinst gaat opleveren.

Als ik in een stuk code waar ik een messcherp design voor heb kunnen maken iets moet veranderen, dan is dat in de regel zo gebeurd. Een zeer consequente scheiding van verantwoordelijkheden en technieken als proxies of plug-ins met strakke interfaces zorgen daarvoor.

Vergelijk dat met de code van die enkele genoemde collega's. Alles is van elkaar afhankelijk. Een class van tegen de 2500 regels, met 100 data members, waarbij alles elkaar beïnvloed is heel gewoon. Tel daar nog eens bij op dat ze key concepts in werkelijk elke andere functie een andere naam geven, en het wordt heel moeilijk om snel iets gedaan te krijgen. In dergelijke code is zelfs het simpelweg aanroepen van 1 functie al een hels karwei; vanwege al die afhankelijkheden moeten er eerst 10 data member gezet worden en 2 andere functies op het object worden aangeroepen. Dat dit gedaan moet worden staat dan natuurlijk weer op geen enkele wijze gedocumenteerd en blijkt ook uit geen enkele wijze uit de code zelf.

Logisch dat jij geen tijd hebt als je ook zulke code blijft schrijven!

[Verwijderd]

Jij komt nu wel leuk met het argument dat netjes code je tijd kost, maar je bezit waarschijnlijk nog niet het inzicht om te begrijpen dat dat je op de langere termijn juist tijdwinst gaat opleveren.

Flowerp, aub herlees wat ik schrijf. Dat is exact wat ik schrijf. Men moet ons programmeurs de tijd laten om het deftig te doen, en idd, dan spaart het tijd uit in de toekomst.

Maar effe zeggen dat ik niet het inzicht heb, hello man. Ik ben juist de grootste voorstander van gestructureerd te werken, met deftige tickets, support, hardware etc. Maar al te vaak stoot je op de management. Ze willen maximale productie, maar vaak zien ze niet in, dat deftige maximale productie geld kost.

Als het aan mij lag, zou gans de code basis herschreven worden. Ben je maanden aan bezig, maar uiteindelijk spaar je deze tijd in de toekomst uit, en win je erop met minder bugs, duidelijker, sneller ( performance ), en sneller ( implementeren nieuw code ), meer future proof.

En sorry als ik het zeg, maar volgens mij mag je nog met geluk spreken van uw codebasis. Dit framework waaraan we werken heeft een zeer beperkt aantal class'en, wat wil je, dit ding is 5 jaar oud, geschreven op een programmeer taal versie waarvan de release intussen ouder dan dat is. En dan stoten we nog op de nodige bugs in de programmeer taal zelf, maar deze upgraden eq trouble, zodus het wordt niet gedaan.

Tust me, de wil is er, maar men moet ook meewerken van boven af.

Maar flowerp, ik zie duidelijk aan je posting één probleem dat hier ook aanwezig was. Communicatie. Je gaf het perfecte voorbeeld zelf, met de rewritten code tijdens de vergadering, die niet meer gebruikt word. Zo een zaken komen gewoon van een slechte communicatie. Daar proberen we intussen al wat structuur in te krijgen. Maar zo een taak is normaal die van de Lead programmeur of Project beheerder hoor.

Je kan veel in de schoenen schuiven van je programmeurs, maar bij nieuwe taken diene zo een zaken eerst afgechecked te worden bij de mede programmeurs, die mogelijk meer kennis hebben over dat deel van de code.

Ik zie het ook vaak, de ene persoon weet meer af dan de andere persoon over de interactie, de gebruikte velden, etc. En als je dat niet navraagt, idd, dan heb je zo een fladders voor.En dat is ook vaak een punt, dat leid tot bugs of nutteloos werk.

Als iemand echt slordig werk blijft leveren, spreek die persoon erover aan. Misschien is die persoon meer geschikt & is hij gelukkig met misschien analyses te maken, of andere taken. En soms moet je op mensen hun tenen trappen. En dan heb je 2 gevolgen, de persoon herpakt zich, of het leid tot een conflict.

Maar al te vaak moet er van boven uit een deftig beleid gegeven worden, en dan zullen de mis toestanden ook makkelijker opgelost geraken.

[Eric Oud Ammerveld]

@ 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 afhandeling en exception handling; gebruik niet meer dan je nodig hebt; denk aan het gebruik van globale variabelen)
3. Hergebruik van code (Een modulaire opbouw van je code zorgt ervoor dat je code herbruikbaar wordt en overzichtelijk blijft)

Wanneer je programmeert in een taal die je niet volledig beheerst zul je de tijd moeten vinden om de capaciteiten van deze taal te kennen, zodat je weet wanneer je iets zelf moet programmeren of van de beschikbare (geoptimaliseerde) functies gebruik maakt.

Zo kan je, wanneer je je doel wilt bereiken met behulp van de daarvoor aangeschreven functies van de betreffende taal, bepalen of je de boeken in moet of dat je zelf deze functies moet schrijven.

Indien je een CASE statement bijvoorbeeld niet zou kennen zou je gebruik kunnen maken van een hele lading IF - ELSE constructies.
Als programmeur moet je de voor en nadelen van beide kennen en weten wanneer je welke kiest en er moet een lampje gaan branden wanneer je iets wil gaan bouwen dat mogelijk al bestaat.
[/toevoeging]

[Verwijderd]

Je zou geautomatiseerde code-checking tools kunnen invoeren. Volgens mij is er op dit gebied voor Java al wel wat te krijgen. Maar goed, zoiets werkt meestal alleen als het management erachter staat.

[Verwijderd]

Tijdens een meeting doe ik verslag hiervan, waarbij een andere programmeur z'n hand opsteekt en doodleuk zegt dat ik al die code niet had aan hoeven te passen, want die wordt toch niet meer gebruikt. (en nee, het van te voren controleren of elke regel en elke functie nog wel gebruikt wordt is bijna onbegonnen werk).

Commentarieer die code uit en kijk of het project nog compileert.

[flowerp]

Commentarieer die code uit en kijk of het project nog compileert.

Grapjas, ik kan toch niet op een code base van >500.000 regels willekeurige dingen gaan uit commenten om te zien of ze nog gebruikt worden? Deels kan ik dergelijke 'simpele' dingen al automatisch of semi-automatisch doen (b.v. "open call hierarchy" op een method en dan de tree volgen).

Daarnaast is het ook niet altijd zo simpel. Dikwijls kom ik van deze constructies tegen (even sterk versimpeld):

if ( situation == a ) {
// lots of code 1
}
else {
// lots of code 2
}

Technisch gezien is deze code niet dood, waardoor er geen automatische of semi-automatische test is die dit pakt. Ik ga dan ook gewoon het code 1 blok mee refactoren. Later blijkt dan dat situatie a alleen kan voorkomen als in de DB in tabel X, column Y een 5 voorkomt, MAAR dat er ergens al andere code is die zorgt dat er nooit een 5 daar kan voorkomen. Die andere code kan een DB constraint zijn, maar misschien ook een scriptlet op een JSP pagina, of whatever.

Punt is, ik kan dat niet snel nagaan. Als ik bij refactoren voor ELKE conditie moet checken waar die afhankelijk van is, en waar die weer afhankelijk van is, etc, dan ben ik voor de simpelste refactoring operaties weken bezig.

Als dit voor 1 of 2 situaties zou gelden, dan was het nog te doen. Maar spreek je over 100 situaties, met elke 10 afhankelijkheden die gemiddeld ook 10 levels diep gaan en verschillende problem domains door kruisen, dan zit je met een op z'n minst vervelende situatie.

Bij het refactoren is het uitgangs punt dat de betekenis van de code hetzelfde blijft. Als daar die check staat, en code 1 overduidelijk live is, en er zelfs unit testen zijn die hierop controleren, dan zou ik er zonder meer vanuit moeten gaan dat die code in gebruik is.

Het ligt bijna tegen het onbeschofte aan dat de programmeur die die eerdere verandering heeft gemaakt, dit niet opgeruimd heeft. Hij zadelt mij EN andere programmeurs die in dit stukje code moeten werken met heel veel extra werk op, alleen omdat ie te lui was om dit zelf even weg te halen.

[flowerp]

Flowerp, aub herlees wat ik schrijf. Dat is exact wat ik schrijf. Men moet ons programmeurs de tijd laten om het deftig te doen, en idd, dan spaart het tijd uit in de toekomst.

Dikwijls moet je die tijd gewoon pakken. Laat je niet (te veel) opjagen, maar werk de dingen af op een redelijk correcte manier. Vergeet niet dat de pure manager helemaal geen idee heeft hoeveel tijd iets kost. Die roept maar wat. Ga jij daar telkens in mee, dan bevestig je daarmee haar of zijn totaal onrealistische tijd schatting.

Een en ander hangt natuurlijk wel af van je mede team genoten. Als de andere team genoten er net zo als jij over denken, dan zou je eigenlijk op rozen moeten zitten. Laat de manager maar komen met die 10 requirements per persoon die in 1 week af moeten. Accepteer ze, ga er aan werken, en zeg op het eind van de week met een stalen gezicht dat je er 3 af hebt.

De manager zal nu misschien beginnen te razen, maar als de andere programmeurs het net zo gedaan hebben, dan zal de manager de volgende keer al het aantal requirements omlaag schroeven. Hij of zij kan wel weer met 10 komen, maar als iedereen er consequent in de orde van 3 maakt, dan moet die persoon wel heel veel boter op 't hoofd hebben als er elke keer 10 requirements blijven komen.

Als je andere teamgenoten echter allemaal liever sloppy willen coden, dan heb je wel een probleem. In je eentje win je zoiets eigenlijk nooit, hoe sterk je ook in je schoenen staat.

Zijn er een paar andere teamgenoten die geheel of matig geïnteresseerd zijn in betere kwaliteit code, dan begint een politiek steekspel van zieltjes winnen en voorzichtige schijnbewegingen maken. Het zou eigenlijk niet zo moeten zijn voor een programmeur, maar werken in een corporate omgeving brengt natuurlijk ook een zeker politiek element met zich mee.

Hoeveel tijd en energie je hier in wilt stoppen is natuurlijk jouw zaak. Vergeet niet dat het om je eigen werkomstandigheden gaat. Wil jij gestrest werken en elke dag met hoofdpijn thuis komen omdat de code base een puinhoop is, of kom je voor jezelf op en eist verbetering?

Speel ook niet alleen de zielepiet die voor zichzelf betere code wil. Bij elke bug in het systeem, bij alles wat er fout gaat, moet je de slechte staat van de source code de schuld geven. Keer op keer. Als je dit goed speelt zal de manager op een gegeven moment, soms bijna onbewust, slechte/sloppy code associëren met bugs.

Kijk heel kritisch als de manager iets 'gisteren' gedaan wil hebben en zeg dat je het wel kunt doen, maar dat het dan wel een 'hack' is. Geef de manager de keuze; een hack die gisteren klaar is, of een solide implementatie die morgen klaar. Je zadelt nu de manager direct met de verantwoording op om slechte code af te leveren. Gaat er later iets (wat dan ook) fout, zeg dan dat het door die hack komt. Jij zelf en je teamgenoten zijn dan bijna automatisch gevrijwaard van de problemen die ontstaan zijn door de fout, het was namelijk de manager zelf die koos voor die hack.

Na verloop van tijd zie je een psychologisch effect op treden dat een manager liever niet meer voor hacks zal kiezen. Pas natuurlijk wel op dat je de term 'hack' niet te veel gebruikt want dan schiet het z'n doel voorbij. Maar een uitgekiend gebruik ervan kan zeker enorm bijdragen.

De strekking van het artikel klopt dus wel in zekere zin; uiteindelijk ligt het bij de programmeur. Die moet tijd en kwaliteit eisen. De manager die geen regel code kan lezen zal deze tijd nooit automatisch geven als de programmeur dit niet kenbaar maakt.

[Verwijderd]

De strekking van het artikel klopt dus wel in zekere zin; uiteindelijk ligt het bij de programmeur. Die moet tijd en kwaliteit eisen. De manager die geen regel code kan lezen zal deze tijd nooit automatisch geven als de programmeur dit niet kenbaar maakt.

Ik heb dit soort dingen ook wel eens meegemaakt.

In het begin moesten de teamleiders vechten om genoeg tijd en mensen te krijgen. Code opschonen en documentatie maken deed je maar later.

Er was elk half jaar wel een grote crisismeeting in het auditorium. Want het product kon niet op tijd opgeleverd worden of er zaten nog te veel problemen in.

Toen ik er weg ging, was het helemaal naar de andere kant doorgeschoten. Groepsleiders moesten elke wijziging aftekenen en checken dat de review van de code en het design was goedgekeurd.

[flowerp]

Toen ik er weg ging, was het helemaal naar de andere kant doorgeschoten. Groepsleiders moesten elke wijziging aftekenen en checken dat de review van de code en het design was goedgekeurd.

Ik snap wat je bedoeld.

Dit is echter een heel gevaarlijk argument. Het is namelijk het meest gehoorde verweer van van sloppy coders en kortzichtige managers. Als iemand voorstelt om netter te coden, dan is een standaard reactie meestal: "Ja, en dan zeker toestemming moeten vragen voor elke regel code die ik schrijf he!? Nee dank je de koek-koek!".

Het feit dat een over-bureaucratie bestaat is gewoon geen reden om dan maar elke regel aan je laars te lappen en de cowboy of hippie uit te gaan hangen.

Van te veel water drinken ga je dood. Moet je daarom maar helemaal geen water meer drinken?

[aswelter]

Bij aanpassingen in code laten enkele personen 9 van de 10 keer alle oude code staan. 2 a 3 van die gevallen pik ik er dan nog tussen uit met mijn controles, maar dan staat er nog steeds -veel- rotzooi.

Dat is vanwege maar 1 reden : Software onderhoud is moeilijker dan nieuw bouw. Vandaar de standaard reactie van de meeste programmeur om maar opnieuw te beginnen. En dan uiteraard in deze "nieuwe code" alle fouten weer opnieuw maken.

Het zou verplicht moeten worden om weer eens echt onderhoud te moeten doen waardoor je leert om code te lezen ook al is die van iemand anders.

[aswelter]

Als het aan mij lag, zou gans de code basis herschreven worden. Ben je maanden aan bezig, maar uiteindelijk spaar je deze tijd in de toekomst uit, en win je erop met minder bugs, duidelijker, sneller ( performance ), en sneller ( implementeren nieuw code ), meer future proof.

Lees eens "in search op stupitity" en vooral het stukje over netscape. Jouw reactie geeft aan wat ik ergens anders ook al zei: onderhoud is moeilijker dan nieuwbouw...en jouw jouw gaat de volgende programmeur exact hetzelfde zeggen over jouw nieuwe/sneller/minder bugs etc... code

[Verwijderd]

Ik snap wat je bedoelt.

Voor de duidelijkheid: ik bedoelde dat dit bedrijf door schade en schande leerde dat kwaliteit belangrijk was.

Als beginnend programmeur vond ik elke nieuwe regel kleinerend. Maar het wende. En ik merkte snel dat het ook veel beter werkt.

Ik ben gewend dat ik toestemming van mijn manager nodig heb om een stuk code te wijzigen. Als ik een PR en CR krijg, dan moet ik eerst globaal opschrijven wat ik denk te gaan doen. Pas als ik dan toestemming krijg, mag ik de wijziging doorvoeren.

En ik vind dit niet raar. Ik vind het juist gek als ik op eigen houtje zomaar iets mag veranderen in een belangrijk product.

[flowerp]

Dat is vanwege maar 1 reden : Software onderhoud is moeilijker dan nieuw bouw. Vandaar de standaard reactie van de meeste programmeur om maar opnieuw te beginnen. En dan uiteraard in deze "nieuwe code" alle fouten weer opnieuw maken.

Inderdaad, helemaal met je eens!

Het is veelal een reactie van nieuwe, onervaren programmeurs. In veel gevallen is het ook niet zo'n goede strategie omdat je inderdaad alle subtiliteiten in de bestaande source code niet zo snel kan doorgronden en gedoemd bent veel fouten weer overnieuw te maken.

Met name de tijdsschatting is het probleem. Nieuwe programmeurs hebben nogal de neiging hun eigen kunnen te overschatten. Die denken het dan wel even overnieuw te schrijven, maar er gaat -altijd- veel en veel meer tijd in zitten.

Het wordt trouwens ook als weer een ander excuus gebruikt om code niet netjes te houden: "Dat is toch oude code, die ga ik over een tijdje toch helemaal overnieuw schrijven. Het is dus zinloos om dat nu te gaan cleanen." (en dan na enkele jaren is de code nog niet overniew geschreven omdat bleek dat het dus inderdaad veels te veel werk is)

[Eric Oud Ammerveld]

@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.

[ErikRad]

"Als lead programmer is 1 van mijn taken het bewaken van de kwaliteit van sourcecode,"

Dus in dit geval neem je actie en escaleer je de zaak. Dat is dan toch ook jouw verantwoordelijkheid?

[flowerp]

Dus in dit geval neem je actie en escaleer je de zaak. Dat is dan toch ook jouw verantwoordelijkheid?

Inderdaad, dat is mijn verantwoordelijkheid en af en toe doe ik dat ook. Dan verhef ik m'n stem, komen er wat woedende en rode gezichten (want ze zijn het er natuurlijk nooit mee eens) en gaan we daarna weer verder.

Het jammere in dit geval is echter dat (Java) programmeurs zo moeilijk te vinden zijn. Er zit natuurlijk een zekere angst in dat bij een te grote escalatie de programmeur in kwestie opstapt. Zelf zou ik de rotte appels er het liefst uit willen en daar dus niet rouwig om zijn, maar in ons toch al onder bezette team is dat momenteel niet echt een optie.

Volgens mij geeft Java een exception als je dat probeert. Ik heb het een tijdje geleden in al m'n onschuld ook eens gedaan

Dat hangt natuurlijk van de collection implementation af.

De collections in de JDK zelf zijn bijna allemaal fail-fast. Maar het punt in deze situatie was niet -dat- er altijd twee threads op die ene collection tegelijk werkte. Er was een -mogelijkheid- dat dit kon gebeuren. De thread die er wat instopt draait gemiddeld ongeveer 1 maal per uur. De thread die itereerd draait vast elk half uur. De kans dat ze er allebei tegelijk in werken is misschien niet zo groot. In de live code was het nog nooit gebeurd, en daarom was de programmeur ook zo kwaad dat ik er wat van zei.

Met een vrij simpele aanpassing kan je deze code thread safe maken; gewoon een synchronisatie block beginnen voordat je de iteratie in gaat. De programmeur vond dit echter onzin; het was nog nooit live fout gegaan, waarom zou ie die aanpassing moeten maken?

Dat is dus ook wat iemand netjes of slorig maakt. Nette programmeurs sluiten al problemen uit voordat die optreden. Slordige programmeurs reageren alleen op problemen nadat ze zijn gebeurd.

Soms zie je dit tot in het extreme doorgevoerd. Zo hadden we een formulier met 8 invul velden die totaal niet gecontroleerd werden. Op een dag ging het fout met veld 3, dus zette die slordige programmeur alleen een check op veld 3. 2 maanden later ging het fout met veld 1 en je raad het al, er kwam toen alleen een check op veld 1 bij. Het is bijna alsof die mensen iets missen, maar het komt gewoon niet in ze op om dan meteen checks op alle velden te zetten.

( Ik kan bijna wel een eigen thedailywtf beginnen aan de hand van alle dingen die ik in de praktijk tegenkom )

[vbmot]

offtopic:
Volgens mij geeft Java een exception als je dat probeert. Ik heb het een tijdje geleden in al m'n onschuld ook eens gedaan

[aswelter]

En wat heb je toen gedaan? Je vervolg actie met deze programmeur is uiteindelijk terug tezien in je software en je support.

Management is dus ook in dit soort van gevallen van belang.

Enneee....omdat iedereen al cmm etc heeft genoemt noem ik nog maar even PSP (Personal Software Process)

[Corrit]

Uiteraard zul je altijd zien dat deze 1% in de praktijk dan al snel uitbreid tot 5-10%, als iedereen zo te werk gaat.

[maartsen]

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.

[Mic2000]

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.

[Verwijderd]

Ik ben het grotendeels met je eens.

Software development is nog een grotendeels een ambachtelijk beroep waarbij er weinig tot geen regels zijn. Waar in veel oude industrieen (zoals vliegtuigbouw en wegenbouw) wettelijke normen zijn waaraan een product moet voldoen, is dat er voor software nog niet of nauwelijks.

Ik denk dat het eisen van bepaalde normen van het proces waarop gebouwd wordt (denk aan CMM en ISO) al een heel eind help, maar uiteindelijk is het de praktijk die de echte kwaliteit test. De technieken hiervoor bestaan al, met als belangrijkste automatische unit tests. Als deze goed worden ingezet om nauwkeurig zowel realistisch als extreem gebruik te simuleren, kan je hiermee een garantie voor kwaliteit worden geleverd.

Er zijn echter een groot aantal redenen te geven waarom dit nog niet breed wordt toegepast.
1) statisch vs. dynamisch: een brug is een statisch element. Het zal in zijn leven nauwelijks veranderen, dus als het eenmaal "werkt" en de brugdelen onderhouden of vervangen worden, blijft het werken. Hetzelfde geldt in grote mate voor een vliegtuig. Met software is dat echter anders. Software zal gedurende een levenscyclus relatief veel wijzigen, waardoor na iedere aanpassing de kwaliteit van een systeem opnieuw gecontroleerd moet worden.

2) kosten: Software is duur om te maken, duur mo te gebruiken en duur om te onderhouden. Om deze dan ook van top tot teen te testen is ook enorm duur, zeker als je weet dat met iedere wijziging van de software alle testen aangepast moeten worden en het hele systeem binnen zijn context opnieuw getest moet worden. Voor veel bedrijven is het simpelweg het geld niet waard om dit te bekostigen.

3) Doorlooptijd: Veel bedrijven zijn tevreden met een redelijk produkt over 3 maanden i.p.v. een goed product over een half jaar. Software moet een hulpmiddel zijn, en in de snelle veranderingen van de markt is er soms geen tijd om alles kwalitatief hoogwaardig aan te pakken.

Vooral redenen 2 en 3 zijn een direct gevolg van de keuzes van de klant. Men wil iets hebben wat goed genoeg en niet te duur is, want foutloze software maken kost veel meer tijd en geld. Als men wettelijk afdwingt dat software een bepaalde kwaliteit moet hebben of de kosten van storingen te hoger worden dan de kosten van kwalitatief betere software, zal er vanzelf geschakeld worden naar kwalitatief betere processen en technieken.

Overigens, het idee dat een certificering van programmeurs of projectleiders zou helpen is onzin. Een brug blijft niet overeind omdat engineers een diploma hebben, maar omdat ze aan wettelijke normen die soms over honderden jaren ontstaan zijn moeten voldoen, en omdat ze deze volledig "testen" met simulaties en natuurkundige berekeningen voordat ze werkelijk bouwen.

Echte kwaliteit zit in het proces, niet in de mensen.

[Eric Oud Ammerveld]

[dubbel post]

[Eric Oud Ammerveld]

Echte kwaliteit zit in het proces, niet in de mensen.

Met een berg rotte appels kan je geen verse appelmoes maken, onafhankelijk van je proces.

Je proces (ik neem aan dat je refereert naar het software ontwikkeltraject in algemene zin) geeft je sturing in welke methodieken je op welk moment moet gebruiken/benutten.

Een belangrijke factor, zo niet de belangrijkste factor zijn de mensen die ontwikkelen (developers/programmeurs) en de mensen die een sturende rol hebben in dit traject (opdrachtgever/project manager(s)) en de communicatie tussen deze partijen.

Slechte programmeurs kunnen je ontwikkeltraject in een zeer korte tijd heel gestructureerd en gedocumenteerd naar de afgrond leiden.

Een klein voorbeeld dat ik wil aanhalen is het gebruik van de projectmanagement/beheersings methodiek Prince2.
In veel ontwikkeltrajecten is beheersing hiervan een vereiste terwijl ze eigenlijk enkel pas goed toepasbaar is bij grote trajecten. (> 15 man)

Bedrijven zien het belang van een controlerende en sturende entiteit binnen een ontwikkeltraject, maar weten vaak niet op welke manier ze deze entiteit willen laten monitoren.

Ze worden gewezen op een bewezen techniek (Prince2) en willen dit koste wat het kost toepassen op een clubje van 4 programmeurs.
Dit is gebruikmaking van een proces dat niet geschikt is voor een kleinschalig ontwikkeltraject.
Is het daarmee een slechte techniek?
Nee; maar het geeft wel aan dat je je niet moet blindstaren op een proces maar moet kunnen terugvallen op de kunde van de procesbegeleiders en de uitvoerende partij.

[hansg]

Een brug kost tientallen miljoenen. Een vliegtuig kost honderden miljoenen. Windows kost 400 euro.

Als je bereid bent die honderden miljoenen te investeren, en bereid bent om je eisen beperkt te houden, en een voldoende lang ontwikkeltraject kan accepteren, *dan* kun je foutloze software krijgen. Als je dat allemaal niet wil, als het goedkoop, snel, en vooral met zoveel mogelijk features moet zijn, dan kan er een foutje insluipen.

[Quadro!]

Euh, je beschrijft hier de ontwikkelkosten van die brug en het vliegtuig, niet de gebruiks / licentie kosten, zoals je bij windows doet. Kromme redenatie dus

[Cobalt]

Je maakt een fout in de kosten. Een brug kost tientallen miljoenen en wordt voor één klant gebouwd (bijv. Overheid). Een vliegtuig kost ook vele miljoenen en wordt ook voor één klant gebouwd (bijv. Air France). Windows wordt door één bedrijf gebouwd voor miljoenen gebruikers. De ontwikkelings kosten daarvan lopen ook in de miljoenen.

[merauder]

Bijna goed.

Een licentie om Windows te gebruiken kost 400 euro, een vlucht met het vliegtuig zie je op internet voor prijzen vanaf 49 euro. Denk dat het ontwikkelen van Windows ook al snel in de miljarden zal lopen.

Vind het zelf ook erg jammers dat er mensen in het vak zitten om maar de ICT-er uit te kunnen hangen, terwijl er ruimte verloren gaat voor mensen die wel het vak respecteren.

[flowerp]

Een brug kost tientallen miljoenen. Een vliegtuig kost honderden miljoenen. Windows kost 400 euro.

Iedereen koopt in feite dezelfde Windows. Duplicatie is triviaal. Je betaald met zijn allen gezamenlijk de werkelijke kosten.

400 euro * 0.5 miljard = +- 200 miljard.

(ja, dat is schrikken he!)

[R3M1]

Ik denk dat de ontwikkeling van Windows Vista wel iets meer dan 400 Euro heeft gekost. De analogie met een brug gaat niet op.

[tjerkw]

Fout,

Als we een vliegtuig met een copy commando meteen konden kopieren zou die ook maar 400 ballen kosten.

Het ontwikkelprocess voor Vista bijvoorbeeld ligt ook in de miljoenen. En ik durf zelfs te beweren dat een besturingssysteem complexer in ontwikkeling is dan een vliegtuig.

( ok vliegtuigen bevatten besturingssystemen maar die zijn al voorgefrabiceerd )

[ProfPi]

Een brug kost tientallen miljoenen. Een vliegtuig kost honderden miljoenen. Windows kost 400 euro.

De ontwikkeling van Windows Vista kostte iets meer. Denk ordegrootte 10 miljard dollar.

...en een voldoende lang ontwikkeltraject kan accepteren...

Zoek maar eens op hoe lang het ontwikkeltraject van Vista was.

[McRubz]

Ik begrijp je punt, maar je haalt verkoopprijs en kostprijs door elkaar. Dat komt omdat je windows oneindig kunt kopieren zonder noemenswaardige kosten en een brug niet. Windows kost dan ineens een paar miljard (volgens MS)

edit: toch maar eens leren refreshen.....

[Corrit]

Ik vind niet dat je windows met een brug of vliegtuig kunt gaan vergelijken.

Daarnaast moet je niet vergeten dat het ontwikkelen van windows ook honderden miljoenen gekost, voordat het werd wat het nu is. Het grote verschil in prijs komt alleen maar door het feit dat software zo supermakkelijk te reproduceren is.

Ik zou het heel redelijk vinden als er nog eens een windows editie komt die het een paar maanden kan volhouden zonder security-patches

[Bloodshot]

Leuke vergelijking, maar er klopt niets van. Denk jij echt dat Windows maar 400 euro heeft gekost?!?!? Ik denk dat je dezelfde ordegrootte als bij bruggen en vliegtuigen kunt hanteren.

Reken alle bedragen voor het gemak eens om naar percentages: Materiaal, Ontwikkeling, Constructie en Verkoop. Ik denk dat er percentueel gezien vele malen meer tijd/geld in Windows is gaan zitten in Ontwikkeling dan in een brug! (En bij Windows ook vrij veel in Verkoop/marketing. )

[Verwijderd]

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.

[RedLizard]

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.

[n4m3l355]

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.

[Parasietje]

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.

[timonb]

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.

[scsirob]

Negen van de tien keer zit een bug niet in het ontwerp van de applicatie, maar in de implementatie ervan.

Als een gebouw goed ontworpen is dan moet er heel wat gebeuren voor het uit elkaar valt door toedoen van een slechte metselaar. Dit omdat de materialen (stenen, cement) van een redelijk constante en bekende kwaliteit zijn. De metselaar moet wel een heeeel grote kluns zijn om er een ondeugdelijke muur van te maken.

Bij programmeurs/coders is het echter vaak dat de bouwstenen (subroutines) geheel aan hun eigen fantasie overgelaten worden. Vraag 10 programmeurs om een zoekfunctie te implementeren en je krijgt 10 verschillende routines (bouwstenen). Geen bekende en constante kwaliteit, dus onbekende interacties.

[Eric Oud Ammerveld]

Negen van de tien keer zit een bug niet in het ontwerp van de applicatie, maar in de implementatie ervan.

@scsirob
Het ontwerp van een applicatie kan en zal nooit alle situaties afdekken.
De daadwerkelijke implementatie is een detail uitwerking met het ontwerp als basis.
Het ontwerp is geïnterpreteerd en daarmee zal de uitwerking altijd voor 100% afhankelijk zijn van de programmeur en de controlerende partijen (project managers/testers).

Hoe vaak ik al niet van een opdrachtgever heb gehoord:
"Nee, deze situatie zal NOOIT voorkomen."
Waarmee de designer rekent op de kennis en het woord van de klant.

Programmeur A verwerkt de situatie in de applicatie als zijnde een exception. (rekeninghoudend met het feit dat ook een opdrachtgever en daarmee impliciet een designer zich kan vergissen)
Programmeur B verwerkt de situatie niet en hoopt dat deze zich inderdaad nooit zal voordoen.

Vervolgens blijkt in de praktijk dat deze situatie zich wel voor kan doen.

Gevolg:
Bij Programmeur A zal de gebruiker waarschijnlijk een melding krijgen van de situatie en zal een DBA/applicatiebeheerder of de gebruiker zelf handmatig moeten ingrijpen.

Bij Programmeur B zal de gebruiker waarschijnlijk een exception error krijgen die door de compiler is meegeprogrammeerd; één die enkel door een programmeur met de betreffende sourcecode te lezen is en te elimineren is.

In bovenstaande situatieschets is de opdrachtgever de oorzaak van de fout; de designer heeft deze constructiefout doorgewerkt en uiteindelijk is het aan de de programmeur om de situatie te kunnen herkennen en opvangen. Of dat dit laatste gebeurt is afhankelijk van de interpretatie van het design en afhankelijk van de kunde van de programmeur.

[Eric Oud Ammerveld]

[dubbelpost]

[Eric Oud Ammerveld]

Negen van de tien keer zit een bug niet in het ontwerp van de applicatie, maar in de implementatie ervan.

@scsirob
Bij software ontwikkeling is er niet één belangrijke factor die de hoofdrol speelt.
Het is een samenhang van factoren binnen een traject.
Zo zal de "schuld" vaak liggen bij een punt dat onafgedekt is gebleven bij het ontwerp / interviewen van de opdrachtgever / het programmeren en het punt waar dit zich in zal uiten zal 9 op 10 keer de applicatie zijn.

Het ontwerp van een applicatie kan en zal nooit alle situaties afdekken.
De daadwerkelijke implementatie is een detail uitwerking met het ontwerp als basis.
Het ontwerp is geïnterpreteerd en daarmee zal de uitwerking altijd voor 100% afhankelijk zijn van de programmeur en de controlerende partijen (project managers/testers).

Hoe vaak ik al niet van een opdrachtgever heb gehoord:
"Nee, deze situatie zal NOOIT voorkomen."
Waarmee de designer rekent op de kennis en het woord van de klant.

Programmeur A verwerkt de situatie in de applicatie als zijnde een exception. (rekeninghoudend met het feit dat ook een opdrachtgever en daarmee impliciet een designer zich kan vergissen)
Programmeur B verwerkt de situatie niet en hoopt dat deze zich inderdaad nooit zal voordoen.

Vervolgens blijkt in de praktijk dat deze situatie zich wel voor kan doen.

Gevolg:
Bij Programmeur A zal de gebruiker waarschijnlijk een melding krijgen van de situatie en zal een DBA/applicatiebeheerder of de gebruiker zelf handmatig moeten ingrijpen.

Bij Programmeur B zal de gebruiker waarschijnlijk een exception error krijgen die door de compiler is meegeprogrammeerd; één die enkel door een programmeur met de betreffende sourcecode te lezen is en te elimineren is.

In bovenstaande situatieschets is de opdrachtgever de oorzaak van de fout; de designer heeft deze constructiefout doorgewerkt en uiteindelijk is het aan de de programmeur om de situatie te kunnen herkennen en opvangen. Of dat dit laatste gebeurt is afhankelijk van de interpretatie van het design en afhankelijk van de kunde van de programmeur.

[Verwijderd]

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.

[Wim-Bart]

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.

[Verwijderd]

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.

[Verwijderd]

@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.

[CodeCaster]

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?

[Kalief]

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.

[tjerkw]

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.

[Wim-Bart]

@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.

[Verwijderd]

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.

[flowerp]

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.

[YaPP]

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.

[DutX]

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

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.

[J.J.J. Bokma]

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.

[fevenhuis]

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

[tjerkw]

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.

[tjerkw]

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! )

[betatester]

Een instortend gebouw is hetzelfde als software die totaal niet werkt. Echter software met bugs is hetzelfde als gebouwen met ontwerpfouten. Zowel de ontwerpfouten als de bugs worden later gerepareerd. Voorbeeld is de zwaan in Rotterdam. Iedere werktuigbouwkundige heeft weleens van de tacoma narrow bridge gehoord en wat denk je dat er bij deze brug gebeurde... inderdaad precies hetzelfde. En zo is het ook met software.

[bangkirai]

Zelfs als dat vliegtuig neerstort vanwege software fout, wordt er lang niet zo fel achteraan gezeten, wie en hoe die fout gemaakt is, dan een ontwerp fout.

Het wordt een beetje te normaal gevonden, dat er fouten voorkomen.

[J.J.J. Bokma]

Is dat een gevoelskwestie, of heb je hier harde cijfers voor?

[Eric Oud Ammerveld]

@ MrX

Echte kwaliteit zit in het proces, niet in de mensen.

Met een berg rotte appels kan je geen verse appelmoes maken, onafhankelijk van je proces.

Je proces (ik neem aan dat je refereert naar het software ontwikkeltraject in algemene zin) geeft je sturing in welke methodieken je op welk moment moet gebruiken/benutten.

Een belangrijke factor, zo niet de belangrijkste factor zijn de mensen die ontwikkelen (developers/programmeurs) en de mensen die een sturende rol hebben in dit traject (opdrachtgever/project manager(s)) en de communicatie tussen deze partijen.

Slechte programmeurs kunnen je ontwikkeltraject in een zeer korte tijd heel gestructureerd en gedocumenteerd naar de afgrond leiden.

Een klein voorbeeld dat ik wil aanhalen is het gebruik van de projectmanagement/beheersings methodiek Prince2.
In veel ontwikkeltrajecten is beheersing hiervan een vereiste terwijl ze eigenlijk enkel pas goed toepasbaar is bij grote trajecten. (> 15 man)

Bedrijven zien het belang van een controlerende en sturende entiteit binnen een ontwikkeltraject, maar weten vaak niet op welke manier ze deze entiteit willen laten monitoren.

Ze worden gewezen op een bewezen techniek (Prince2) en willen dit koste wat het kost toepassen op een clubje van 4 programmeurs.
Dit is gebruikmaking van een proces dat niet geschikt is voor een kleinschalig ontwikkeltraject.
Is het daarmee een slechte techniek?
Nee; maar het geeft wel aan dat je je niet moet blindstaren op een proces maar moet kunnen terugvallen op de kunde van de procesbegeleiders en de uitvoerende partij.

[mulder]

Je weet hoe ze smeerkaas maken? Juist, van rottende kazen

[catfish]

het gaat altijd over externe omstandigheden:
- een brug/gebouw wordt ontworpen om tegen een bepaalde windkracht te kunnen, aardbeving,... maar als er morgen een zware aardbeving is, is alles kapot
- als een vliegtuig in een zware storm terechtkomt, is de kans HEEL groot dat het neerstort: men vliegt niet bij stormen of men vliegt er rond
- software wordt maar geacht om altijd te werken, als bv MS dan rekening moet gaan houden dat jij een programma wil draaien op Windows dat geheugen van andere programma's wil overschrijven, dat foutieve hardware calls doet,... EN het moet ook een beetje snel blijven, tja, dan kan het wel eens misgaan

[captain007]

Fouten in je software zul je in embedded systemen daarom door een extra laag in je software moeten afvangen. In de extra laag zorg je er gewoon voor dat er geen dingen kunnen gebeuren, waardoor een systeem onveilig wordt. Natuurlijk zul je die laag uitgebreid moeten testen. Als die laag uiteindelijk goed is kun je een applicatie hierbovenop bouwen. Gaat hier dan iets fout dan zal je actie niet uitgevoerd worden omdat je beveiligingslaag dat blokkeerd.
Maar goed ik vind ook dat je beveiliging ook niet alleen in software maar ook in de hardware moet realiseren

Vindt het voorbeeld van de treinen in twente een ander probleem dan om te zeggen dat het niet veilig is. Bij de spoorwegen is de beveiliging ook nog altijd elektrisch uitgevoerd, dus onveilig is het zeker niet.

[Eric Oud Ammerveld]

@ captain007

Deze "laag" noemt men in de volksmond "kernel"
(Menig O.S. draait hier op)

[Verwijderd]

Veel embedded systemen kennen niet eens geheugenbescherming. Soms ondersteunt de CPU het gewoon niet. Soms ondersteunt het OS het niet. Soms wordt het gewoon uitgezet om performance te verbeteren. Taken kunnen dan gewoon elkaars geheugen lezen en beschrijven.

En een kernel kan er niets tegen doen als de software de actuatoren verkeerd aanstuurt.

Als een systeem kritisch is, dan wordt er daarom vaak een mechanische of elektrische beveiliging toegepast.

[Verwijderd]

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.

Weet jij hoeveel software in moderne vliegtuigen zit? Of in auto's? Of medische apparatuur? Een bug in die software kan levens kosten. Sterker nog, er zijn al eens mensen gestorven door bugs in een bestralingsapparaat.

En de leverancier van dit soort software komt niet zo makkelijk weg met "No warranty".

[spasieba]

Ik denk dat dit soort uitdrukkingen appels met peren vergelijken is....

Bij software waar levens van afhankelijk zijn wordt echt wel een stapje meer gedaan aan testen en reviewen van sourcecode..

(ziekenhuisapplicaties bijvoorbeeld)

Er gaat veel mis in de bouw, maar instorten van een gebouw/brug is iets anders dan een geldautomaat die een keer crasht of een kassa die opnieuw moet worden opgestart.

[Parasietje]

Software ontwikkelen is nu eenmaal heel erg complex. En een fout zit in een klein hoekje.

Door een licentie uit te reiken voor programmeurs (zoals bij dokters gebeurt), los je niets op. De number overflow die gebeurde bij de Ariane V had niemand kunnen voorzien.
Dit is IMHO de houding "er is altijd een schuldige voor een ongeluk te vinden". Sommige dingen zijn gewoon een ongeluk, en ik denk niet dat licenties uitreiken voor programmeurs daar iets aan kan veranderen.

[Gyske]

Ik denk, net als MrX, dat niet de programmeur de spil is, maar het ontwikkelproces.
Als het eindproduct niet goed is, dan is er iets niet goed aan het process. Het process moet ten alle tijden gericht zijn op het verbeteren van de kwaliteit van het eindproduct. Dit betekent dat het process dus ook altijd verbeterd moet worden.
Fouten kunnen tijdens alle stadia van het ontwikkelprocess optreden of geintroduceerd worden; tijdens requirements specificatie, test specificatie, design, en natuurlijk ook tijdens het programmeren en testen.
Wanneer er een fout geconstateerd wordt, moet deze natuurlijk verholpen worden. Er moet echter ook gekeken worden naar hoe de fout onstaan is en hoe voorkomen kan worden dat deze nog een keer onstaat.
Hier een interessant artikel over de software ontwikkeling voor de space shuttle. Natuurlijk hebben zij een bovengemiddeld budget, maar hun methodiek is overal toepasbaar.

Een onderdeel van de broodnodige professionalisering is dat iedereen zijn verantwoordlijkheid moet nemen voor hun aandeel in het process. Je moet je eigen fouten kunnen erkennen en ervan leren, ook wanneer je daar door derden op gewezen wordt.
Je kunt fouten dus niet altijd afschuiven op het proces.

Ik denk, net als vele anderen, dus dat de gehele industrie moet professionaliseren, niet alleen de programmeurs. Een belangrijk onderdeel is het kiezen en gebruiken van het juiste proces.
Er bestaan vele processen (bv V-Model, PRINCE2, RUP) en het is belangrijk om het juiste process voor het juiste product/project te kiezen.

PS Iets dat ik in het (bron)artikel en de bijbehorende commentaren bijna niet tegen kom is: testen.
Iedereen weet dat je het moet doen, maar velen doen het niet goed. Maar al te vaak wordt pas aan het einde van het ontwikkelprocess tijd besteed aan testen. Terwijl je je hier al vanaf het begin mee bezig zou moeten houden. Goed testen kost tijd, je moet een plan opstellen hoe je de juiste implementatie alle eisen aan de software wilt gaan verifieren. Er wordt de laatste jaren al wel steeds meer aandacht besteed aan testen, maar aan het feit dat het in deze discussies amper genoemd wordt, blijkbaar nog niet genoeg. (Op Monsterboard staan bijna evenveel vacatures voor testers als voor programmeurs)

[Eric Oud Ammerveld]

Prince2 is een overkoepelend sturings / controle (project management) proces.

Niet te verwarren / vergelijken met (project development processen) Rational Unified Process / RAD / IAD / XP / SDM (Edward Yourdon) etc. achtige methodologiëen welke daadwerkelijk structurele steun bieden in het traject van software ontwikkeling en waarin gebruik gemaakt wordt van de verschillende ontwikkel technieken. ( DFD's / UML / STD's / Procesdiagrammen etc.)

[progster]

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

[Jungian]

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.

[mashell]

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.

[Jungian]

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.

[Guru Evi]

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)

[kidde]

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)

[Verwijderd]

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

[]Byte[]

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
</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.

[Bobco]

Ahem, CMM zul je bedoelen...

[Jungian]

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

[melgers]

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

[Verwijderd]

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.

[Moolie]

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.

[Motrax]

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

[YaPP]

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.

[flowerp]

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.

[Wimw]

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.

[Freakertje]

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

[Verwijderd]

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.

[J.J.J. Bokma]

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.

[flowerp]

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.

[Verwijderd]

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

[flowerp]

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.

[timonb]

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!

[Michaelm]

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.

[Dizzy Grizzly]

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.

[tjerkw]

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.

[Verwijderd]

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.

[vbmot]

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 Bij kritieke systemen is het misschien nog wel aanvaardbaar, maar anders kost het vooral veel tijd en frustratie.

[flowerp]

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.

[tjerkw]

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.

[mashell]

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.

[elteck]

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.

[Floor]

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.

[Verwijderd]

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.

[HellPunk]

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.

[Verwijderd]

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.

[Verwijderd]

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.

[mashell]

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.

[roy-t]

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.

[Verwijderd]

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.

[flowerp]

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.

[Verwijderd]

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.

[flowerp]

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.

Inderdaad is dit vreemd. Ik heb hier zelk ook al veel over geschreven. Het is van de gekke, steeds meer van onze economie is van software afhankelijk, maar als je achter de schermen kunt kijken als programmeur dan schrik je jezelf rot.

Regels zijn er amper, en waar ze er zijn worden ze niet nageleefd. De meest ranzige programmeur constructies zie je en veel mensen lijken zich amper bewust van wat ze nu aan het doen zijn. Onder het mom van "we moeten pragmatisch zijn" en "time to market is belangrijker dan solide code" worden designers of programmeurs die wel serieus met hun vak bezig zijn door managers en mede-programmeurs min of meer gedwongen ondermaats werk af te leveren.

Vergelijk het eens met andere industrieën. Als je een wolkenkrabber wilt bouwen, maar je hebt er niet de tijd en mankracht voor om het goed te doen. Bouw je deze dan maar 'pragmatisch', zonder een design, zonder analyse, en met inferieure bouw technieken?

Ook kwa scholing is het een bizarre situatie. Zelfs hier op tweakers, waar over het algemeen toch de wat meer geïnteresseerde mensen rondhangen, wordt het concept scholing en opleiding voor programmeren vaak belachelijk gemaakt. Een tijdje terug was hier nog een zeer lange thread over op GOT. Het onderwerp was zo'n beetje dat scholing onzin was en dat je programmeren veel beter 'in de praktijk' kon leren.

[YaPP]

Ook kwa scholing is het een bizarre situatie. Zelfs hier op tweakers, waar over het algemeen toch de wat meer geïnteresseerde mensen rondhangen, wordt het concept scholing en opleiding voor programmeren vaak belachelijk gemaakt. Een tijdje terug was hier nog een zeer lange thread over op GOT. Het onderwerp was zo'n beetje dat scholing onzin was en dat je programmeren veel beter 'in de praktijk' kon leren.

Ik ben het eens met de stelling dat je programmeren in de prijktijk leert. Alleen wil dat niet zeggen dat je daardoor scholing moet afschaffen. Programmeren is typisch een vak wat je leert door het te doen. Een goede opleiding kan je de richting geven en je blik verbreden. Maar je moet het toch echt zelf doen!

Zelf zie ik vanuit scholen maar weinig briljante programmeurs komen. De echte goede hebben in de avonduren al veel zelf gemaakt, pluizen de broncode van de library na om te begrijpen hoe iets echt werkt, en kunnen zich verplaatsen in andere programmeurs (hoe zij je gemaakte API functies moeten gebruiken).

De slechte zullen nog 10x een regel veranderen om te kijken of "het dan wel werkt", werken om fouten heen die ze niet begrijpen, documenteren een hypothese waarom iets niet werkt als waarheid, beschouwen een library als black-box, of zijn compleet afhankelijk van goede documentatie, code completion, waarschuwingen van de compiler, of een afgebakende sandbox.

Mensen uit de laatste categorie tref je overal aan. De eerste categorie is moeilijker te vinden. Dan merk je hoe belangrijk systemen als CMM worden, het proces om programmeren heen en eisen die je moet stellen voor sommige functies.

[flowerp]

Een goede opleiding kan je de richting geven en je blik verbreden. Maar je moet het toch echt zelf doen!

Maar geldt dat niet voor zo'n beetje elk beroep op niveau?

Als arts opereren moet je toch ook zelf doen. Toch ben ik wel HEEL erg blij dat er strenge regels zijn aan de opleiding en licentie van een arts.

Een opleiding zorgt er heel concreet voor dat je naar een aantal basis dingen gekeken hebt, dingen waar je dikwijls niet naar kijkt als je alles zelf probeert te leren. Dit is weer een beetje de discussie die op GOT bijna 1000 berichten opleverde, maar thuis ga je heel gericht dingen leren die in jouw oneindige arrogantie 'goed' zijn.

Voordat ik aan mijn informatica opleiding begon, kon ik allang al programmeren. Basic toen ik 6 a 7 was, paar jaar later C, etc.

Een opleiding is echter veel meer dan de syntax en wat populaire concepten leren. Wat een turing machine precies is had ik nog nooit bij stilgestaan. Heb je dat nodig om C++ te programmeren? Staan daar referenties naar in de MFC tutorials. Niet direct, en dus had ik me daar ook thuis nooit mee beziggehouden. Nu ben ik blij dat ik de tijd en gelegenheid heb gehad om daar naar gekeken te hebben. Zelfde geldt voor tig andere concepten binnen de Informatica.

Na het eigen hobbymatige werk en de opleiding zul je nog inderdaad enkele jaren in de praktijk moeten werken om ervaring en inzicht op te doen.

Dit laatste aspect betekend dan niet dat je met alleen werken dat zelfde inzicht krijgt. Mijn ervaring leert dat veel home-made mensen, uitzonderingen daargelaten, dikwijls een vrij nauwe blik hebben. Ze zijn heel erg op specifieke technieken gericht (die ze dan ook wel goed kunnen beheersen), maar kunnen moeilijk naar iets heel anders kijken omdat ze altijd gewend zijn alleen dat te gaan gebruiken wat ze zelf dachten dat goed was.

Ook vallen er soms op de raarste plekken gaten. Lange tijd terug kende ik iemand die de C++ syntax en subtiliteiten van een bepaalde C++ compiler tot in de kleinste details kende, maar doodleuk een algoritme schreef met logaritmische complexiteit, terwijl het gewoon lineair kon. Deze persoon had zich simpelweg nog nooit beziggehouden met analyse en complexiteit van algoritmes, gewoon omdat ie dat nogal zaai vond en liever met de C++ syntax zelf bezig was.

[Verwijderd]

Mag je dan enkel met een licentie een compiler opstarten? Of mag je enkel met een licentie je software op sourceforge zetten? Of enkel met een licentie software voor een bedrijf maken. Wat dan als je tomcat of log4j in je applicatie wil gebruiken, mag dat dan enkel als er een certificaat bijzit dat het door gelicenceerde programmeurs is geschreven?

Totale onzin volgens mij.

[mariusdustbin]

Een opleiding heeft niets te maken met goede software (somige mensen hebben het nu eenmaal, andere zullen het in nog geen 100 jaar leren, 60% studenten valt (vroegtijdig) af).

Goede programmeurs zijn mensen met inzicht, waardoor ze kunnen voorkomen dat het slechte spul op de "straat" terecht komt. Daarnaast bestaat er nog iets als een goed ontwerp, genoeg tijd, extreme programming, extreme testing, noem ze maar op..Ik denk dat indien laatste laatste eigenschappen mits goed toegepast een hoge CMM kunnen scoren.

edit: spelf*.

[Verwijderd]

Het is een goeie discussie, maar ik weet zeker dat de Mars-robot en de Ariane geprogrammeerd waren door mensen die vast wel zo'n licentie zouden kunnen halen en niet door een of andere hobbyist.

MAW: Reken er niet op dat door zo'n systeem het aantal bugs en fouten magisch uit software verdijnt.

[DiSiLLUSiON]

... Er worden topmanagers vervangen, maar die kunnen er vaak ook maar weinig aan doen, aangezien het probleem zich bij de softwareontwikkelaars bevindt. ...

Uitzonderingen daargelaten (er zijn nou eenmaal wat minder professionele mensen in elke branche, dus ook in de ict-branche) is dit wel de grootste onzin dat ik in lange tijd gelezen heb.

Een ambachtelijke schoenmaker neemt er de tijd voor om een kwalitatief hoogstaand product te leveren. Dan wordt er niet gehaast, ook al kost het dan wat meer dan dat de concurrentie er aan zou besteden, en zal deze kosten doorberekend moeten worden aan de klant. Een schoenmaker (lees: fabriek) in Taiwan poept er dagelijks een heleboel schoenen uit, welke misschien maar matig van kwaliteit zijn. Maar die zijn dan ook erg goedkoop, als ze kapot gaan koop je gewoon een nieuw paar.

Een ambachelijke wijnproducent neemt de tijd voor om de druiven handmatig te oogsten, tot sap te persen en de wijn dan een tijd te laten rijpen alvorens deze te verkopen. Erg lekker, maar dat kost dan ook wat, die manier van productie en de opslag. Deze kosten worden doorberekend naar de klant. Een supermarkt-wijnproduct doet alles bijna automatisch. Deze wijnen liggen dan ook in het vak van de plaatselijke supermarkt, bijna voordat ze ook maar geoogst zijn. De smaak is een stuk minder, maar ach, daar betaal je dan ook minder voor.

Daarintegen wordt er van een programmeur meestal verwacht om zo min mogelijk tijd aan een project te besteden? Tijd is immers geld, en daar heeft de baas/opdrachtgever/klant altijd te weinig van lijkt het wel... Als je als bedrijf een bepaalde begroting maakt voor een correct en goed getest stuk software, en de concurrent maakt een begroting die half zo groot is maar waarvan de programmatuur is afgeraffeld, dan kiest de klant voor de concurrent. De klant ziet immers toch niets van de afgeraffelde code. En ja, het is dan nogal wiedes dat de kwaliteit eronder te lijden heeft, als het allemaal maar zo min mogelijk mag kosten.

Dus, om maar zo weinig mogelijk tijd kwijt te zijn aan het project zal er wat minder uitgebreid getest worden, wat minder tijd besteed worden aan de opzet van de structuur en zullen eventuele problemen zo snel mogelijk gepatched moeten worden zonder na te denken over de effecten op de rest van de programmatuur..

Een collega van mij gaf eens het volgende voorbeeld: Er zijn 3 punten van de driehoek, waarbij je er 2 vast kunt leggen, het maakt niet uit welke twee, en de derde altijd zal fluctueren: Tijd, Geld en Kwaliteit." Helaas is het in de branche, in tegenstelling tot andere branches, doodgewoon om vooral Tijd en Geld vast te zetten... De kwaliteit zal er zodoende regelmatig door te lijden krijgen, en zo ontstaan bugs.

Als men wil zorgen dat de hoeveelheid bugs in programmatuur vermindert, dan zal men niet bij de programmeurs in kwestie te raden moeten gaan, want deze zijn spreekwoordelijk aan handen en voeten gebonden door de tijd/budget limieten. Zorg er liever voor dat de verantwoordelijken voor het budget en/of de deadline begrijpen dat het in bepaalde gevallen beter is om Kwaliteit en Tijd vast te leggen en zodoende het budget te moeten verhogen.

Zorg desnoods voor een cursus, waarin top-managers en andere personen waarbij de verantwoordelijkheden van grote programmeerprojecten liggen, inzien en begrijpen waarom er soms extra tijd uitgetrokken moet worden voor een project. Leer ze begrijpen dat je niet binnen een korte periode met een volledig product op de proppen kunt komen en het daarna rustig beetje bij beetje bij kunt schaven, zoals men dat bijvoorbeeld met een website ontwerp kunt doen.

[supershoe]

Bugs blijf je altijd houden, je moet er alleen zo veel mogelijk vinden voor je stukje code in productie gaat.

Dit stukje legt wel heel erg de schuld bij de programmeur. Wat dacht je van:
- De projectleiders die deadlines stellen en het advies van een programmeur om er meer tijd aan te besteden negeren
- Alle consessies die sowieso worden gedaan om geld en tijd te besparen
- Testers die de software niet grondig genoeg hebben getest

Heus niet enkel de schuld van programmeurs.

[YaPP]

Inderdaad. Deze quote vond ik ook wat goedkoop:

Er worden topmanagers vervangen, maar die kunnen er vaak ook maar weinig aan doen, aangezien het probleem zich bij de softwareontwikkelaars bevindt.

Probeer als programmeur maar een goed verkoop praatje te houden bij je manager, die bijv. geen verstand heeft van de techniek/binnenkant. Vertel hem dan dat er een hoop moet gebeuren aan de software maar je aan de buitenkant niets van zult zien. Zoiets kunnen een hoop programmeurs niet goed brengen, en standaard managers moeilijk bevatten.

Uiteindelijk komt het erop neer dat je als programmeur niet een gehele organisatie kunt verbeteren. Iedereen in de organisatie zal een duidelijke visie moet delen om kwalitatieve software te kunnen produceren.

Blijkbaar denkt men dat (top)managers niets inhoudelijk te hoeven begrijpen om een softwareproject te kunnen managen. Daar krijg je helaas wel onhandige - kort door de bocht - gemaakte beslissingen door, zoals een budget korten omdat het ook wel zonder af kan. Zelf merk ik in mijn werk dat een stuk beter werkt als de manager abstract kan meedenken, en andersom de programmeur ook iets begrijpt van verkoopbaarheid, iets rendabel maken, of een investering terug kunnen verdienen.

[Verwijderd]

embedded programmeren is een ander verhaal. Van een auto wil je niet dat de cruise control blijft hangen, maar een bank wil misschien software al inzetten als het pas voor 80% af is omdat de fouten die er in zitten nooit meer geld kost dan de functionaliteit op dat moment al kan opleveren.

[flowerp]

Heus niet enkel de schuld van programmeurs.

Volgens mij bedoeld ook niemand dat. Het gehele software development process moet professioneler uitgevoerd worden. Dat begint al met het besef dat er bv uberhaupt getest moet worden, dat er iets als een design moet zijn, dat er release/deploy voorschriften moeten zijn. Dit zijn dikwijls dingen die in min of meerdere mate buiten de pure 'programmeur' vallen.

Je wilt niet weten hoe veel managers van al die snel geld verdien bedrijfjes achter hippe websitetjes hun programmeurs opdragen om dingen gewoon live aan te passen.

Enkele jaren terug nog gehoord bij de uitbater van een nu niet al te kleine web site toen ik een aanpassing moest doen en vroeg waar ik het kon testen: "wij testen live, dat is veel directer"

[ram.con]

Deze drie argumenten zijn zonder probleem op elke soort van 'productie' toe te passen. Op heel veel plaatsen is het volstrekt niet toegestaan dat er fouten worden gemaakt, zo ook bij vele software, zeker omdat tegenwoordig overal software 'achter' zit. Op al die plaatsen is het noodzakelijk dat het productiesysteem zo ingericht is dat fouten worden uitgebannen.

Meer zegt het stuk ook niet. Er moet een zodanig systeem komen dat de programmeurs goed zijn, de voorwaarden goed zijn en de controle goed is. Het is nu niemands persoonlijke schuld Er moet alleen een houding komen tav softwareschrijven veel meer fouten voorkomt. (Noem het professionalisering, noem het 'het beroep van programmeur wordt volwassen, noem het een kwaliteitsslag, whatever)

[Verwijderd]

Software kan inderdaad vrijwel foutloos geschreven worden indien er tijd genoeg is. Ik zie het altijd bij ons op het bedrijf. Ze will alle toeters en bellen en ze willen het gisteren.

[J.J.J. Bokma]

"Software kan inderdaad vrijwel foutloos geschreven worden indien er tijd genoeg is."

Helaas niet waar door diverse redenen die je niet noemt. De belangrijkste is dat het merendeel van de programmeurs gewoon niet voldoende kennis heeft.

[XyritZz]

Programmeurs hebben vaak wel voldoende kennis, maar zijn té ijverig. Ik herken het bij mezelf ook als ik aan het coden ben, goh met 3 regels code kan ik er nog een feature bij maken.

Vervolgens staat deze 'feature' niet in je specificatie, en word deze ook niet getest. Drie keer raden waar de meeste bugs in zitten...

Juist door eerst tests te schrijven, en daarna je methoden kun je zeer snel ontwikkelen. In het begin zal het extra tijd kosten, omdat je meer regels code moet tikken, maar als je er aan gewend bent leer je jezelf aan om je gewone methoden makkelijker testbaar te maken en krijg je dus kleinere methoden die overzichtelijker zijn. Het onderhoud word makkelijker, je ontwikkelt je test+code sneller dan dat je vroeger je code schreef, en als je jezelf aanleert geen ongespecificeerde features in te bouwen zul je merken dat de software echt beter word.

Wat blastboy zegt vind ik trouwens ook kloppen, tijdsdruk komt er altijd op neer dat het testen ingeperkt word, aangezien dit (nog te vaak) aan het einde van de tijdlijn ingeplanned staat.

[J.J.J. Bokma]

"Programmeurs hebben vaak wel voldoende kennis, maar zijn té ijverig."

Mijn ervaring is dat veel programmeurs gewoon te weinig of soms geen kennis hebben. Het merendeel kan zeker niet bewijzen dat hun code probleemloos werkt, zelfs al hadden ze daar de tijd voor.

"goh met 3 regels code kan ik er nog een feature bij maken."
Precies, en daarom hebben veel programmeurs managers nodig. Ik werk voor mijzelf, en dan is het simpel. Die extra feature moet ik overleggen met de klant (tenzij het een feature is die mijn werk makkelijker maakt natuurlijk)

Veder, yup, tijd voor testen is er zelden, dus meer goed plannen, meer 3rd party libraries gebruiken (die al getest zijn door derden), en overbodige code zoveel mogelijk vermijden.

[arjankoole]

meer 3rd party libraries gebruiken (die al getest zijn door derden)

en wie garandeert je dat die libraries getest zijn, en goed getest zijn? De leverancier? Tja, een salesgoof wil je alles vertellen wat je horen wilt.

Er is geen goed alternatief voor eigen ontwikkeling en zelf kwalitatief testen. Ik vind eigelijk dat iedere programmeur dat als prime directive moet zien. Misschien worden ontwikkeltrajecten daar wel langer door, maar uiteindelijk zal je dat ook echt wel aan de klant kunnen verkopen. (men betaald graag iets meer, als ze daar ook meer kwaliteit voor krijgen)

[Verwijderd]

Meestal is een systeem pas bugvrij als het einde van de levensduur is bereikt.

[Eric Oud Ammerveld]

.. mjah Windows 98 SE is inderdaad geheel bugvrij ...

[flowerp]

Software kan inderdaad vrijwel foutloos geschreven worden indien er tijd genoeg is. Ik zie het altijd bij ons op het bedrijf. Ze will alle toeters en bellen en ze willen het gisteren.

Let op het woordje 'vrijwel' hier. Ik ben het eens met blastboy. Als je niet met complete idioten werkt, en er voldoende tijd in stopt dan kom je al zo'n veel stuk verder als men nu vaak komt.

• Als je in plaats van een slordig todo'tje neer te krabbelen gewoon even de moeite neemt om een requirement een beetje te omschrijven. Paar zinnetjes, even een schetsje erbij hoe er uit moet zien, etc. Zo veel moeite is dat niet. Nu probeert men gewoon te vaak dingen te 'specificeren' met one-liners als: "Laat gebruikers een opmaak maken via een template".
• Probeer dingen tenminste schetsmatig te designen. Misbruik het concept van over-designen niet als excuus om helemaal niet meer te designen. Sommige mensen zien -echt- anti designs, maar ook hier hoeft het allemaal niet zo veel moeite te kosten. Een compleet fully featured UML model is zeker niet altijd nodig. Een simpele class diagram schets op papier, met een eenvoudige sequence diagram erbij die je even bespreekt met je collega's hoeft in veel gevallen niet meer dan enkele uren te kosten. Toch wordt dit te vaak niet gedaan, onder het mom van: "de klant leest en ziet toch geen design".
• Ga bij de implementatie gewoon van de best practices uit. Weet gewoon als programmeur van de meest bekende design patterns af. Als je als programmeur te beroerd bent om even tenminste een paar A4'tjes te lezen over die basic patterns, dan moet je je afvragen of je wel het goede vak gekozen hebt. Veel platformen bieden b.v. ook direct support voor het MVC model. Gebruik dit gewoon. Ga niet denken sneller te zijn door weer wat business logic in een view te vrotten.

Ik kan zo nog wel even door gaan mbt testen en deployment, maar het stomme is dat al deze dingen al jaren lang bekend zijn. Ik heb nog een software engineering boek uit 1995 in de kast staan en alle genoemde punten stonden daar al gewoon in.

Om echt volwassen te worden heeft de software industrie misschien nog wel wat meer nodig, maar als het overgrote deel van de shops zich al niet aan de basics kan houden, dan hebben meer advanced methoden IMHO ook niet zo veel zin.

[servies]

Goh, ik dacht dat dat alleen bij ons gebeurde...

[Luno]

Ik ben programmeur of zo iets. M'n eerste programma schreef ik in 1967.

Wat constateringen:

Ik heb een aantal malen in beta programma's meegedaan (o.a OS2/Warp, WordPerfect diverse versies).
Wat mij daarin altijd verbaasde wat dat als ik een bug meldde en het het niet reproduceerbaar was, het blijkbaar geen bug was. IMHO is als slechts één persoon een bug meldt het al iets is wat onderzocht zou moeten worden.

Dijkstra's uitspraak: Goto is Harmful en een ieder die met een programmeertaal die goto bevat, nooit een goede programmeur kan worden gaat me iets te ver. Maar in feite zijn alle moderne objecten talen zit zoiets: je klikt op iets en dan gaat er iets uitgevoerd worden. Dat is een soort gemaskeerde GOTO. En die brokjes coding weten nauwelijks wat de 'echte' status is van het programma, maar gaan gewoon iets doen. Vind je het gek dat programma's crash gevoelig worden.

Waarom zou software niet net als elk ander product moeten voldoen aan het consumenten recht: als het niet doet wat het geacht wordt te doen, dan krijg een gratis reparatie of je geld terug. Wedden dat men minder hasst heeft om iets buggy op de markt te zetten.

Als programmeur, ga defensief programmeren, dwz, ga ervan uit dat men verkeerde parameters meegeeft, maak een exception handler altijd aan. Geef dan een zinnige foutmelding, of liever nog geen een zinnige melding en een suggestie hoe het wel moet.

Tot slot: ik geloof niet in gelicenceerde programmeurs, wel in goede programmeurs en slechte. En goede programmeurs documenteren de source, omdat ze weten dat jaren jaren die documentatie ook voor henzelf nodig is.

edit:

Googel overigens eens op: mythical man month

[yeep]

Hier had ik al wat over gezet in mijn initiele reactie. Als slechts 1 op de 100.000 mensen een bepaalde bug odnervind, dan is het jammer voor die persoon, maar dan levert het niets op voor de maker om de bug te fixen. Het kost te veel geld om dat voor die ene persoon te doen.
Bedrijven willen geld verdienen, zo simpel is het.

En buggy software is vaak ook buggy, niet door een bug in de software zelf, maar omdat een ander programma iets raars doet en het verpest voor de andere programma's. Plug-ins of drivers die gewoon slecht zijn. Als dit niet helder is, zoals vaak bij device drivers in Windows, dan krijgt de 'hoofd-applicatie' de schuld.

Defensief programmeren klinkt heel goed, maar het is lang niet altijd mogelijk. Je wil namelijk ook generiek programmeren, zodat je een functie vanuit meerdere locaties in je programma kunt gebruiken, want minder code is minder bugs. Je kan die functie dus niet altijd een zinnige foutmelding laten genereren, omdat je lang niet altijd weet waarom die functie is aangeroepen. De bewerking van de functie hoeft namelijk totaal niet duidelijk te zijn voor de gebruiker. Een foutmelding die zegt "Out of diskspace", zegt mij niets als ik als gebruiker als ik alleen probeer een bestandje te versturen via internet. Hoe moet ik weten dat die applicatie het misschien eerst tijdelijk opslaat voordat hij het verstuurd?

[flowerp]

als het niet doet wat het geacht wordt te doen, dan krijg een gratis reparatie of je geld terug. Wedden dat men minder hasst heeft om iets buggy op de markt te zetten.

Inderdaad. 1 reden dat bedrijven telkens gehaast nieuwe versies van software 'moeten' opleveren is omdat de concurrent dit ook doet. Wij zijn b.v. bijna verplicht om -hoogstens- elke 2 maanden een nieuwe versie van de software te leveren die we bouwen. Dit terwijl de huidige versie nog gewoon prima draait voor iedereen. Eigenlijk is het gekkenwerk af en toe.

Als door een wettelijke regeling de concurrent niet meer elke 2 maanden een versie uitbrengt, dan hoeven wij dat ook niet meer en dan hoeft de partij voor wie wij weer een concurrent zijn dat ook niet, etc. Het is een keten die we zelf in stand houden, bang om die klanten kwijt te raken.

Uiteindelijk zal het dan voor ons als developers een stuk relaxter werken zijn, als we in rust een stuk code kunnen bouwen waar iedereen trots op is en dat gewoon in (nagenoeg) alle omstandigheden correct werkt.

[eijckron]

De kwaliteit van software wordt door zeer veel factoren bepaald. Ik betwijfel of professionaliteit van de ontwikkelaars het eerste is waar je aan moet gaan sleutelen.

Het belangrijkste is de driehoek van tijd, geld en kwaliteit die elkaar in evenwicht houden. Wil je meer kwaliteit dan betekend dat in de meeste gevallen meer geld investeren en een langere doorlooptijd. Ik heb al in vele software projecten mee gebouwd en budgetten en doorlooptijd winnen het vaak van kwaliteit. De verhouding van deze facetten wordt vooral bepaald vanuit een business perspectief.

Mijn ervaring is dat de aandacht voor kwaliteit eerder te vinden is bij ontwikkelaars dan bij het management. Ontwikkelaars moeten namelijk tijdens de onderhoudsfase leven met die mindere kwaliteit code.
Of zoals een van de Amiga ontwikkelaars het ooit al omschreef: Programming is like sex, one mistake and you have to support it for life!

[Heathcliff]

Helemaal mee eens. Vaakgenoeg wordt je werk uit handen gerukt terwijl het nog niet af is. Maar het moet opgeleverd worden, omdat een verkoper dat beloofd heeft. En het volgende project ook alweer uitgevoerd moet worden. Als alles (bijna) bug-vrij geprogrammeerd moet worden, dan zou de software vele malen duurder worden en dat willen de klanten weer niet bepalen.

Bij software is het belangrijk om met SLA's te werken: Software License Agreement. Er zullen altijd bugs zijn. Zware bugs, waardoor gebruikers niet meer verder kunnen en lichte bugs, die hooguit een beetje irritant zijn. Met een SLA bepaal je op voorhand wat voor ondersteuning er op software zal worden gegeven in bepaalde omstandigheden. Snellere support is dan gewoon duurder.

En by the way: Die "Licentie" heb ik al; dat is mij HIO diploma!

[flowerp]

En by the way: Die "Licentie" heb ik al; dat is mij HIO diploma!

Jij wel, maar helaas (?) mogen mensen zonder die 'licentie' ook gewoon als programmeur aan de slag.

Een makelaar mag niet zonder licentie z'n vak uitvoeren. Een advocaat mag dat ook niet. Maar een 'programmeur' kan met het grootste gemak de software schrijven die beiden gebruiken voor hun dagelijkse werkzaamheden.

Ergens zit er toch iets een beetje krom...