Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 135 reacties

Door problemen met ict-systemen lijdt de Nederlandse economie jaarlijks ongeveer 1,6 miljard euro schade, zo staat in een zaterdag verschenen onderzoeksrapport. Eerder bleek al uit onderzoek dat de Nederlandse overheid jaarlijks miljarden verspilt aan ict-projecten.

Dat meldt onder andere Z24 op basis van het persbureau ANP. Een onderzoek uitgevoerd in opdracht van ict-bedrijf Sogeti heeft als belangrijkste conclusie dat er jaarlijks 1,6 miljard euro schade wordt geleden doordat ict-systemen hun werk niet naar behoren doen. Het gaat om schade aan de Nederlandse economie, die zowel door overheid, bedrijven als consumenten wordt geleden. Onder andere webwinkels hebben te kampen met economische schade door haperende systemen.

Het gaat dan vooral om softwarefouten die ervoor zorgen dat productie stil komt te liggen of dat het werk op andere manieren wordt beïnvloed. Om aan de schadepost van 1,6 miljard euro te komen werden consumenten en werknemers bij overheid en bedrijven ondervraagd. Het schadebedrag werd verkregen door het aantal uren te tellen waarin het werk stillag, vermenigvuldigd met de gemiddelde kosten die dit met zich meebrengt.

Een parlementaire onderzoekscommissie bracht eerder resultaten van een soortgelijk onderzoek uit. De commissie onder leiding van VVD-Kamerlid Ton Elias concludeerde dat er jaarlijks tussen de 1 en 5 miljard euro wordt verspild aan ict. Dat gaat echter over ict-projecten, waarin schade door fouten in bestaande software waarschijnlijk niet is meegerekend.

Moderatie-faq Wijzig weergave

Reacties (135)

Waarom altijd weer dat negatief sensationele?
Wat ook kan:
Software levert onze economie jaarlijks miljarden euro's op aan efficienties. Als gefocussed zou worden op het verminderen van software fouten, zou dit 1,6 miljard extra opleveren.
Admin-edit:Spelfouten en/of ander commentaar m.b.t. nieuwsposts horen thuis in
Geachte Redactie.

[Reactie gewijzigd door Dirk op 25 oktober 2014 14:25]

Goeie opmerking, het levert ook trouwens een massa's jobs op in dev. Slecht nieuw verkoopt beter als goed nieuws Maarten21 (journalistiek 101 :) )
Toch zit er wel degelijk wat in.

Ik zat al jaren lang in de software development, ben lead developer van een team en wij worden dikwijls ingezet als andere teams er niet meer uitkomen en/of vastzitten met erg lastige bugs of architecturen die niet voldoen.

Ik weet uit ervaring hoe triest het -te- vaak gesteld is met de kwaliteit van software. Dan heb je het over zo veel fouten, zo veel knulligheden, zo veel onbegrip van hoe techniek werkt.

Als je je beseft hoe enorm onze samenleving in al haar facetten op software steunt vandaag de dag, dan is het nog een klein wonder dat het niet veel vaker veel erger mis gaan.

Denk aan verkeersystemen, auto besturingen, banksystemen, nagenoeg elk apparaat wat we tegenwoordig gebruiken tot aan de koelkast toe, communicatiesystemen, stemmachines (in Nederland niet voor niets opgeschort), en alles wat duidelijk meer aan de oppervlakte ligt zoals de web sites die we bezoeken en de apps die we installeren.

Voor zoveel andere dingen in onze maatschappij hebben we zeer strikte regels. Dat kunnen voor dingen zijn die levensbedreigend zijn als ze niet voldoen, zoals bouwvoorschriften voor huizen en bruggen, maar ook meer elementaire dingen als de samenstelling van azijn om maar wat te noemen.

Maar voor software zijn eigenlijk geen regels, en in de huidige vorm van hoe we developen zijn deze ook eigenlijk onmogelijk op te stellen. Waar we in de meeste branches eisen dat er degelijk opgeleide vakmensen zijn, vinden we dat software maar daar elk 15 jarig script kiddie gemaakt moet kunnen worden. Elke keer weer ontstaan er ellelange en vermoeiende discussies over hoe een universitaire opleiding informatie volledig onzin zou zijn, en dat je gewoon JavaScript in 21 days moet lezen en een beetje aan prutsen en dan komt die site er ook wel :X

Gedeeltelijk zijn het ook de tools, talen en frameworks die we gebruiken. Alles is enorm complex, en zelfs de hoogst opgeleide, meest ervaren en meest getalenteerde mensen (waar er *echt* wereldwijd triest, TRIEST weinig van zijn) veroorzaken nog te veel bugs en kunnen in veel gevallen bij lange na niet meer een compleet software systeem overzien.

En software werkt dikwijls zo dat het kleinste foutje wat te snel en te makkelijk gemaakt kan worden al catastrofale gevolgen kan hebben.

Een veel te grote complexiteit van de materie gecombineerd met een veel te laag niveau van de mensen die er mee moeten werken is niet bepaald een optimale combinatie.
offtopic:
soms weet je dat je gedownmod gaat worden :P dit is daar een voorbeeld van, maar hey het moet gezegd worden
Ik in mijn rol als programmeur moet je helaas gelijk geven (toegegeven ik ben niet een van de hoogst opgeleide nog een van de meest ervaren programmeur, maar ik draai al een aantal jaartjes mee). Ik ben het alleen niet eens met jou visie van de oorzaak. Het zijn niet de gebrek aan regels, de toegenomen complexiteit nog de tools of de kennis en ervaring.

De grootste oorzaak van problematiek rondom software is de programmeur en hoe bedrijven zich organiseren rondom programmeurs. Hier zijn mijn argumenten hiervoor:

Programmeurs veroorzaken dit probleem om veel redenen hier zijn in mijn ogen de vier grootste. Programmeurs zijn de kennis dragers van de software en bepalen daarmee de software. Dit heeft een groot aantal risico's. In de kern vindt bijna elke programmeur het belangrijker om te begrijpen hoe een functie werkt en dus iets van scratch af aan te bouwen i.p.v. iets off the shelf te pakken of aan te schaffen. Daarnaast integreren programmeurs vaak features die wel wat aan de software toevoegen maar niet iets wat van oorsprong in de software hoorde te zitten. Het laatste argument dat ik voor deze stelling aandraag is dat software programmeurs vaak de kennis en ervaring missen van wat het eind product moet zijn, hierdoor maken programmeurs over het algemeen de code veel te complex omdat ze niet goed genoeg weten wat belangrijk is en wat niet. Programmeurs zijn gewoon niet goed in communiceren, sterker nog ze zullen het vermeiden waar ze de kans krijgen. Documentatie, nou dat zien ze als een straf. Het managen van verwachtingen zijn ze niet goed in (ze zijn techneuten geen bedrijfskundigen). Op verzoek kan ik meer argumenten aanleveren ;)

De organisatie rondom programmeurs veroorzaken het probleem omdat deze vaak niet in kunnen grijpen omdat ze simpel weg de kennis er niet voor hebben. Als organisatie proberen ze winst te maken. Dit heeft als gevolg dat er gekeken wordt naar het is software het is iets met wat wij doen (databases of control systems) dus wij kunnen het. Vervolgens gaan deze met een algemene beschrijving terug naar hun programmeurs die hier een uren inschatting op maken en dit wordt dan als offerte gestuurd naar de klant. Een gedegen voor onderzoek is te duur omdat je als bedrijf het risico loopt dat na een voor onderzoek ze je niet kiezen en dus een grote kosten post hebt. Daarnaast weten de organisaties niet hoe ze duidelijke meet palen moeten zetten tijdens software ontwikkeling. Ze willen bijvoorbeeld wel het V-model hanteren, echter dit vraagt tijd van zowel managment als programmeurs en levert niet veel op, dus bij de eerste vorm van druk gaat dit de deur uit. (zo wordt een URS vaak niet gemaakt, is het FDS en SDS 1 document, module en integratie testen worden over geslagen en het FAT en SAT document zijn zo algemeen dat de hele installatie af kan branden om zo alsnog een goedkeuring te krijgen). Daarnaast programmeurs die binnen een organisatie hier verbeteringen op aan willen brengen betreft kennis architecturen of kwaliteits meetpunten in ontwikkeling willen toevoegen worden afgebrand door hun collega's en door hun managers gezien als lastig, vervelend of niet flexibel genoeg. Om vervolgens vervangen te worden door iemand die net van school af komt.

Ik kan nog veel meer argumenten aandragen maar ik ken een geniaal boek die het allemaal voor je op een rijtje zet.

Betreft jou argumenten voor de programmeer kennis en ervaring van de programmeurs: Regels toevoegen heeft alleen zin als regels ook nageleeft worden. Architecturen kiezen en gebruiken heeft alleen zin als je de voor en nadelen van de architecturen kent. Ik heb nog geen organisaties op het gebied van programmeren gezien die hierin tijd of energie wil steken. In elke regel code die geschreven wordt kan 1 tot en met 100 bugs zitten. Minimaal 20% van elke software applicatie genereert bugs, het fixen van de bug heeft ook weer een 20% kans van het introduceren van een nieuwe bug. Dit is onafhankelijk van de kwaliteit van de programmeur en er zijn door IBM hele studies over verricht. The tool does not save you, lees voorgaande argumenten. De complexiteit heeft te maken met een gebrek aan kennis van het probleem en niet van programmeren. En de laatste als er een manier zou zijn om bugs te voorkomen hadden wij als programmeurs er allang een antwoord op gevonden.

Edit:
Hier vindt je een effectieve methode voor het verbeteren van software kwaliteit die bedrijfstechnisch gezien wordt als te duur en dus niet gehanteerd wordt.
Hier worden een aantal development mytes waar programmeurs in geloven aan de kaak gesteld.
Hier vindt je informatie hoe een organisatie zou moeten functioneren rondom software engineering / activiteiten waarvoor een programmeur van systemen vaak geen tijd voor krijgt bij het ontwerp van software.
Hier vindt je een website met intressante onderzoeken. Hier heb ik ook die 20% bug introductie vandaan.

[Reactie gewijzigd door _wolf_ op 25 oktober 2014 22:57]

In de kern vindt bijna elke programmeur het belangrijker om te begrijpen hoe een functie werkt en dus iets van scratch af aan te bouwen i.p.v. iets off the shelf te pakken of aan te schaffen.
Dit is een bekend probleem. Er zijn diverse oorzaken voor. Het not-invented-here syndrome is er eentje van, en in het verlengde daarvan gewoon je eigen plasje over iets willen doen (een gebruik waar niet alleen programmeurs niet vies van zijn).

Maar het gaat dieper.

Programmeurs zijn ook lui, en waarom helemaal de moeite doen en iets van scratch te bouwen met alle moeite en het gedoe van dien? Je zegt het eigenlijk al; een programmeur vindt het belangrijk om te begrijpen hoe iets werkt.

En DAAR zit dus een deel van het probleem. In plaats van gedeeltelijk te ontkrachten, bevestig je eigenlijk precies mijn stelling ;) Deze is namelijk dat de huidige manier waarop we code te complex is. Kennelijk is het dus niet mogelijk om een bestaande functie (snel) te doorgronden!

In geval van open source: code leest te moeilijk, ook voor heel ervaren mensen. Ik heb dit laatst nog gehad. Een graph cloner voor een bepaalde domain object graph. 8 of 9 classes, met diverse methods die zeer grote blokken code bevatten met diverse loops. Mijn eerste instinct is dan ook inderdaad; hoe moeilijk kan dit zijn? Ik schrijf het wel van scratch. Dit gaat me uren kosten om te begrijpen wat precies de gedachte gang van de programmeur was die dit allemaal schreef.

En dit was Java code, en ik programmeur in Java sinds 1996, dagelijks... en daarvoor deed ik C++, dagelijks, wat een vrij gelijke syntax ken. Ik schrijf sneller requirements in code dan in natuurlijke taal.

Dan heb je tal van methodieken om dit allemaal beter in te richten. Dingen als simpele maar zeer heldere variable namen. Een maximale branching factor (cyclomatic complexity), je method names in geval van OOP logisch ordenen in een class, liefst zodat ze van boven naar beneden in lifecycle order lezen, etc etc.. Clean Code van Uncle Bob bevat veel van dergelijke tips.

Maar toch... je moet al al deze dingen erg goed beheersen, zeer veel ervaring hebben om het correct toe te passen, en dan NOG blijft het lastig om bestaande code te lezen, en ja dan gaat men het herschrijven.

En de volgende programmeur, die leest jou code weer, snapt het niet volledig en gaat het WEER herschrijven.

Blijkbaar is er OOK in de meest high-level languages een disconnect tussen het menselijk mental modal, en de syntax en structuur van code.

WE SNAPPEN HET SIMPELWEG NIET GOED GENOEG!

Dit is een erg fundamenteel probleem.

Mensen met veel ervaring inzetten, veel best practices volgen, tools inzetten als checkstyle en findbugs etc zijn allemaal doekjes die dat een beetje verhelpen, maar het fundamentele probleem niet verhelpen.

Overigens is the inmates are running the asylum idd een klassieker ;)
offtopic:
Kijk aan iemand om mee te sparren :P
Je hebt een goed argument, al denk ik dat deze net zo relevant is: Organisaties zijn nu zo ingericht dat de verantwoordelijkheid van een software product volledig op de schouders ligt van een programmeur.

Projecten van 200 tot 10000 uur worden op de schouders van programmeurs gelegd. Wij programmeurs zijn goed in ons werk maar niet zo sterk in communicatie. Dus om te voorkomen dat we in situaties komen waarbij we in de problemen komen en dus moeten gaan communiceren zoeken we zekerheden. Code erven is geen garantie dat de code volledig zal werken of dat dit geen problemen introduceert in je huidige project. Deze onzekerheid is de reden juist waarom programmeurs het liefst gelijk in de code duiken en alles opnieuw bouwen. Heel simpel als ze begrijpen hoe het werkt dan kunnen ze ook met zekerheid zeggen dat het werkt (denken ze). Dus in mijn ogen is het geen kwestie van competentie op het gebied van programmeren, maar het durven geven van garanties op werk van anderen.

Dat gelijk in de code duiken en gelijk naar implementatie gaan, is het geen wat juist vaak dit soort problemen veroorzaakt. ja we schrijven sneller code dan documentatie echter daardoor mis je wel een essentieel onderdeel van je ontwerp proces en ben je erg geneigd om een spiral design model te gaan volgen. Natuurlijk valt dar wat voor te zeggen en het heeft ook zeker zijn voordelen. Mijn grootste bezwaar hierbij is vaak dat het ontwerp niet natuurlijk volgt uit de vereiste functionaliteit en er een mis match ontstaat tussen het mentale model van de programmeur en de gewenste functionaliteit. Dit heeft niets met de complexiteit van software te maken of met de kunde van de programmeur die hier iets mee moet. Dit heeft te maken met een slecht ontwerp proces. Waardoor zelfs gestructureerde code voor een buitenstaander ongestructureerd lijkt en vol lijkt te zitten met overbodige functionaliteit.

Laatst ook, een simpel model voor een recept generator met ongeveer 10 tot 12 classes. Tijdens ontwikkeling is er nooit gekeken van wat moet er precies gemaakt worden en hoe past het probleem nu in het grotere plaatje. Gevolg objecten zijn al 100x aangepast, namen non descriptive en architectuur die je niet echt bij een abstract factory zou verwachten (de kick the watchdog method bijv, lijkt method die als watchdog voor een watchdog object ingezet kan worden maar deze hield bijv ook indirect als watchdog netwerk communicatie in de gaten, maar waarom zit er een watchdog in een abstract factory?). Nu komt er een andere software engineer deze ziet een bug en code en kan dat moeilijk herleiden naar functionaliteit. Hij krijgt 2 uur om de bug op te lossen. Gevolg deze software engineer gaat op eigen houtje classes herschrijven aanpassen en uitbreiden om de bug op te lossen. Dit noemen we in ons bedrijf bloemkool software (komt telkens wat bij). Uiteindelijk is hij 3 dagen verder heeft hij 10 nieuwe bugs geïntroduceerd die ik tot net toe nog zat op te lossen, door weer exact dezelfde fout te maken als die programmeur omdat deze software eigenlijk gewoon een redesign nodig heeft.

Vervolgens moet deze zelfde programmeur 8 bugs oplossen in tracking systeem waarbij er 27 classes zijn. Hoewel dit initieel veel ingewikkelder lijkt, is het ontwerp naar de functionaliteit van het systeem. Gevolg, de bugs opgelost in 2 classes in een fractie van de tijd bij het recept generator, en daar hoef ik dus niet mn weekend mee te vullen. Het initiele ontwerp van de software is beter, simpel weg omdat bij het laatste project er eerst meer tijd besteed is aan: Wat is het probleem? Wat moet de software doen? Wat zijn de fysieke eigenschappen van het systeem? Hierbij krijg je code die veel dichter bij het mental model van een normaal mens komt en daarbij leesbare code omdat de code gebaseerd is op classes en objecten die functionaliteit uit de realiteit over neemt.

DISCLAIMER: Dit maakt code leesbaarder, natuurlijk is er wel een basis niveau aan kennis nodig. Plus natuurlijk worden grotere projecten complexer, echter op het moment dat een programmeur het niet kan lezen moet je een redesign overwegen ipv een locale aanpassing en natuurlijk is dit ook niet de heilige manier van oplossen en loop je in de praktijk ook tegen problemen aan.
Dus in mijn ogen is het geen kwestie van competentie op het gebied van programmeren, maar het durven geven van garanties op werk van anderen.
Maar ook dit grijpt weer terug op de essentie van hoe we programmeren.

Waarom zouden mensen deze garantie moeten durven te geven op het werk van anderen? Waarom is deze garantie niet af te lezen uit de code zelf?

Er bestaat wel degelijk het concept van formal correctness proofs, alleen deze zijn opzich zelf met de huidige middelen dan ook weer veels te complex om practisch toe te passen. Je ziet dit eigenlijk alleen gebeuren voor algoritmes die voor extreme omgevingen gebruikt moeten gaan worden (denk kerncentrale toepassingen, ruimtevaart, etc). En zelfs DAAR gaat het fout!

Embedded (b.v. via annotations) assertions en constraints op code gaat al een stukje de goede kant op (voor hele simpele gevallen denk b.v. aan @NonNull, @NonEmpty etc op variables en return values), maar we zijn er nog lang niet.
we schrijven sneller code dan documentatie echter daardoor mis je wel een essentieel onderdeel van je ontwerp proces
Maar als de bedoeling van code in de eerste instantie helderder en more consise zou zijn, dan was documentatie helemaal niet nodig!

Sterker nog, documentatie is JUIST een ENORME bron van bugs!

Het probleem is namelijk dat documentatie in de regel eigenlijk altijd achterloopt. Men past de code aan, maar 9 van de 10 keer vergeet men dat er ergens anders documentatie was die nu verkeerd is. Of helemaal erg, men copy/paste code, past wat aan, en laat de oorspronkelijke embedded documentatie (b.v. in Java de JavaDoc) staan. Deze documentatie klopt nu echter totaal niet meer. Je wilt niet weten hoe vaak, hoe gruwelijk vaak we dat tegenkomen in code bases die we moeten cleanen.
Dit heeft te maken met een slecht ontwerp proces.
En slechte en niet duidelijke requirements. Bij het klassieke waterval model was dit natuurlijk helemaal een ramp, waar de requirements eigenlijk in een final versie opgeleverd worden, dan er een final design kwam en dan pas met code werd begonnen.

Eigenlijk wist men dan al lang al dat de requirements ondertussen compleet veranderd waren, maar ja... het process he? Het process zei dat er niets meer veranderd mocht worden, dus pech! Maar lekker gaan implementeren en met het volgende produkt doen we het dan wel weer goed.

Maar ook met zeer korte iteraties (i.e. 2/3 weken zoals bij Scrum) gaat dit net zo goed fout. "Men" weet namelijk ook niet precies wat ze nou willen, en veranderd vaak van mening. Ene sprint gaan we focussen op het verwerken van de geld stromen, andere sprint moet dat er toch maar weer uit want money is toch evil, en dan de volgende sprint maar weer erin want hey, we hebben toch ook inkomsten nodig.

Ook hier blijkt weer dat eigenlijk de huidige best practice processen ook helemaal niet zo super werken. Ik voorspel dat zoals we nu met minachting op waterfall terugkijken, men over 10 jaar met minachting terug kijkt op Scrum, als het volgende best practice process is uitgevonden.
Hierbij krijg je code die veel dichter bij het mental model van een normaal mens komt en daarbij leesbare code omdat de code gebaseerd is op classes en objecten die functionaliteit uit de realiteit over neemt.
Inderdaad, dit is een belangrijk ding. Ik voer b.v. vaak als regel in dat de namen van domain classes MOETEN overeenkomen met het daadwerkelijke domain. Heet iets in de UI "Car", dan MOET de bijbehorende page (indien het een web UI is) /cars zijn, en indien er een id doorgegeven moet worden car_id, en de bijhorende class Car zijn, etc.

Vaak zie je mensen die dit niet snappen. Car in de UI wordt dan opeens een page /auto, een id wordt amid (automobile id), en de class heet dan opeen MotorVehicle.

Kortom, men doet eigenlijk maar wat en gebruikt een naam die gewoon ter plekken in ze opkomt, zonder te kijken of er voor een concept al een bepaalde term in gebruik is.

In een erg extreem geval heb ik ooit een software systeem moeten cleanen waarbij er een klein handboekje (10 bladzijden) met tabellen was die termen bevatten met daarbij alle alternatieven variable namen die in de code voorkwamen. Daar had je sommige termen bij die meer dan 10(!) totaal verschillende namen in code hadden. En dan had je nog overlappende namen ook. Dus in het voorbeeld boven was "vehicle" dan een alternatief voor "car" (en een -direct- alternatief, niet als een super class!), maar "vehicle" bestond ook en dat was wat anders als een "car", maar... een alternatief voor "vehicle" was... "car"! En dan als echt alternatief ook, niet in de betekenis van sub class!

Deze naamsverwarring bleek na een lange analyse een enorme bron van bugs en tijdsverspilling (en dus geld) te zijn.

Programmeurs bleken continu de namen door elkaar te halen. Dan werd er b.v functionaliteit voor een Car geschreven, en dan nog gecontroleerd ook of Car daadwerkelijk een Car was (door b.v. 4 lagen diep de variable te volgen), maar ja, dan ging het uiteindelijk toch weer fout na dagen van programmeren want helemaal down in de DB bleek het dan toch om een Vehicle te gaan.

Er zo waren er nog veel meer onzinnige dingen in de code alleen al qua namen (kan er een klein boekwerk over schrijven waarbij The Daily WTF! verbleekt).

[Reactie gewijzigd door flowerp op 26 oktober 2014 14:37]

Aha, met documentatie bedoel ik: het definieren van requirements en use cases om vervolgens op basis hiervan een architectuur te kiezen en de variabele benamingen (classes, objects, constructs en interfaces). Om dit vervolgens ook te hanteren en op te volgen en waar nodig bij te werken.

Deze documentatie is vaak een bron van fouten omdat de programmeur er voor kiest om af te wijken hiervan zonder het bij te werken. Dit zou je kunnen scharen onder de kennis en ervaring van de programmeur. Echter wat ik om me heen zie bij meerdere software bedrijven is dat het de instelling is van de programmeur.

Wat ik probeer aan te tonen is correlatie vs causaliteit. Dat er een correlatie is ben ik volledig met je eens. Echter in mijn ogen is er geen sprake van causaliteit. De kunde en ervaring wordt wel duidelijk wanneer een programmeur de implementatie niet begrijpt. Hierbij maakt de programmeur dus een ontwerp op aannames en verwachtingen in plaats van use cases. De oorzaak ligt in mijn ogen bij de implementatie kennis van het eindproduct. Het ontwerp hoort logischerwijs uit de implementatie kennis te volgen, waar mits gedisciplineerd mee gewerkt er leesbare code uit volgt.

Zwart wit kijkend: Als ik software schrijf voor een medische toepassing weet ik zelf vaak ook niet genoeg af van de toepassing zelf. Dit zou mij moeten triggeren om juist dan meer tijd en energie in use cases te moeten steken om de functionaliteit van het product te achterhalen. Wanneer ik hier niet de tijd en ruimte voor krijg moet ik aannames gaan maken en ga ik uit van wat ik weet. Hierdoor kan het voorkomen dat ik ontwerp fouten in functies maak en ook fouten in benamingen. Dit wordt nog eens versterkt als iemand anders met een andere achtergrond dezelfde code gaat revieuwen en de code gaat uitbreiden of bugs moet fixen. Uiteindelijk krijg je onoverzichtelijke code omdat de code gewoon te ver af zal liggen van de implementatie. Maakt dat mij of mijn collega een slecht programmeur? Mijn antwoord op die vraag is, misschien maar niet om die reden.

Om mijn punt verder te verduidelijken trek ik het in extreme. Als alle programmeurs absolute specialisten zijn en alle programmeertalen voor 100% zouden beheersen, zijn dan alle problemen hiermee opgelost? Ik beargumenteer hierbij van niet, simpel weg omdat ik denk dat er veel meer speelt dan alleen de kunde van de programmeur. Wat ik begrijp van jou is dat jij denkt van wel. Dus wij zijn het op dit punt oneens met elkaar, en dat is ook precies het probleem van de gehele industrie. Er is nergens een rechte lijn getrokken van zo moet het. Daarin heb jij volkomen gelijk.
Het systeem moet gewoon logisch en modulair in elkaar zitten. Dan kunnen programmeurs klooien wat ze willen, maar als het niet goed is trek je de module er gewoon uit en vervang je die door een van een andere programmeur.

Als het zo niet werkt, dan heeft de systeemarchitect een fout gemaakt, niet de programmeur.

Schuif dus niet alle schuld af op de programmeurs.
Lol dat doet zij niet, dat doe ik. Ik zie dat ik de variabele "programmeur" niet goed omschreven heb. Voor de zekerheid definieer ik het probleem nu dubbel, een antwoord voor programmeurs en een voor management.

Management samenvatting
Discussie: Het vinden van oorzaken en gevolgen van het feit dat software engineering een relatief nieuw vakgebied is. Dit is niet het wijzen van vingers, dit is kijken naar de oorzaak van het probleem en filosoferen over hoe de industrie dit beter op zou moeten pakken.

Stelling van flowerp: De meerderheid van software engineers stoppen vaak na hun studie met het uitbreiden van hun kennis, en doen dan ervaring op in organisaties waarbij ze al binnen komen als kennis dragers.

Stelling van _wolf_ : De meerderheid van software engineers zijn goed genoeg in hun kennis betreft codering maar de organisatie structuur die nu bestaat is niet afdoende om te compenseren voor de natuurlijke bias van programmeurs.

Huidige progressie: Beiden partijen hebben erkent dat de problematiek op beiden punten al zijn ze nog niet helemaal overtuigd betreffende de argumentatie van elkaar. Op een ding zijn ze het zeker eens, er is een wijziging van de manier van werken nodig waarbij er nog geen concrete stappen zijn gedefinieerd.

Programmeur uitleg
DISCLAIMER NEGEER DE SYNTAX ERRORS
/* Blame function */

/* Define parameters */
bool FlowerpHeeftGelijk = FALSE;
bool WolfHeeftGelijk = FALSE;
string Programmeur [3] = (Software Architect, lead engineer software, senior/medior/junior software engineers);
string Organisatie [5] = (Project manager, Client manager, sales, marketing, quality control);
string Reason();
string Blame[i];

/* twee if statements die ieder het zelfde probleem vanuit een ander perspectief belichten waardoor er een andere oorzaak ontstaat */

if (FlowerpHeeftGelijk = TRUE) // Dames gaan voor
{
Reason="Er is simpel weg te weinig kennis aanwezig op het gebied van software engineering. Dit is een relatief niet vakgebied waardoor in tegenstelling tot andere vakgebieden zijn er te weinig vaste conventies om aan vast te houden. Als je dit bijv. vergelijkt met bouw, een vakgebied wat al meer als 2000 jaar oud is en waar een goed gedefinieerde structuur regelementen en opleidingen voor aanwezig zijn.";
Blame = (Programmeur[3]);
}
if (WolfHeeftGelijk = TRUE)
{
Reason = "Problematiek zit hem in hoe software engineers naar de wereld kijken en hoe ze problemen oplossen. Daarnaast ligt het probleem hierbij vaak dat ze een natuurlijke bias hebben naar zekerheid echter deze vervalt vaak onder druk waardoor er te snel en ondoordacht gewerkt word, dit in combinatie met hoe we dingen organiseren. De traditionele aanpak van engineering past hierbij niet omdat de ervaring en kennis bij de low level programmeur ligt.";
Blame = ("Programmeur[0]","Programmeur[1]","Programmeur[2]","Organisatie [0]", "Organisatie [1]","Organisatie [2]");
}
printf("Reason", "Blame") ;

[Reactie gewijzigd door _wolf_ op 26 oktober 2014 13:42]

[...] als het niet goed is trek je de module er gewoon uit en vervang je die door een van een andere programmeur.
Oh, was het maar zo makkelijk. Was het maar zo makkelijk...

Theoretisch heb je wel gelijk, en 1 van de velen eerdere doekjes die ik noemde om de complexiteit te beheersen is inderdaad modulariteit. Een goede gelaagdheid, en het verminderen van onnodige koppelingen (het bekende mantra: high cohesiveness, low coupling) kan inderdaad helpen om bugs beperkt te houden en te isoleren.

In de praktijk weten we helaas nog niet helemaal hoe echt goed te modulariseren. Het in de Java wereld bekende osgi zou een van de parade paartjes moeten zijn op dit gebied en de IDE/Platform Eclipse het voornaamste demonstratie product.

Maar Eclipse is zo onstabiel en buggy als maar kan. De HAAT, de PURE HAAT tegen Eclipse wordt met de dag groter. En wat wil je? Als je midden in je werk zit en Eclipse het opeens weer nodig vindt om een dialog box te tonen out of the blue met "Read beyond Widget stream (-1)", en de boel opeens niet meer reageert. Of als een Maven project opeens gewoon niet wilt builden (en dat dat je dan uren bezig bent om te zoeken naar een oorzaak die er gewoon niet is, want als je Eclipse alleen maar restart doet ie het opeens weer wel) etc etc.

Het is een bekende angst in de Eclipse wereld - 1 verkeerde plug-in (osgi module) kan je hele omgeving slopen. En -dat- is dan het neusje van de zalm op gebied van modulariteit? Waren modules niet juist uitgevonden om dit soort problemen te voorkomen?

Daarbij komt nog dat terwijl modules en abstractie lagen de boel lokaal behapbaarder kunnen maken, ze het grote plaatje juist weer (veel) complexer kunnen maken. Iedereen kent wel de grappen van Spring met z'n AbstractFactoryFactoryDecorator. Op een gegeven moment zie je door de bomen het bos niet meer en ben je eigenlijk juist weer verder van huis, en gaan mensen je mooi ontworpen architectuur links laten leggen en opzoek naar eenvoudigere oplossingen. Mooi voorbeeld, het aloude EJB 1 & 2, wat gebasseerd was op het nu weer actuele idee van micro-services en waarbij ALLES een remote component was voor maximale ontkoppeling en waarbij alles voortdurend "gemapped" moest worden omdat je nooit iets voor waar kon aannamen en altijd alles anders en veranderd en aangepast zou moeten kunnen worden.
Als het zo niet werkt, dan heeft de systeemarchitect een fout gemaakt, niet de programmeur.
Ik geloof niet zo in super slimme systeemarchitecten die vanuit een ivoren toren lopen te architecten en dan domme programmeurs die als een robot zo'n architectuur moeten gaan uitprogrammeren.

Of de architect leeft volledig in z'n eigen wereld en heeft geen enkele kaas gegeten van de daadwerkelijk technieken, of de architect is eigenlijk gewoon een lead developer en programmeert in z'n eentje het hele systeem, maar in een abstracte taal. Het uitprogrammeren daarvan is dan gewoon voor menselijke compiler spelen.

In beide gevallen een beetje dom.
"Het laatste argument dat ik voor deze stelling aandraag is dat software programmeurs vaak de kennis en ervaring missen van wat het eind product moet zijn, hierdoor maken programmeurs over het algemeen de code veel te complex omdat ze niet goed genoeg weten wat belangrijk is en wat niet. Programmeurs zijn gewoon niet goed in communiceren, sterker nog ze zullen het vermeiden waar ze de kans krijgen. "

Als een tester kan ik dit beamen. Ik moet vaak de brug spelen tussen de business en de devs uit mijn team. De devs gaan gelijk helemaal los in technische oplossingen, en ik moet ze steeds vragen 'waarom doe je dit', of 'wat is de waarde voor de business?'. Het kost heel veel energie om dit te doen, maar uiteindelijk is het de moeite waard.

En als tester is het ook vaak mijn nachtmerrie als de dev weer eens alles heeft refactored. Weer allerlei gekke fouten op gekke plaatsen.

Test Driven Development lijkt deels een antwoord, maar zal ook niet al het menselijk falen kunnen opvangen, omdat je simpelweg niet alles kan testen. Daar is geen tijd voor.

Toch zouden we 'langzamer' moeten gaan programmeren en meer tijd inruimen om unit tests en integratie tests te schrijven. En de tester moet daarnaast nog los kunnen gaan met exploratory testen e.d. Helaas wil de business altijd snel nieuwe functionaliteit en begrijpen ze niet dat er onder de facade van de frontend een berg rotzooi code verstopt zit.

Ik vind het zo frustrerend dat 1 regel foute code al voor een enorme berg ellende kan zorgen.

Aan de andere kant houdt het dit vakgebied zeer interessant :P
En als tester is het ook vaak mijn nachtmerrie als de dev weer eens alles heeft refactored. Weer allerlei gekke fouten op gekke plaatsen.
Het is een twee zijdig zwaard. Soms denk je van waarom was het nu in godsnaam nodig om de boel overhoop te halen? Aan de andere kant is voortdurende refactoring (mits GOED gedaan) een noodzaak om de boel begrijpbaar en onderhoudbaar te houden.
Test Driven Development lijkt deels een antwoord, maar zal ook niet al het menselijk falen kunnen opvangen, omdat je simpelweg niet alles kan testen. Daar is geen tijd voor.
Dat komt omdat de testen voornamelijk steek proeven zijn, en er dus op die manier nooit een garantie te geven is dat het ook voor alle situaties werkt.

Met een formal correctness proof geef je die garantie WEL, maar zo'n proof kan bijna niemand opstellen. Dat is vrij zware wiskunde in de regel en een volledige andere skill dan wat jij waarschijnlijk met je testjes doet, wat meer een softere alpha skill dan een kei harde beta skill is.
Toch zouden we 'langzamer' moeten gaan programmeren en meer tijd inruimen om unit tests en integratie tests te schrijven.
Langzamer en zorgvuldiger programmeren zeker, maar inderdaad, "men" wil steeds meer en meer voor minder en minder. De huidige afraffel methode van software vindt men nog te duur. Dus outsourced men alles naar India die het zo mogelijk NOG meer afraffelen en zelfs DAT vindt men dan nog te duur!

Er is een grote disconnect tussen de enorme moeite en een enorme kunde die software schrijven vereist, en wat men vindt dat het waard is (even afgezien van wat het daadwerkelijk waard is, dat is wat anders). Maar als men zelfs vindt dat niet opgeleide mensen, in sommige gevallen halve zwervers die letterlijk voor een appel en een ei werken nog te duur zijn, dan kun je alleen maar concluderen dat "men" de software dus echt helemaal niets waard vindt.

Overigens is het schrijven van unit testes die DAADWERKELIJK zinvol zijn nog een hele kunst. Ik heb systemen gezien met duizenden unit tests, waarbij er in de praktijk af en toe bugs optreden (zoals bij elk systeem), maar waarbij nooit, maar dan echt helemaal nooit, een unit test een bug heeft aangetoond.

Hoe kan dit? Toeval? Stom toeval? Of schrijft men gewoon DOMME tests?

Wie test er dan dat een test niet DOM is? Dat een test ECHT wat bijdraagt?

B.v. een getter/setter testen. Een beetje code base (in Java) heeft 10.000'en van die dingen, dus kun je ook makkelijk 10.000'en tests hebben, die lekker altijd passen (geeft je een nice and cosy feeling), maar die in de praktijk eigenlijk gewoon helemaal geen nut hebben.

Of een SQL insert naar een DB doen en dan terug lezen dat de insert gelukt is. Wat test je dan helemaal? Je DB driver? Je DB zelf? Zoiets gaat eigenlijk gewoon nooit fout door een bug.

Ja, de test ligt er wel eens uit, maar dan is de test DB net even down! Dus krijg je allemaal failed tests opeens, restart iemand zuchtend de test DB en is alles weer groen. Zijn die tests dan bedoeld als monitoring of de test DB nog wel up and running is? Maar die test DB is er toch alleen om de testen te runnen? Wat schiet je daar mee op???

Etc.
Dat komt omdat de testen voornamelijk steek proeven zijn, en er dus op die manier nooit een garantie te geven is dat het ook voor alle situaties werkt.

Met een formal correctness proof geef je die garantie WEL, maar zo'n proof kan bijna niemand opstellen. Dat is vrij zware wiskunde in de regel en een volledige andere skill dan wat jij waarschijnlijk met je testjes doet, wat meer een softere alpha skill dan een kei harde beta skill is.
Was die alpha/beta 'testjes' sneer nou echt nodig? Dat was het punt helemaal niet.

Gegeven dat je in korte tijd de business moet informeren over de status van het product wat je voor hen bouwt, moet je keuzes maken. Leuk dat je een correctness proof kan doen, dat gaat in de praktijk niet gebeuren.

Ja refactoren is nodig, maar als een dev dat doet, vervolgens niet eens het fatsoen heeft om zijn eigen changes na te lopen en het bij de tester dumpt, kan je wel zeggen dat het een kleine nachtmerrie is.

Ik proef verder wat frustratie in je post, lijkt het wel...naar testers, of zelfs het nut van testen (?), maar ook naar hoe men omgaat met software ontwikkeling.

Ik zie het zelf zo: als team doe je zo goed mogelijk je best om mooie software te maken voor je klant. Daar heb je devs, testers en de business voor nodig, verschillende soorten mensen. Samenwerken, teamgevoel, de klant er constant bij betrekken. Als de software uiteindelijk doet wat de klant wil, ben ik blij; ook al zitten er foutjes in. Als je er maar het beste van maakt in de korte tijd die je hebt als team.

Ik ben benieuwd wat de toekomst brengt voor ons vakgebied. Of het ooit mogelijk gaat zijn 'perfecte software' te maken....
Was die alpha/beta 'testjes' sneer nou echt nodig? Dat was het punt helemaal niet.
Het was niet de bedoeling om jou of wie dan ook omlaag te halen. Sorry!

Waar het om gaat is het grote plaatje. Natuurlijk doet iedereen z'n best en zijn het de beste tools die we hebben, maar het is allemaal erg primitief.
Leuk dat je een correctness proof kan doen, dat gaat in de praktijk niet gebeuren.
Precies, en dat is dus ook mijn punt. Dat is keiharde beta, ondoorgrondelijke wiskunde die vrijwel niemand snapt, en zelfs voor die paar mensen die het snappen is het een vrij vermoeide klus. Die proofs zijn dus ook niet te doen in de praktijk. Dat is voor een klein stukje code die je schrijft en waarvan je ervan uit gaat dat ie jaren lang niet zal veranderen (en als je er ook maar het minste ding aan die code veranderd moet je de hele proof weer overniew gaan doen).
Ik proef verder wat frustratie in je post, lijkt het wel...naar testers, of zelfs het nut van testen (?), maar ook naar hoe men omgaat met software ontwikkeling.
Inderdaad. Ik ben een 8:00 tot 24:00 development lead, test schrijver en wanneer het uitkomt zelfs operations (heel andere discipline weer). Natuurlijk ben ik gek van mijn vak anders zou ik het niet blijven doen, maar de manier waarop we developen en testen moet gewoon nog zo veel beter kunnen.

Neem b.v. Selenium tests die de web UI testen. 1 van de meest high-level vormen van testen. Die blijven relatief lastig om te schrijven en er hoeft maar iets in de UI te veranderen en die testen moeten weer allemaal handmatig aangepast worden. Ik zou niet precies weten hoe, maar je voelt gewoon dat daar nog veel ruimte is voor verbeteringen.

Of het ooit 'perfect' gaat worden is moeilijk om te beantwoorden, met name omdat onze definitie van 'perfect' steeds veranderd, maar ik weet bijna zeker dat men over 50 jaar terug kijkt naar deze tijd en meewarig zucht hoe wij in 2014 zaten te rommelen met onze "testjes" (en bedenk; ik schrijf dus zelf ook van die "testjes" ;) )
Dat was ook precies mijn gedachte. Het is een erg verwrongen manier van naar dit soort economische factoren kijken.

Dit truukje wordt trouwens vaak toegepast, niet alleen in tech. Ook als het bijvoorbeeld over natuurverschijnselen gaat wordt nogal makkelijk vergeten dat we ook eten en ademen dank zij die natuur en gedaan alsof de natuur een kostenpost is.
Wordt ook erg moe van deze berichten. Snap niet waar dit ineens allemaal vandaan komt. Maar goed denk dat er zeer zeker veel jobs opleveren. Maar de andere kant van het geheel is waarschijnlijk dat er meer zijn verdwenen. Meerdere keren heb ik het zien gebeuren dat ik ergens kom dat ik pakket schrijf om het ze makkelijker te maken. Het proces te versnellen en ineens zijn er minder mensen nodig voor hetzelfde werk.

Maar goed 1,6 miljard klinkt als een hele hoop maar vraag me af hoeveel er mee wordt verdient. Ik gok dat dit een druppel op een hete plaat is.
Waar het vandaan komt? Dat lijkt me nogal duidelijk: Sogeti staat bekend om z'n kwaliteit in het testen, oftewel: een onderzoek in opdracht van Sogeti om de sales van de Sogeti testafdeling een boost te geven. Niet noodzakelijkerwijs van invloed op de kwaliteit van het onderzoek, maar natuurlijk wel op de onderzoeksvraag: het eenzijdige aspect "wat kost gebrek aan softwarekwaliteit" tegenover "is het kostentechnisch interessant om meer te testen en daarmee de kosten van softwarefouten omlaag te brengen". Overigens verwacht ik dat ook op die tweede vraag het antwoord nog positief zal zijn.
Nee dit is nog een reactie op een parlementaire enquête. Tijdens de enquête is met de volgende externe bedrijven gesproken:
  • KPN
  • Ordina
  • PBLQ
  • Logica
  • VIAgroep
  • Hewlett Packard
  • BdBProjectmanagement
  • Wigo4it
  • Rathenau Instituut
  • AME Research
  • IBM
  • Kahuna
  • Dell
Met daarnaast zowel nederlandse als engelse overheids afdelingen / universiteiten. Gewoon de bronnen volgen en je komt automatisch toch weer uit bij de parlementaire enquête.
Volgens welke bronnen dan? DE bron (https://www.sogeti.nl/updates/nieuws/softwarefalen-leidt-tot-¤16-miljard-economische-schade) van het nieuws rept gewoon van een eigen onderzoek van Sogeti uitgevoerd door Pb7, en sluit af met een promo-quote voor het vernieuwde TMap dat participatie van eindgebruikers centraal stelt.
offtopic:
Ik neem aan dat je met 16 miljard, 1,6 miljard bedoelt


Als ik de links in het artikel volg kom ik uit op:

We beginnen bij de eerste link:
http://www.z24.nl/geld/st...heidsites-kost-16-miljard
Deze verwijst naar:
http://www.z24.nl/geld/di...en-van-de-overheid-504866
Dit is gebaseerd op
Dat concludeert de commissie-Elias, die namens de Tweede Kamer onderzocht wat er steeds misgaat met grote overheidsprojecten waar informatie- en communicatietechnologie aan te pas komt.
Feitelijk is deze rapportage een afgeleide van de parlementaire enquête en zegt dus eigenlijk niets nieuws.

Dus gaan we naar de volgende link kijken:
http://tweakers.net/nieuw...lt-miljarden-met-ict.html
In dit tweakers bericht wordt er verwezen naar:
https://zoek.officielebekendmakingen.nl/kst-33326-5.html
Intressant is de schade die ze inschatten, volgens de parlamentaire enquete gaat het hier om:
Een veilige schatting op grond van informatie van diverse deskundigen komt neer op 1 à 5 miljard euro verspilling per jaar – naar het oordeel van de commissie in alle gevallen een onaanvaardbaar hoog bedrag..
Dus laten we eens kijken naar het onderzoek dat sogeti heeft laten uitvoeren, dit geeft sogeti als bron:
http://www.mcspr.nl/wp-co...-Gebruikers-Betrekken.pdf
Hier zie je dan ook een bedrag terug wat in de lijn met de parlementaire enquete is.

Zeker als je het eens goed doorleest staat er dat de publieke sector 2x zoveel kosten heeft als de niet publieke sector. Dit houd dus in dat dit onderzoek zegt tussen de 1,6 miljard en de 4,8 miljard aan schade. Dit komt verdacht goed overeen met de parlementaire enquete.

Daarbij moet ik nog een kant tekening maken, wat zal de reden zijn dat de first draft tijdens de parlementaire enquete uitgegeven is, maar dat de final draft 2 weken later gepresenteerd wordt? Hadden ze tijd nodig om de cijfers aan te passen?

Plus natuurlijk waar zijn de bronnen voor het onderzoek van PB7, nou PB7 natuurlijk. Zonder bronvermelding is het de tijd niet waard, als er een goede bron er voor is wordt dit vermeld. Om het in perspectief te zetten, ik doe nu een enquete of ik een goede programmeur ben, ik heb wat rond gevraagt en wat blijkt ik ben een goede programmeur. bron

Mijn uiteindelijke conclusie, volgens de bronvermelding op tweakers gaat dit over de parlementaire enquete en hier kom je ook op uit als je de bronnen van tweakers volgt. Ga je onderzoek doen naar het nieuws bericht van sogeti dan heb je gelijk het is een reclame plaatje van sogeti.

Maar claimen dat dit probleem alleen bestaat omdat sogeti het zegt en omdat het in hun belang is, is je kop in het zand steken. Dat iemand een specifieke software leverancier aan pakt heb ik geen problemen mee. Dat mensen dit als excuus gebruiken om te bewijzen dat het probleem niet bestaat, heb ik wel een probleem mee. Ik ben niet nieuw in dit vakgebied en geloof me het is een serieus probleem. Daarom heb ik aangegeven dat als je de links volgt van dit nieuws artikel hier op tweakers dat je bij de parlementaire enquete uit komt, waar zover dat kan in een politieke arena, objectieve informatie staat.

Als ik het mis heb en ik letterlijk de bron vermelding niet goed gevolgd heb laat het me weten waar ik de fout in ga.

[Reactie gewijzigd door _wolf_ op 28 oktober 2014 22:42]

Je gaat de fout in door aan te nemen dat de bron van het sogeti-rapport de parlementaire enquete is op basis van het feit dat de journalistiek in een artikel de parlementaire enquete en dit onderzoek aanhaalt.

Sogeti ziet gewoon een markt en laat daarom een onderzoek uitvoeren door een derde partij gericht op de éénzijdige onderzoeksvraag van de kosten van bugs zonder daar de kosten voor het voorkomen van die bugs tegenover te zetten. Als het ons meer dan 1,6 miljard kost om de fouten te voorkomen zijn we beter af met 1,6 miljard 'verlies' door de fouten (en zoals ik al aangeef: naar mijn verwachting zou een onderzoek dat wèl de brede onderzoeksvraag stelt van welk deel van de kosten van bugs vermijdbaar is tegen lagere kosten dan de kosten van de bugs zelf nog steeds eenuitkomst hebben die pleit voor beter testen)
Aha, ok. Goed dat je me op mn fout wijst. Kudos daarvoor :), en mijn excusses voor mijn misopvattingen. Ik laat ze gewoon staan omdat als ik de fout maak, anderen dezelfde fout kunnen maken.

Wij (programmeurs) houden ons al jaren bezig met dit probleem. Bugs is de prijs die je betaald voor steeds hogere abstractie niveaus (voor meer functionaliteit) en steeds kortere ontwikkel tijden. Het probleem is, het niet gebruiken van producten zoals het door een engineer bedacht is. Dit geld voor engineers van de eerste lijn (hardware ontwikkelaar), tweede lijn (OS ontwikkelaar), derdelijns (Tool ontwikkelaar) en user end ontwikkelaar. (hierbij ga ik ook nog eens er vanuit dat er maar vier engineers er tussen zitten, wat ook geen garantie is). De software ontwikkelaars krijgen het meestal voor de kiezen omdat deze meestal de user end engineers zijn. Een fout in de engineering chain is het probleem van de laatste persoon in de chain. Wij (programmeurs) maken het ook niet beter door als iets niet werkt een "work around" te maken. Hierdoor ontstaat de perceptie dat de fout die je in de laatste chain merkt altijd een software fout is.

Als programmeurs hebben we ook genoeg mogelijke ideeën om dit probleem op te lossen. De een denkt de oplossing te vinden in meer testen, de ander denkt de oplossing te vinden door strakkere regels/werkstijl en weer een andere denkt de oplossing in het beter opleiden van personeel te vinden. Echter nog steeds is "first time right" zeldzaam en het is geen absolute garantie dat het een wel zal werken en het ander niet. Ook door de dingen met elkaar te combineren komen we vaak tot de conclusie dat het te duur wordt terwijl het te weinig voorkomt dat er bugs in het product zitten.

Dus gaan we verder in de chain kijken en ga je informeren zie je dit:
  • Gebruiker, het product werkt niet zoals gewenst, er zitten bugs in de software. Dit mag toch niet kunnen? Er moet beter getest worden.
  • Tester, er wordt te weinig getest en daarom is de software niet goed afgetest. Daarnaast veranderd de software te vaak zelfs tijdens testen.
  • Programmeur, Ik loop tegen onverwachte fouten aan in de tool, hardware en OS. Verder krijg ik ook nog eens teweinig tijd, om iets goed te implementeren.
  • Hardware engineer, er zullen wel wat problemen zijn, los het maar op in de software.
  • Tool bouwer, ze gebruiken onze tools niet goed.
  • OS bouwer, ze gebruiken het OS niet zoals bedoelt.
  • Hardware leverancier, hardware engineers zullen wel bekend zijn met de problemen.
Iedereen heeft een beeld van de oplossing maar niemand heeft een praktische oplossing. Geloof me meer testen is ook niet de oplossing, tried that, burned and failed.
Je zou ook kunnen stellen dat automatisering juist banen kan reden.

Oké, een bedrijf of organisatie zal door autmatisering minder mensen nodig hebben voor hetzelfde werk, maar als zij geen autmatisering zouden toepassen dan zouden zij zich op termijn uit de markt prijzen, en verdwijnen de banen naar de concurent die wel automatiseert.
De banen verdwijnen niet naar de concurent die wel automatiseert
De banen verdwijnen punt
Alleen bij de concurent die wel automatiseert verdwijnen niet alle banen, omdat ze open blijven.
De banen verdwijnen omdat het efficiënter gedaan kan worden door computers/robots. Efficiënter betekent prijsdaling, betekent koopkracht omhoog, betekent meer kansen in andere/nieuwe sectoren.

Een probleem wordt het pas als automatisering in alles efficiënter is dan wij mensen, maar zo ver is het nog lang niet. Klinkt ook als een aardig luxeprobleem.
Ik snap wel waar dit vandaan komt. Software testen is een van de belangrijkste activiteiten van Sogeti. Logisch dat zij met een onderzoek als dit het nut van hun activiteiten willen onderbouwen.
Tja als je al die bedragen optel. Files kosten tig miljard, roken tig miljard en ga zo maar door dan zijn we ondertussen arm en draait de economie niet.

Feit is natuurlijk er wordt geld verkeerd besteed maar het wordt wel besteed. bij ict krijgen mensen betaald, die betalen er weer belasting over, geven het geld uit en betalen btw en zo is de cirkel weer rond.

zou het niet besteed zijn, mensen werkeloos maar daarentegen anders besteed weer mensen aan het werk.
Verschil is dat door files diverse afspraken niet worden gehaald en personeel moet overwerken (waar niets tegenover staat) en bij roken krijgen we wel belasting binnen, maar kost het op den duur meer vanwege ziekte.

Bij dit soort dingen is er in zekere zin wel schade, maar wordt er ook weer geld verdient in de IT door het oplossen van die problemen. Het is geen geld wat je eigenlijk kwijt raakt, het blijft in de economie.
bij roken krijgen we wel belasting binnen, maar kost het op den duur meer vanwege ziekte.
De roker betaalt veel belasting over zijn hobby, en sterft jonger...
Die zieke roker van 60 kost inderdaad meer dan de gezonde niet-roker van 60.
Ik vraag me af of die stelling houdbaar blijft als je het afzet tegen dezelfde roker die na 5 jaar uitbehandeld is en sterft, tegen diezelfde gezonde niet-roker met een uiterste houdbaarheidsdatum van 120?
Worden gezonde mensen niet ook ziek en kosten ze de samenleving in hun laatste decennia niet ook veel geld? (verpleging, medische hulp want we kunnen alles fixen en in leven houden, en aow)

En betaalt de verzekering niet die ziektekosten?
Levert die roker niet eigenlijk meer op door een korter ziekbed waardoor de premies minder stijgen? ;)

[Reactie gewijzigd door Teijgetje op 25 oktober 2014 15:48]

Ik heb het vermoeden dat je gelijk hebt. En hoewel ik de geur van roken smerig vind en er liever uit de buurt blijf, vind ik de razzia op rokers om economische of betuttelingsreden belachelijk.
Geld blijft altijd in de economie. Het enige wat te bepalen is, is waar het gaat zitten. Dus bij jou, mij of iemand anders. Dan kun je door belastingen doen, of elkaar te verleiden spullen te kopen. Doordat je een schilderij maakt waar andere een miljoen voor willen geven wil niet zeggen dat er een miljoen bijgekomen is. Dat kan pas als de overheid de geldpersen aanzet.
Precies, als ik het goed begrijp meten ze geen kosten maar 'opportunity cost'. Dan krijg je bij een webwinkel iets als: "Onze website lag 4 uur plat. Normaal verkopen we voor 1000 euro per dag, nu een halve dag gemist met, dus, kosten van 500 euro". Waarbij dan waarschijnlijk niet wordt meegenomen dat men wellicht gewoon morgen meer verkoopt.

Iets anders is bij een bedrijf met support staff: systeem 4 uur down, 4 engineers naar gekeken a 100 euro per uur, dus 1600 euro kosten. Echter heb je die mensen toch in dienst en moet je ze toch betalen, dus zonder fouten had je dezelfde kosten als ze de hele dag alleen koffie drinken. Het is erg moeilijk in te schatten of je het met minder staff kan doen met betere systemen.

Verder komt die 5 miljard van Ton Elias weer uit een hele andere hoek: die rekent welke bedragen de overheid betaalt aan ict projecten die falen. Dat is dus geld de overheid investeert zonder direct resultaat. Echter, zoals je zegt, het geld komt wel bij bedrijven en werknemers terecht die belasting betalen, dus die bedragen zijn veel minder erg voor de economie dan ze lijken.

Verder staat er nog bijvoorbeeld dit:
"Bijna 1 op de 3 ondervraagde consumenten heeft afgelopen jaar minstens een keer een product op het laatste moment toch bij een andere webshop gekocht, omdat hij toen hij wilde afrekenen te maken kreeg met een foutmelding of storing. Doorgerekend betekent dat, dat onlineretailers in totaal 514 miljoen euro aan concurrenten hebben gelaten, op het moment dat de consument virtueel al de portemonnee trok."

Maar dat is natuurlijk WEER een ander bedrag: als men het bij een andere webshop koopt is er nul verlies voor de economie. Dan verdient alleen een andere shop meer en deze minder. Netto verdienen ze dus exact hetzelfde als geheel. Dus hier is een individuele opportunity cost, maar geen collectieve/economische.

Al met al rekent men met allemaal verschillende bedragen en kosten om zo tot een of ander compleet arbitrair bedrag te komen.

Niettemin is het belangrijk om dit soort dingen in kaart te brengen, alleen erg lastig. Waarschijnlijk is het volledige rapport een stuk beter dan de nieuws headlines. Zo iets complex kan je nou eenmaal niet samenvatten in drie paragrafen.

[Reactie gewijzigd door Zoijar op 25 oktober 2014 14:23]

Hoewel ik helemaal eens ben met je zegt mis je wel iets essentieels. De initiele levering van software. Het systeem betreft software aanpak op project basis zit als volgt in elkaar:

Stap 1: Klant wil verbetering van zijn productie/service maar heeft geen idee hoe of wat.
Stap 2: Klant gaat in gesprek met 3 software bedrijven elk 2 uur en op basis wat er gezegd wordt tijdens die gesprekken volgt er een offerte stadia of nog een vervolg gesprek van 2 uur. (1e kosten leveranciers, en voor alle behalve de leverancier die het project krijgt een kosten post)
Stap 3: Software bedrijven geven een offerte gebaseerd op een initiele inschatting. (dit is het bedrag waarmee de eind kosten vergeleken worden)
Stap 4: Klant vergelijkt de verschillende software aanbieders en maakt een keuze gebaseerd op wat voor hem belangrijk is. (geld, tijd of kwaliteit)
Stap 5: Na meer overleg blijkt dat er meer functionaliteit nodig is, en dus dat het meer gaat kosten (meer werk kosten, 1e schadepost voor de klant).
Stap 6: Er valt wel eens wat tegen en software ontwikkeling duurt wat langer of korter. ( redesign kosten, 2e schade post voor leverancier)
Stap 7: Software wordt intern getest en het blijkt dat sommige functionaliteiten op papier wel werken maar in de praktijk niet. Hierover wordt in overleg gegaan met de klant hoe dit op te lossen. (2e schadepost voor zowel leverancier als klant)
Stap 8: Software wordt opgeleverd en het is niet helemaal wat de klant er van verwacht, en wil dingen net iets anders en dit moet geimplementeerd worden voor afname door de klant. (opleverings kosten, 3e schadepost voor leverancier)
Stap 9: Systeem wordt geimplementeerd en mensen moeten ingeleerd worden, in dit tijd bestek zijn de mensen niet productief. (inleer kosten, 3e schadepost voor klant).
Stap 10: Gebruikers zijn nog niet gewent aan de software en hun productiviteit ligt initeel de eerste paar weken onder het niveau. (gewenningskosten, 4e schadepost voor klant)
Stap 11: Oude systeem gaat down en het nieuwe systeem wordt opgezet. Hier zit meestal wat tijd tussen. Hoewel een slim bedrijf zorgt dat dit zo kort mogelijk is, is het in de praktijk soms niet te vermijden. (Overschakel kosten, 5e schadepost voor de klant)
Stap 12: Nieuwe systeem is up en running buisiness as usual, maar de klant en de leverancier gaan in over leg hoe de situatie te verbeteren. Het kan zijn dat de klant ontevreden is en dus de software in zijn geheel schrapt, maar het kan ook zijn dat de kosten gedeelt worden en het systeem in gebruik blijft.

Deze 12 stappen zie je in vrijwel elk project terug op het gebied van software engineering. Afhankelijk van het bedrijf en de mensen is een van de stappen zwaarder dan de anderen. Deze kosten worden vaak niet mee genomen in de orginele offerte en waarom niet? dan wordt het namelijk te duur en gaan ze naar de concurrent.

Natuurlijk heb je gelijk betreffende jou argumenten, maar de grootste kosten worden vaak al in een eerder stadia gemaakt.
Echter, zoals je zegt, het geld komt wel bij bedrijven en werknemers terecht die belasting betalen, dus die bedragen zijn veel minder erg voor de economie dan ze lijken.
Dat vind ik een beetje een kromme redenering. Want als die 5 miljard niet naar gefaalde ICT projecten ging, dan ging het wel naar iets anders dat dat geld ook goed had kunnen gebruiken (laat ik voor de grap maar even zorg en onderwijs noemen). En dan was dat geld óók gedeeltelijk terug komen rollen in belastingcenten. Het netto verschil is dat die 5 miljoen bruto nu is weggegooid, terwijl het op een andere manier beter terugverdiend had kunnen worden.
Precies, als ik het goed begrijp meten ze geen kosten maar 'opportunity cost'. Dan krijg je bij een webwinkel iets als: "Onze website lag 4 uur plat. Normaal verkopen we voor 1000 euro per dag, nu een halve dag gemist met, dus, kosten van 500 euro". Waarbij dan waarschijnlijk niet wordt meegenomen dat men wellicht gewoon morgen meer verkoopt.
Daar is uitgebreid onderzoek naar gedaan.

Als je een shop hebt die een uniek (of vrijwel uniek) product verkoopt is de schade inderdaad niet direct gelinkt aan normale omzet, maar de schade is er wel (tegen de 25%). Als je een product verkoopt dat wijd verkrijgbaar is dan is de schade gemiddeld rond de 75% van de omzet.

Een uur downtime van je shop servers is gewoon bijzonder kostbaar.
Volgens mij is dit een nieuwssite, en kunnen de mensen hier prima de zakelijke boodschap zonder feel-good envelop verwerken. Idiote PC gedoe altijd... Wat onderzocht is zijn de kosten die fouten met zich meebrengen, dus dat wordt genoemd.

Storender vind ik "de overheid verspild jaarlijks"...

Ik zie dit soort berichten meer als een meetlat. Als over 5 jaar een vergelijkbaar onderzoek aantoont dat er nog maar 800 miljoen verkwist wordt, is dat vooruitgang.
Volgens mij is dit een nieuwssite, en kunnen de mensen hier prima de zakelijke boodschap zonder feel-good envelop verwerken. Idiote PC gedoe altijd... Wat onderzocht is zijn de kosten die fouten met zich meebrengen, dus dat wordt genoemd.
Maar je kunt helemaal niet onderzoeken wat de kosten zijn van software fouten. Kosten ten opzichte van wat? Ten opzichte van géén software? Ten opzichte van perfectie (wat nooit kan bestaan)? Ten opzichte van de realiteit?

Maarten heeft wel degelijk een punt. Als je de kosten vergelijkt met een situatie zonder software dan zijn er alleen opbrengsten. Als je de kosten afzet tegen perfectie van ben je jezelf voor de gek aan het houden.

Dit soort onderzoek is zinloos. Het levert alleen iets op voor de onderzoekers zelf en verder wordt er niemand beter van.
Het gaat dan vooral om softwarefouten die ervoor zorgen dat productie stil komt te liggen of dat het werk op andere manieren wordt beïnvloed
Lijkt me prima meetbaar? Falende productiemiddelen kosten gewoon geld. Dat is met ICT niet anders dan met een of andere machine.

[Reactie gewijzigd door evilution op 25 oktober 2014 12:39]

minder opleveren is lang niet altijd gelijk aan kosten,
als jij voorziet in een behoefte lost die behoefte nagenoeg nooit direct op..

de enige sectoor waarin dat echt geld is de voedings-industrie, je had een kop koffie gelust maar de automaat is kapot dus lijdt je maar een post dorst en drinkt een slok kraan water, dit kost de economie zo'n Eur: 1.50

in consumptie en productie goederen steld zo'n fout in de meeste gevallen de bevrediging van die behoefte alleen maar uit, de enige werkelijke kostenpost is wanneer die software fout een productie-fout opleverd, en men dus goederen kan wegsmijten, of wanneer er voor mega bedragen reparaties aan te pas komen, maar dat is in de meeste gevallen lang niet aan de orde. kortom: broodje aap bedragen,
Lijkt me prima meetbaar? Falende productiemiddelen kosten gewoon geld. Dat is met ICT niet anders dan met een of andere machine.
Once again: Ten opzichte van wat? Ten opzichte van dat die systemen helemaal niet zouden draaien omdat er geen software zou zijn? Ten opzichte van De Perfecte Wereld, die niet bestaat?
Nee, mensen kunnen dat heel slecht.

Nu schat ik tweakers hoger in dan dan nu.nl publiek. Maar als je naar de gemiddelde reacties daar kijkt blijkt dat mensen positief nieuws niet meer geloven na lang negatief nieuws.

De media is zo sterk dat zelfs wanneer ze geen leugens vertellen, maar vooral het halve verhaal dat dat invloed heeft op hoe mensen denken.
En dan nog lijkt 1.6 miljard me nog genoeg ruimte voor verbetering. Dat is geen kattepis.
Als je ook nog kijkt naar slechte uitrollen van software pakketten, waardoor een pakket niet geaccepteerd wordt in een organisatie, en daardoor niet gebruikt wordt dat kost ook miljoenen.

Eigenlijk is het niet zozeer verlies, maar minder dan er potentieel gebruikt kan worden.
Zou je zeggen, alleen 1,6 van wat? Als het een omvang heeft van 200 mld dan zijn het peanuts. Dan moet je daar geen tijd en energie in investeren omdat de kans groter is dat deze kostpost groter zal worden dan de schade.

Lees dergelijke berichten altijd met een voorbehoud.
Omdat er bedrijven letterlijk failliet gaan aan software die niet naar behoren werkt of niet naar behoren is geïmplementeerd.
ja en de concurent gaat meer verdienen, lullig voor dat ene bedrijf maar macro-economisch heeft zoiets nauwelijks merkbaar effect zelfs een deel van het personeel zal wellicht worden overgenomen door de stijgende vraag bij dat andere bedrijf.
Mensen tillen ou eenmaal zwaarder aan verlies dan aan verminderde meeropbrengst.

Waarom? Weten we niet, alleen wel dat het zo is. Zie bijvoorbeeld hier: http://nl.wikipedia.org/wiki/Vooruitzichttheorie.

Ik heb overigens nog een variant voor wie zicht ergert aan het kopje over softwarefouten. Die luidt:

<b>"Managementfouten kosten de Nederlandse economie jaarlijks 1,6 miljard euro".</b>

Dit is zondermeer waar, omdat iedere softwarefout in feite een managementfout is. Alleen zijn managers beter in bekvechten dan softwarebouwers, dus durft niemand het zo te stellen, hehe.
Waarom? Weten we niet, alleen wel dat het zo is.
Nou, ik weet het wel.
Minder winst is alsnog positieve winst.
Verlies is negatieve winst.
"Managementfouten kosten de Nederlandse economie jaarlijks 1,6 miljard euro"
Ja, en mismanagement is dan ook een vrij groot probleem in nederland. Ook hierdoor komen steeds vaker door persoonlijk gewin of onkunde cruciale structuren in gevaar.
Magoed, tweakers is een technologiesite dus zie je hier alleen de berichten over ITC.
Je zorgen zijn evengoed volkomen terecht.
Software levert onze economie jaarlijks miljarden euro's op aan efficienties.
Leuk bedacht, maar kom dan eerst met een bron die dat onderbouwt. Ik heb daar zo mijn twijfels over.
Het lijkt mij toch aardig voor de hand liggend dat een financiële administratie in een computer systeem in het kwadraat sneller te verwerken is, dan alles met potlood in een grote map opschrijven en bij de jaarafrekening 2 weken met een rekenmachientje alles op te tellen. Waarna je meer gebruikersfouten op het rekenmachientje gaat krijgen, dan fouten door bugs in software ;)

En dan hebben we het alleen nog maar over financiën, laat staan alle andere zaken die in computer systemen bijgehouden en uitgevoerd worden.

[Reactie gewijzigd door Engineer op 25 oktober 2014 16:36]

Waarom altijd weer...
Omdat we als maatschapij steeds meer afhankelijk worden van diezelfde software.
Daardoor kunnen softwarefouten steeds vaker grote gevolgen hebben voor de maatschapij.
De grote vraag is of we de oplopende risico's die met vergaande automatisering gepaard gaan wel op kunnen vangen als het een keer echt mis is.
De grote vraag is of we de oplopende risico's die met vergaande automatisering gepaard gaan wel op kunnen vangen als het een keer echt mis is.
Kijk, iemand die het snapt ;)

Ik zie veel reacties hier in de trend van "ach, website van Kareltje van om de hoek ligt er even uit, misschien gaat ie failiet. Jammer, maar Pietje verdient toch genoeg, dus boeie?"

Maar we gaan langzaam toe naar een TOTALE afhankelijkheid van software. Het begint toch echt wel vrij scary te worden, en het is allemaal 1 groot kaartenhuis. Alles zit stik vol bugs en wordt met plakband aan elkaar gekoppeld, niet zelden met aannames en gokken wat het gekoppelde systeem in hemelsnaam precies allemaal doet.

En dan heb ik het alleen nog maar over het basale functioneren, en niet eens over de security van alles, wat nog een compleet verhaal apart is.

Eigenlijk zijn we veels te snel veels te veel software gaan gebruiken voor alles en nog wat, zonder goed in staat te zijn om zulke enorme bergen aan code te doorgronden en te onderhouden.
Eigenlijk zijn we veels te snel veels te veel software gaan gebruiken voor alles en nog wat, zonder goed in staat te zijn om zulke enorme bergen aan code te doorgronden en te onderhouden.
Maar gaan we dat ooit eigenlijk goed kunnen. Branching is zowiezo moeilijk voor het menselijk brein.
Maar gaan we dat ooit eigenlijk goed kunnen.
Dat is de vraag. We zijn sinds assembly al best ver gekomen, maar duidelijk is dat we er nog lang en lang niet zijn.

Probleem is dat elke keer als de talen, frameworks en tools higher level worden, we ons domain ook weer vergroten. Als we nu slechts de software zouden schrijven die in 1984 gebruikelijk was, dan waren de huidige talen best te pruimen.
Branching is zowiezo moeilijk voor het menselijk brein.
Inderdaad, en een te hoge branching graat is een recept voor bugs, want je -weet- dat boven een bepaalde level het brein het gewoon niet meer kan bevatten in 1 oog opslag. Daarom heb je ook static code analyzers die de maximale branching voor elke methode meten en waarschuwen als het te hoog is.
Omdat het hier over softwarefouten gaat en niet wat software de economie oplevert.
En omdat negatief nieuws het goed doet natuurlijk.
Mee eens.
Software levert veel werk op.
We kunnen ook zeggen dat inefficientie in de zorg ons miljarden per jaar kost.
De EU miljaren per jaar inefficient is etc etc
Meer focus betekent echter ook meer kosten, want meer kwaliteit kost tijd, tijd = geld. In hoeverre de extra kosten die dan onstaan in verhouding is wat men nu verspilt is nog maar de vraag of dat daadwerkelijk winst oplevert.
En hoe denken ze kosten te drukken door grondigere kwaliteitscontrole in te voeren ?
Een groot stuk fouten zijn er juist omdat mensen onder tijdsdruk ondoordachte beslissingen moeten maken en hier een daar een snelkoppeling nemen.
Zijn er ergens betrouwbare cijfers over die efficientiewinst?
Helaas genoeg niet, efficientie winst is een abstract begrip. Aan de ene kant heb je minder werk echter aan de andere kant kan er meer werk zijn. Kijken naar wat software effectief opbrengt is een kwestie van koffie dik kijken aangezien je pas na 10 jaar een globaal idee heb van de toegevoegde waarde ervan en in de tussentijd zijn er vaak al veel meer ontwikkelingen geweest waardoor de efficientie van een implementatie onmogelijk wordt om los te zien van zijn geheel.

Het zelfde geld ook voor mogelijke verliezen die optreden, als een service tijdelijk offline is dan kan je effectief per uur gaan middelen over een jaar wat het kost, echter je weet niet exact wat het gaat kosten omdat je ook niet weet of daarvoor of daarna meer gebruik is gemaakt van het systeem. Het probleem met groot onderzoek is dat je iets algemeens in handen heb wat 100x hoger of 100x lager uit kan vallen. Dit komt praktisch neer op hoe je de statistieken leest.

Dus er zijn nog betrouwbare cijfers over efficientie winst nog betrouwbare cijfers over de verliezen die geleden worden. Enige betrouwbare meetbare resultaten is downtime en recovery time.
Dank, _wolf_
Een m.i. realistische reactie . Er zijn natuurlijk zaken waarin de voordelen niet te missen zijn, maar andere kant is het t.o.h. in mijn branche", de gezondheidszorg, meer de Haarlemmerolie van de minister en sprookjes troef: 'ieder voordeel hep meestal ook zijn nadeel'
Ik snap je reactie, maar ik hoop dat je wel bewust ben dat net als elke ontwikkeling ook gezondheidszorg met de tijd mee moet gaan. Toegegeven nieuwer is vaker niet beter dan wel beter, en dat geld zeker voor alles wat bedacht wordt op het gebied van ICT.

Maar wat staat er tegen over als je niet mee gaat met ontwikkelingen? Je creëert daarmee een steeds grotere kloof tussen gezondheidszorg en mensen. Hoewel de snelheid waarmee het nu gebeurt ook veel te snel is vanuit mijn oogpunt leven we nu ook in een maatschappij waarop alles te snel moet gebeuren.

Intrede van nieuwe systemen moeten vooral geleidelijk aan gebeuren waarbij niet gekeken moet worden naar wat kan maar wat de zwaksten gewent zijn. Kijk veel oudere mensen vinden het maar knap lastig mobile telefonie, pin pas en nu ook nog iets wat internet heet. Daarom moet er bij bestuurders het besef zijn dat deze technieken dus ook nog niet ingevoerd moeten worden in het systeem.

Door deze voorgestelde manier van handelen aan te houden ontstaan er 3 dingen. 1 technische ontwikkelingen worden logisch voor iedereen en daarmee ook gemakkelijk geaccepteerd. 2 Programmeurs en techneuten lopen ook niet meer op het uiterste van hun kunnen en technische toepassingen worden uitgetest en daarmee ook een stuk betrouwbaarder. 3. Er is een minder aantal maar beter opgeleide techneuten nodig waardoor deze markt ook weer gezond wordt, waar deze dat op dit moment gewoon totaal niet is.

Dus mijn stelling is technische ontwikkelingen zijn nodig, echter op een lager tempo. Kan jij het daar in vinden?
Met een paar van je opmerkingen kan ik het zeer eens zijn wolf; en dan betreft het in de eerste plaats de wat tegenstrijdige opdracht zowel met de netwerk- als met de oudere generatie aansluiting te houden.

Mijn zorgen zitten vooral in wat andere zaken:
- De minister rekent op kostenbesparing terwijl juist technologische vernieuwing voor zover ik kan overzien duurder heeft gemaakt
- veel glossy vernieuwingen zijn in essentie niet meer dan middelen om meer data te verzamelen. Daar staan twee dingen tegenover: vaak levert goed luisteren, kijken en bekloppen net zoveel op; en er geldt 'hoe meer je meet - hoe meer niet echt relevante "afwijkingen" je ziet - hoe meer overbodig vervolgonderzoek en behandeling - hoe meer bijwerkingen van behandelingen die niet nodig waren'. Tevens een van de redenen ernstig te twijfelen aan die fantastische vermeende efficiëntie en besparingen
- ik zie nogal wat fout gaan in de zorg, en dan heb ik het niet over foute dokters maar over de gevolgen van (beleids)keuzes. Afhankelijkheid van soms falende techniek is daar een van
- of we het leuk vinden of niet: behandeleffecten zijn in niet geringe mate ook afhankelijk van relationele factoren. En voortschrijdende techniek heeft daar een slecht voorspelbare invloed op. Ligt dicht aan tegen fundamentele kritiek op mogelijk negatieve kanten aan IPad-leren; kritiek die geen oude lullen praat is, maar berust op hard onderzoek en inzicht in psychologie

Resteren natuurlijk ook prachtige dingen als ondervangen van handicaps met techniek

Gr

[Reactie gewijzigd door xynyxs op 11 november 2014 17:37]

"Software levert onze economie jaarlijks miljarden euro's op aan efficienties. Als gefocussed zou worden op het verminderen van software fouten, zou dit 1,6 miljard extra opleveren."

Minder fouten => betere QA, meer ontwikkeltijd, ...
De relevante vraag is "tegen welke kosten?"
Omdat Sogeti het onderzoek heeft betaald en omdat zij belang hebben bij deze conclusie. Ze leveren immers veel test expertise.

Wel een goede marketing stunt trouwens: Tweakers.net trapt er in en gezien de verhitte discussies hier, veel tweakers ook.

[Reactie gewijzigd door delima op 25 oktober 2014 14:02]

Waarom altijd weer dat negatief sensationele?
Wat ook kan:
Software levert onze economie jaarlijks miljarden euro's op aan efficienties. Als gefocussed zou worden op het verminderen van software fouten, zou dit 1,6 miljard extra opleveren.
[modbreak]
Spelfouten en/of ander commentaar m.b.t. nieuwsposts horen thuis in
Geachte Redactie.
[/modbreak]
Tijdens het lezen van het artikel kwam ik tot exact dezelfde gedachte.

Als die modbreak slaat op het "commentaar leveren" op de gedachtengang van het nieuwsbericht (misschien is er tekst over spelfouten verwijderd?), denk ik dat deze moderator een denkfout maakt. Het is immers geen commentaar op de nieuwspost, maar commentaar op het onderzoek dat in de nieuwspost beschreven wordt.

Het is zo ongeveer een cliché dat positief werk van ICT'ers (o.a. programmeurs) niet gezien wordt door de menigte, maar zodra er wat mis gaat dan gaat de zweep erover ;) Exact hetzelfde met dit onderzoek.

[Reactie gewijzigd door Engineer op 25 oktober 2014 16:02]

Helemaal mee eens, softwarefouten kosten niets, ze zorgen voor minder inkomsten! als deze zoveel kosten, dan is dat het geld wat wordt uitgegeven om de fouten te herstellen.
Softwarebedrijven zouden de foutjes gratis moeten oplossen.
Als er iets mis is met jouw pas gekochte auto, ga je er mee terug en de leverancier repareert hem gratis. Op software zou ook garantie moeten zitten, maar nee, bij sommige dure software moet je een jaarlijks bedrag betalen voor ondersteuning.
Ja, en kijk eens naar de disclaimer die bij nagenoeg elk software product zit. ELKE verantwoordelijk wordt afgeschoven tot het absolute maximum wat wettelijk mogelijk is.

Het -kan- ook gewoon niet anders.

We hebben simpelweg amper de kennis om redelijk bug vrije software te schrijven, plus we eisen dat software alles en zelfs meer dan alles kan voor niets. En we vinden dat iedereen een soort geboorterecht heeft om software te moeten kunnen schrijven, en dat opleidingen maar elitaire en discriminerende dingen zijn die je vooral niet moet gaan eisen.

Wil je met de huidige staat van de techniek redelijk bug vrije software (zoals vereist voor diverse medische toepassingen), dan betaal je voor een minimale hoeveelheid functionaliteit al makkelijk vele honderduizenden euros. Op schaal voor de consument zou dit nog steeds betekenen dat het meest lullige tooltje al snel een euro'tje of 100 moet kosten.

En ja, dat willen "we" natuurlijk niet betalen!

Want developer hebben geen recht op geld, geld is evil! Software moet gewoon GRATIS! zijn of als het -echt- niet gratis kan HEEL GOEDKOOP (en dan gaan we lekker met z'n allen zeiken in fora dat we die ene euro die iets moet kosten zo evil is). En hoe developers dan moeten leven? Nou, ze kunnen toch "alternatieve bronnen" zoeken (lees, overdag gratis software maken, 's avonds hamburgers flippen, dan meteen slapen en 's ochtends weer meteen werken).

Tsa, en dan vragen mensen zich nog af hoe het kan dat er geen garantie op software zit :(
offtopic:
Er is een plek voor kritiek op tweakers, dit is niet de plek hoe terecht of onterecht het ook is, zet je eerste zin offtopic je verdere opmerking is in mijn ogen zeer relevant
De reden waarom je niet terug leest wat software opbrengt, is omdat dit moeilijk meetbaar is. Kijk in een fabriek kan je wel zeggen van goh joh we produceren 10% meer sinds de upgrade van een machine. Deze winsten worden vervolgens geboekt als winst van het bedrijf en niet als winst voor de samenleving als geheel.

Het feit dat zonder automatisering de meerderheid van de fabrieken in nederland niet winstgevend zijn en dus allang falliet gegaan zijn of verhuist is ook moeilijk om een waarde op te leggen simpel weg omdat het te complex wordt om dit door te berekenen. De waarde voor de samenleving is banen. Wanneer een industrie verhuist, dan verlies je bijv niet alleen 10.000 banen van de fabriek, ook de bedrijven die middag eten aanleveren, schoonmaaksters, transport bedrijven, energie bedrijven, openbaar vervoer, consultancy en engineering bedrijven en nog vele anderen zullen dit financieel merken. De momenten dat dit wel gedaan wordt, zie een NXP in 2009 of een ondersteuning met deeltijd ww voor een ASML in 2010-2012, of zelfs in het absurde een voetbal club komt bestuurders dan vaak ook op grote kritiek te staan omdat het probleem van het vertrek van een grote werkgever zo groot kan zijn dat mensen het simpel weg niet kunnen bevatten.

Voor een service ligt het nog moeilijker. Je kan moeilijk geld leggen op het feit dat het UWV 5 uur offline is, of dat belasting formulieren 10 dagen later verwerkt worden. De reden waarom dit zo moeilijk is, is omdat software maar 1 radertjes is van een rad. Er is vaak geen directe feedback wanneer z'n service uitvalt. Dus moet je een waarde gaan leggen op de downtime van een server. Naar mate er meer services gemaakt worden, zijn er meer servers en dus ook meer downtime. Hier wordt dan een ongeveer getal aan verbonden om toch maar een beeld te genereren dat dit daadwerkelijk een groot probleem is.

Van project tot project kan je dus moeilijk inschatten wat levert het nu op, dit kan je niet omdat deze cijfers niet gezien worden als inkomsten maar als een gebrek aan uitgaven. Een voorbeeld hiervan is in de zorg, in in de rijksbegroting van 1980 betaalden we ongeveer 17 miljard euro aan zorg. rijksbegroting betalen we nu ongeveer 92 miljard. (zie CBS als je me niet geloofd) Als we hier de inflatie inclusief de relatieve geld waarde van gulden naar goud in 1980 tot en met nu. Dan komen we ongeveer uit op 72 miljard. Rekening houdend met dat er in de loop van de jaren toch echt heel veel verschillende types behandelingen bijgekomen zijn, ik ben geen deskundige maar laat ik het stellen op 2x zo veel. Betekend dat er een kosten besparing is op behandelingen van ongeveer 60 miljard. Dit kan je natuurlijk niet alleen als opbrengsten van automatisering zien, echter we kunnen wel stellen dat dit mee speelt. Er zijn nog zo veel andere factoren die hier invloed op hebben dat je er letterlijk geen geld definitie aan kan hangen.
Niets is perfect, en software helemaal niet. Ik zeg altijd: "Software sucks", en dat is de waarheid. Elk stuk software werkt wel eens niet naar behoren. Maar toch: Zonder onze software zouden de taken de economie nog veel meer geld kosten :)
Dat klopt, maar er is een enorm kwaliteitsverschil in de markt, waarbij er een flinke variatie is in dit " wel eens" in de fout gaan.

Bij ons zijn er systemen/applicaties die 3 tot 4 jaar zonder problemen in de lucht zijn. Oude DEC-APLHA servers hielden het alleen al aan de OS kant soms 10 jaar zonder dralen vol, en alleen de applicatie werd indien nodig van een update voorzien. Om nog maar niet te spreken van de kwaliteit van Stratus FT systemen gebaseerd op VOS.

Veel fouten staan onder druk van tijd en geld. Software huizen die jonkies in dienst nemen en het programmeerwerk laten doen. Nog steeds een gebrek aan standaard werkmethodes. etc. Dit is allemaal te voorkomen, en in het bedrijfsleven gaat het nog redelijk, maar de overheid zit zichzelf met zijn aanbestedingsregels en keuze bepalingen waarbij de prijs tot 60% meetelt in de weg. Ze vragen zelf om de problemen waar ze mee zitten.
En nog veel meer fouten ontstaan omdat de software systemen van tegenwoordig oneindig veel ingewikkelder zijn dan die van 10 jaar geleden, om nog maar te zwijgen over 20 jaar geleden.

20 jaar geleden werd een stuk software gebouwd om één interne handeling te automatiseren.
10 jaar geleden werd een stuk software gebouwd om één intern proces te automatiseren.
Tegenwoordig moet een stuk software meerdere procesen zowel intern als extern ondersteunen.

Fouten ontstaan nauwelijks door jonkies of gebrek aan standaarden. Fouten ontstaan door complexe situaties die niet volledig doorzichtig en voorspelbaar zijn.
Ja das met alles zo hè. Zou het niet fantastisch zijn als ze auto's uitvonden die nooit stuk gingen. Of wasmachines, magnetrons en vaatwassers.

Maar goed, wat gaan al die monteurs en verkopers dan doen voor de kost?

Dingen gaan nou eenmaal stuk en das met software niet anders. En 1,6 miljard klinkt als best veel maar als je dat vergelijkt met ruwweg 750 miljard die de totale economie waard is, valt het best mee (0,2%). En het grootste deel van die economie is inderdaad alleen maar mogelijk door al die computers en software.
Zou het niet fantastisch zijn als ze auto's uitvonden die nooit stuk gingen. Of wasmachines, magnetrons en vaatwassers.
Hier heb je het over slijtage. Das wat anders.

Bij software gaat het om elementaire ontwerp fouten.

Als zoiets bij wasmachines, magnetrons of vaatwassers gebeurd komt er een recall en niet zelden een schadevergoeding.

Bij software wordt het echter de markt opgegooid MET die ontwerp fouten, en ach, als er iets fout gaat patchen we het wel.
Het zou wat wezen dat computers net zo goed werkten als auto's.

Kijk ik terug over 25 jaar leaservering en 30.000 km/jaar dan ben ik in al die jaren 5 keer naar de garage geweest buiten het reguliere odnderhoud om voor een storing.
tsjah.. en wat gaan we eraan doen?
1,6 miljard steken in optimalisatie van het ontwikkelproces, extra testers en teststraatjes?
Om vervolgens te moeten concluderen dat er alsnog bugs aanwezig zijn in de finals?

beetje een loos onderzoek als je het mij vraagt, wat wil men hier nou mee?
Inderdaad, eigenlijk is dit bedrag enkel nuttig als je het kan vergelijken met het bedrag nodig om deze fouten op te lossen of te voorkomen.
beetje een loos onderzoek als je het mij vraagt, wat wil men hier nou mee?
Ik denk niet dat het loos onderzoek is, maar vraag me wel af wat men hier nu mee wil.

Sogetti heeft natuurlijk een bepaald commercieel belang, maar het brengt wel degelijk aandacht voor een daadwerkelijk probleem.

Optimalisaties in het ontwikkelproces is een middel om te proberen de boel meer onder controle te krijgen, maar eigenlijk is er geen enkel proces wat echt goed werkt.

Neem het bij sommige als het proces van de verlossing gezien: Scrum. Je hebt teams die Scrum tot op de letter volgen en waar het eigenlijk helemaal nergens meer over gaat. Estimations b.v. (beetje hot topic, zoek eens op "#noestimations") waar men uren verspilt aan het droogjes opnoemen van allemaal mooi klinkende uurtjes, dan aan de slag gaat en keer op keer op keer op keer (*100) klopt er totaal niets van. Maar ja, toch blijven doen he? Want Scrum zegt nu eenmaal dat het moet en Scrum zegt dat als het maar vaak genoeg doet de estimation steeds beter doet. En als dat dan na jaren nog niet gebeurd... nou dat steek je gewoon je kop in het zand, want Scrum zegt dat...

Of ijskoud allemaal issues gaan aanmaken waarvan de product owner vindt dat ze de hoogste prioriteit hebben (want Scrum zegt dat!), en dan gebeurd er bijna niets, want de product owner houdt geen rekening met het feit dat developers in het team niet gelijk zijn. Sommige zijn goed in de frontend, sommige goed in de backend, andere in algoritmes. Maar ja, Scrum zegt dat iedereen gelijk is, en dat iedereen elk issue moet kunnen oppakken. Dus ja, de jQuery frontend dev pakt opeens een issue op waar een SQL query in de backend optimized moet worden, en bakt er dan niets van. Maar ja, Scrum zegt dat dit zo moet, dus doen we het maar he!? :X

En alle testen die we in de praktijk doen (unit tests, integration tests, smoke tests, ...) zijn nagenoeg allemaal steek proefen. En MEER testen betekent helaas niet altijd betere software. Soms zelfs slechtere!

Want de unit test GURUs zeggen dat we moeten mocken! Dus gaan we complete mock systemen bouwen die van alles en nog wat mocken en stubben, en nog meer mocken. En daar gaan we dan tegen unit testen, en ja! De tests passen!!! Dus gaan we in productie en BOEM! Alles op z'n bek, want we hebben alleen de mocks getest, niet het daadwerkelijke systeem. En de mocks waren zo geschreven dat ze de unit tests lieten passen.

Ondertussen ging er in het maken en onderhoud van al die volledig zinloze testen zo veel tijd en energie zitten dat er voor de daadwerkelijke kwaliteit van de software geen tijd meer is. En ja, soms ook echt slechter maakte omdat we dingen die intern hadden moeten zijn opeens toch blootstellen omdat het anders niet te testen. TDD zegt dat dat juist goed is, want minder coupling etc. Maar ja, wat eerst een straightfordward implementatie was, wordt nu opeens wel erg complex door al die wazige de-coupling. Maar ja, nu kunnen we wel testen dat de volledige triviale getter en setter daadwerkelijk werken! En onze test coverage is 95+% dus onze software is tenminste 95+% bug vrij, toch? (alleen, waarom komen er in het eerste uur nadat de software in productie gaat toch altijd weer zoveel bug reports? We zijn toch 95% bug vrij???)

Etc...
Als IT prof kan ik helemaal niets met dit artikel.

Er word 'iets' geroepen en daar word 'prijskaartje X' aan gehangen zonder enige concrete onderbouwing anders dan 'men zegt'. Ik heb de vragstelling natuurlijk niet gelezen maar schuif die dan ook terzijde.

Ton Elias en commissie
Stelt u zich even voor? Een commissie waar geen enkel lid enig idee van en met IT heeft die deze wereld bij de overheid gaat onderzoeken? 1. Een overheid die natuurlijk eigen nest niet bevuild laat staan verantwoordelijkheid durft te nemen en 2. IT leveranciers die natuurlijk hun broodheren niet voor het hoofd zullen stoten en zie daar, een totaal onevenwichtig en op punten onjuist rapport.
Dat was eerder al voorspeld maar dat even in de marge.

Wat u moet weten is dat......

IT 100% voorspelbaar
Het is klaarblijkelijk steeds minder bekend dat Materie en Vehikel 100% voorspelbaar is. Zeker is dat dit gegeven ook nog niet (helemaal) binnen de gelederen van Sogeti is binnegedrongen.

Forecast schade
Al jaren houd ik mij bezig met de 'awareness' dat IT 100% voorspelbaar is en waarom fouten ontstaan. Ik maak met regelmaat mee dat de commercie zich met allerlei andere zaken bezig houd dan overbrengen dat
1. Wat automatiseren is
2. Waarom je automatiseert
3. Waarom je eigenlijk al of niet zou automatiseren

Want als je je namelijk bezig houd met deze drie vragen VOOR je ook maar één stap in zet in en met IT, je eindelijk datgene gaat bewerkstelligen wat je beoogt met en in IT.

Schade prognose
De schade zoals Sogeti dit hier presenteerd is veel te laag ingeschat. Alleen al binnen Nederland, inclusief de overheid, heb je het over een schade naar idee van meer dan 5 miljard op jaarbasis.

Diversiteit
Doordat men sinds 2008 allerlei zg 'Nieuwe Dingen' is gaan bedenken roepende dat dat kostenbesparend zouden zijn zien wij voornamelijk oude wijn in nieuwe zakken en... een enorme toename van steeds grotere incidenten met een steeds grotere impact.

Steeds minder mensen houden zich met de werkelijke basis van IT bezig en dat kun je werkelijk voorspellen dat de shade door incidenten en voorspelbare fouten, 100% voorspelbaar, zullen gaan toenemen. Daarmee uiteraard de schade eveneens

Back to basics
Wil je werkelijk in en met IT besparen? Iets waar je IT sec voor in zet, dan moet je terug naar de basics van IT

Terug naar de drie vragen
1. Wat is automatiseren?
2. Waarom automatiseer je?
3. Waar zou je automatiseren

en dan hebben wij het nog niet ens over de IT wetmatigheden waar 3/4 van de professionals niet eens meer iets van af weet.
IT 100% voorspelbaar
Het is klaarblijkelijk steeds minder bekend dat Materie en Vehikel 100% voorspelbaar is. Zeker is dat dit gegeven ook nog niet (helemaal) binnen de gelederen van Sogeti is binnegedrongen.
Stellen dat de materie 100% voorspelbaar is, is onwetendheid op z'n minst. De materie waar je het binnen IT over hebt zijn bedrijfsprocessen en de mensen die die processen uitvoeren. Als jij dat 100% kunt voorspellen moet je nu onmiddelijk stoppen met IT en je op de beurs gaan begeven (of in een circus wellicht).

Een transistor is voorspelbaar. Een processor is voorspelbaar. Een stuk code is voorspelbaar. De inhoud van een database niet, de gebruiker achter het scherm niet, de programmeur niet. En nog veel belangrijker: Datgene wat er morgen door de systemen gedaan moet worden is niet voorspelbaar.

Software is een enorm complex vakgebied. En daarmee is de voorspelbaarheid nagenoeg 0. Wat wel mogelijk is, is het proces en de software aanpassen aan datgene wat we niet hebben kunnen voorspellen.

De drie vragen waar je het over hebt zijn vragen die de gemiddelde ITer zich iedere dag opnieuw stelt. De teams waar ik mij begeef vragen bij ieder stuk code weer aan de proces eigenaar: Waarom wil je dit automatiseren? Wat levert het op om dit te automatiseren? Wie of wat wordt daar beter van? 90% van de echte professionals doet dat bijna iedere dag weer. (niet raar ook; luiheid is de beste eigenschap van een ITer. Luiheid omdat alles wat teveel tijd kost geautomatiseerd wordt maar ook luiheid omdat wat níet geautomatiseerd hoeft te worden ook níet gebeurt)
Doordat men sinds 2008 allerlei zg 'Nieuwe Dingen' is gaan bedenken roepende dat dat kostenbesparend zouden zijn zien wij voornamelijk oude wijn in nieuwe zakken en... een enorme toename van steeds grotere incidenten met een steeds grotere impact.
2008? Volgens is er sprake van "nieuwe dingen" sinds de uitvinding van het tellen en de aanverwante ontwikkelingen (hardware en software in welke vorm dan ook). Zonder het begrip "rekenkunde" en de handvatten die hiervoor aanwezig waren/zijn, zouden duizenden personen uit de oudheid en het heden volledig niet bekend zijn geweest om hun bijdrage aan wetenschap. Hierdoor zou dus mogelijk de PC (in ponskaart of quantum-vorm) nooit zijn uitgevonden.

Ik vind het persoonlijk dan ook erg overtrokken en ongenuanceerd om dan sinds 2008 te vinden/zien dat er een enorme toename is van grotere incidenten met steeds grotere impact. Het is niet gekwantificeerd noch kwalificeer je de termen incident & impact; wat voor jou, of jouw werk/functie/opleiding, iets groots is, kan voor de volgende persoon iets miniems of iets reusachtig zijn, wederom niet gekwantificeerd of gekwalificeerd.

Jouw betoog loopt hierdoor wat scheef; in 1 zin worden bedragen genoemd die slaan op de overheid (want in het nieuws geweest) maar meteen trek je daar andere bedrijfstakken bij, wederom zonder kwantiteiten te benoemen of te verwijzen naar een bron.
Wat je zegt klopt gewoon niet. Het is wel degelijk ergens op gebaseerd. Namelijk een uitgebreid onderzoek.
Dit is gewoon de zoveelste golf van politiekers en commisies die IT ziet als een kostenpost en deze wilt
onder handen nemen. Enorm hypocriet eigenlijk want ze hebben de situatie van nu zelf gezaaid met hun openbare aanbestedingen om altijd voor de "goedkoopste oplossing" te gaan. Dat ga je nu niet oplossen door de knip erin te zetten.
Ik ben denk ik een van de 80% of 3/4 van die IT specialisten (schrijven van software voor automatiserings doeleinden, dus niet voor communicatie doeleinden ICT, denk aan machine besturingen ipv web services en formulieren) die niet begrijpt dat de ontwikkelingskosten van software voor 100% van te voren voorspelbaar zijn.

De vraag wat automatiseren is, is iets wat duidelijk is. Ik weet ook waarom ik automatiseer en waar dit toegepast wordt en wat daarvan de uiteindelijke opbrengsten zullen zijn. Sterker nog zelfs tijdens coderen blijf ik altijd kritisch of hetgene dat ik implementeer echt nodig is en het komt er niet in als het niet nodig is.

Maar ik kan niet kan voorspellen welke fouten ik in code zal maken de aankomende weken. Ik begrijp dan de basis volgens jou nog niet. Ik ben benieuwd wat kan ik doen om te voorspellen welke fouten ik in software in de toekomst ga maken? Graag met concrete voorbeelden zodat iedereen er van kan leren.
Zolang opdrachten vooral naar de laagste aanbieders blijven gaan blijf je dit soort shit houden.
Er wordt teveel gelet op de prijs en minder op kwaliteit en impact.
er zijn gerust mensen die enkel het beste willen en daar ook duchtig voor willen betalen, maar dat zijn niet noodzakelijk de mensen met beslissingsrecht
Want als je 30 euro per uur meer betaald heb je bug vrije software en geen incompetente klanten aan tafel die van alles willen en van niets weten.

bugs zijn inherent aan het werk dat je doet.
"Het gaat dan vooral om softwarefouten die ervoor zorgen dat productie stil komt te liggen of dat het werk op andere manieren wordt beïnvloed."

Er bestaat zoiets als een test omgeving
Geloof mij; test-omgeving en productie komen in 90% van de gevallen niet overeen met elkaar.
Ja, dit ligt somsaan de ontwikkelende partij, maar mijn ervaring is dat dit ook vaak aan de ontvangende partij ligt.
Voorbeelden hierin zijn onder andere missende vereiste patches, te kort window om alles live te zetten, zoals eerder werd aangegeven; de constant veranderende data in het systeem - die niet overeengekomen was met de leverende partij, derde partijen die invloed hebben op productie, die niet aangesloten konden worden op de test omgeving om allerlei redenen...
Dan moet je ervoor zorgen het wel met elkaar overeen stemt en niet excuses hiervoor verzinnen.
Nee, je moet zorgen dat DevOps en SysOps samenwerken. En dat je systeemprofielen hebt en niet een of ander mannetje dat lekker knullig achter een console de configuratie zit bij te werken.
Ben ik het helemaal mee eens - ik geef alleen de werkelijkheid (die ik meemaak) weer.
Ik vraag me af of er is meegenomen dat fouten in de software wel weer werk creëert voor software-ontwikkelaars. Het kan misschien zo zijn dat dit de geleden kosten weer opheft.
Iets wat niet perfect werkt roept de wens op tot verbetering, die verbetering noemen we dan weer innovatie. Dus met perfecte software loopt de innovatie waarschijnlijk schade op. Het is gewoon een onderzoek met een groot getal om aandacht te trekken voor een thema. In deze software kwaliteit.
dit soort cijfers moet toch met een grote schep zout worden genomen. Het is een extrapolering van een beperkte onderzoeksgroep, want ik kan mij echt niet voorstellen dat deze representatief is voor alle sectoren waar IT in gebruikt wordt, laat staan dat de meerwaarde of het verlies ervan objectief meetbaar zijn. Worden hier ook banksystemen meegeteld die voor honderden miljarden aan beurstransacties uitvoeren en razendsnel kopen/verkopen op basis van gigantisch ingewikkelde beursberekeningen
Alle cijfers waarbij die berekeningen maken op basis van bijv. mogelijk gemiste uren en mogelijk gemiste verkopen moeten met een scheepslading zout worden genomen. Immers gaan die berekeningen zo:

1 niesbui is ongeveer 7 seconden lang.
De meeste mensen hebben ongeveer 6 niesbuien per jaar.
Aantal werkende mensen ligt om en nabij de 7 miljoen.
Modaal inkomen is ongeveer ¤34.500 per jaar.
Modaal aantal werk uren is ongeveer 1375 per jaar of ongeveer 5,000,000 seconden.

((6 * 7s) / 5000000s) * (¤34.500 * 7000000) = ¤2,028,600.
Conclusie: Niesbuien kosten de Nederlandse economie elk jaar ca. 2 MILJOEN Euro.
( Terzijde: als een directeur van een multinational niest, is dat ongeveer het modaal dagelijks inkomen per niesbui ;) )

Natuurlijk is nodeloos haperende software slecht, daar niet van :)
"Het schadebedrag werd verkregen door het aantal uren te tellen waarin het werk stillag, vermenigvuldigd met de gemiddelde kosten die dit met zich meebrengt."

Vaak word op deze manier schade berekent maar zo makkelijk valt het niet te berekenen. Je haalt je werk dan waarschijnlijk gewoon later in of doet de bestelling ook later.

Stel ik koop een boek van 20,- bij bol maar de website ligt er uit. Dan koop ik dit gewoon op een later moment ze lopen dan niet meteen 20,- omzet mis.

http://www.deondernemer.n...e-kost-ons-2-miljard.html

Toen zoals bij de nucleaire top, mensen werkten toen gewoon thuis, namen een dag vrij, of kochten het product 2 dagen later in den haag. Zoveel economisch verlies was er dus niet geleden omdat mensen het werk later gewoon inhaalden.
Als een medewerker twee dagen niet vooruit kan, omdat de benodigde stukken niet aanwezig zijn: dan kan de medewerker dit wel inhalen, maar met een vaste deadline (vaak gesteld door de klant zelf), kan dit niet binnen de beschikbare uren.
Je argument gaat niet helemaal op :-)
Software ontwikkelen is nou eenmaal moeilijk, en zeker als het om grote, ingewikkelde systemen gaat dan is het gewoon onmogelijk om het 100% foutvrij te doen. Natuurlijk kun je vanalles doen om de kans te beperken dat er fouten inzitten (unit tests schrijven, en goede integratietests doen).

Het getal "1,6 miljard" op zichzelf zegt ook niet veel. Het is inderdaad veel geld als je puur naar het bedrag kijkt, maar waarmee moeten we het vergelijken? Je kunt hiermee niet concluderen hoe het gesteld is met de kwaliteit van de software.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True