Waarom de werkende klasse op een goudmijn zit

quote:

Op zaterdag 7 juni 2025 11:49 schreef blomke het volgende:

[..]
Kan alsnog....

Zeker.

Maar bedenk eens hoeveel geld er aan onzinopleidingen is en wordt weggegooid.

In mijn tijd op de Universiteit Utrecht was de duurste studie per student Culturele Antropologie. Studie waarmee je zo goed als niets kan. Was iets van 7x zo duur als het studiegeld dat je moest betalen.

Terwijl Rechtsgeleerdheid per student ongeveer de helft van het studiegeld kostte.

quote:

Op zaterdag 7 juni 2025 11:56 schreef VEM2012 het volgende:

[..]
Zeker.

Ik ga zo achter de kruiwagen lopen. TuiniereN!

quote:

Op zaterdag 7 juni 2025 11:56 schreef blomke het volgende:

[..]
Ik ga zo achter de kruiwagen lopen. TuiniereN!

In de regen? Bikkel!

quote:

Op zaterdag 7 juni 2025 09:58 schreef michaelmoore het volgende:

[..]
klopt het moet ook voor anderen heel eenvoudig te begrijpen en goed om mee te werken zijn

wat ik maakt daar kon iedereen mee werken zonder eerst iets gezegd te zijn, logisch toets en invul volgorde , gewoon onmogelijk maken om iets fout te doen

iedere stagiar kon gelijk aan het werk

Definieer iets fout doen? En trouwens een "software engineer" die roept "Onmogelijk iets fout te doen" neem ik niet echt serieus.

Gebruikers vinden altijd iets om fout te doen, of bewust user input bewerken om te hacken. Door ervaring weet je een beetje waarop je op moet letten..

Naast user input validatie, hoe zit het met je foutafhandeling? Hoe zit het met je maintainability? Etc etc..

quote:

Op zaterdag 7 juni 2025 11:39 schreef blomke het volgende:

[..]
Vreemde definitie. Ik ben puur technocraat, edoch mag de installatiedelen niet bedienen. Zelfs geen afsluiter openen/sluiten.

Verder zal zo'n loodgieter (ik zou zeggen "installateur") prima met z'n handen werken en idem terecht veel verdienen. Edoch, ik moet 'm tot in details uitleggen hoe de aansluitingen er moeten komen. Want enig denkwerk is hen vreemd.

Als installateur doe je er vaak goed aan de plannen met een flinke korrel zout te nemen en te behandelen als een ruwe richtlijn. Al was het maar, omdat de opsteller daarvan echt niet in de kruipruimte en op de zolder gaat kijken of alles daar ook echt geïnstalleerd kan worden en waar alle gaten moeten komen.

quote:

Op zaterdag 7 juni 2025 11:43 schreef VEM2012 het volgende:

[..]
Er is ingezet op meer hoger opgeleiden. Dat was het beleid. En dat is gelukt.

Alleen: als je een populatie hebt met zeg 7% die capaciteit hebben om het WO te volgen en op enig moment doet slecht 2% dat… ok, dan is het zinvol om te kijken naar de beperking van die andere 5%. En dat bleek ooit geld te zijn. Nou, dat is opgelost (tot dat te duur werd, maar dat is een ander verhaal).

Vervolgens wilde men dat succes nog groter maken.

Alleen, je kan je bevolking niet slimmer maken (niet helemaal waar, door import kan dat, maar ik hoef denk ik niet uit te leggen dat onze import eerder het gemiddelde niveau laat dalen). Dus als je verder gaat dan de 7% (is een fictief getal in de zin van dat ik niet bekend ben met een betrouwbaar cijfer in dezen), dan lukt dat alleen maar door het niveau te verlagen.

Dat is gebeurt en nadat het niveau eigenlijk niet meer omlaag kon kreeg je de afgelopen 10 jaar vooral onzinstudies erbij. Zoals gender studies.

De Westerse wereld holt zichzelf een beetje uit. En niet alleen de Westerse wereld overigens (ik ben zelf verbonden aan een niet-Westerse universiteit en daar had ik ook studenten die niet op een universiteit thuishoren). Als groei een doel wordt in plaats van een gevolg… dan ga je de gekste dingen zien.

Dat geldt voor opleidingen. Dat geldt voor bedrijven (daar heb ik dan wat meer dan gemiddeld verstand van). Dat geldt voor economie. Enz.

In de politiek moet ook op zeker moment alles SMART zijn. Toverwoord. Je kan je voorstellen dat op zo’n moment het doel in cijfers (specifiek en meetbaar!) heilig wordt en mensen vergeten waarom de doelstelling er was. En dat leidt er dan ook toe dat soms de doelstelling geweld aan wordt gedaan door maar te zorgen dat het cijfermatige doel bereikt wordt.

Om een treffend voorbeeld te geven: positieve discriminatie bij toelating aan universiteiten in de VS heeft geleid tot hogere aantallen toelatingen van bv Afro-Amerikanen. Dat vervolgens de uitval van deze studenten zeer hoog was en ze daardoor gemiddeld een lagere educatie kregen… tsja…

Het doel was gehaald.

En hetzelfde zie je dus met hoger opgeleiden. Daar hebben we er teveel van en een deel had veel en veel beter gewoon een vak kunnen leren.

TL;DR: het is uiteraard allemaal de schuld van de buitenlanders.

Dat we het niveau drastisch verlaagd hebben omdat minstens de helft van de bevolking tegenwoordig een hbo/VO studie moeten volgen ben ik zeker met je eens. Al was het maar omdat anders HR medewerkers niet eens meer gaan kijken naar jouw CV.

quote:

Op zaterdag 7 juni 2025 14:08 schreef michaelmoore het volgende:

[..]
in de ogen van de programma maker iets fout doen, daarom moet de programmamaker ook werkervaring op doen
want inderdaad vaak , / meestal ligt de fout bij de programmamaker, die begrijpt de routine niet , of de redenering erachter

Dit zijn niet echt bugs, maar meer interpretatiefouten, daarnaast heb je het fenomeen dat als je met extreem grote aantallen bewerkingen te maken krijgt, je ook tegen zaken aanloopt die vrij uitzonderlijk zijn, om een voorbeeld te geven, de meeste developer zullen denken dat een voornaam altijd 1 naam zonder spaties is, maar we hebben ook Nederlanders die vanuit een immigratie technisch gezien een voornaam hebben met een spatie erin.
Of een andere, niet iedereen heeft een geboortedatum, wat tot veel gedoe kan leiden van officieele zaken zoals bijvoorbeeld pensioen: https://www.binnenlandsbe(...)0-jj-blijft-probleem

quote:

Op zondag 8 juni 2025 11:56 schreef raptorix het volgende:

[..]
Dit zijn niet echt bugs, maar meer interpretatiefouten, daarnaast heb je het fenomeen dat als je met extreem grote aantallen bewerkingen te maken krijgt, je ook tegen zaken aanloopt die vrij uitzonderlijk zijn, om een voorbeeld te geven, de meeste developer zullen denken dat een voornaam altijd 1 naam zonder spaties is, maar we hebben ook Nederlanders die vanuit een immigratie technisch gezien een voornaam hebben met een spatie erin.
Of een andere, niet iedereen heeft een geboortedatum, wat tot veel gedoe kan leiden van officieele zaken zoals bijvoorbeeld pensioen: https://www.binnenlandsbe(...)0-jj-blijft-probleem

SCRUM. Iedereen hun taak en hun blokje, iteratie in plaats van plannen. Geen overzicht.

quote:

Op zondag 8 juni 2025 11:59 schreef SymbolicFrank het volgende:

[..]
SCRUM. Iedereen hun taak en hun blokje, iteratie in plaats van plannen. Geen overzicht.

SCRUM werkt prima, alleen denken sommige dat bij SCRUM geen documentatie of uitgebreide technische beschrijving hoort, daarnaast als je een lastig stuk moet implementeren wat zich bijvoorbeeld niet handig in sprints laat vertalen, dan kan het verstandig zijn om dat uit de SCRUM structuur te halen, en via een andere methode te bewerkstelligen. 99% van de projecten waarbij ik SCRUM verkeerd zie gaan is omdat mensen te snel denken aanpassingen te moeten doen, dan hoor ik: Wij doen onze eigen SCRUM methode, tjah en dan raar opkijken dat het een zooitje is.

quote:

Op zondag 8 juni 2025 12:05 schreef raptorix het volgende:

[..]
SCRUM werkt prima, alleen denken sommige dat bij SCRUM geen documentatie of uitgebreide technische beschrijving hoort, daarnaast als je een lastig stuk moet implementeren wat zich bijvoorbeeld niet handig in sprints laat vertalen, dan kan het verstandig zijn om dat uit de SCRUM structuur te halen, en via een andere methode te bewerkstelligen. 99% van de projecten waarbij ik SCRUM verkeerd zie gaan is omdat mensen te snel denken aanpassingen te moeten doen, dan hoor ik: Wij doen onze eigen SCRUM methode, tjah en dan raar opkijken dat het een zooitje is.

Als je SCRUM ziet als een lopende band voor massaproductie, werkt het goed. Aan de andere kant moet het natuurlijk ook mogelijk zijn om nieuwe dingen op te lossen door iteratie. Het ontwerp is meestal een initiële taakverdeling en de documentatie doe je achteraf, zodat je opvolger er ook mee uit de voeten kan. En het is natuurlijk ook zo, dat steeds minder mensen het geheel nog kunnen overzien, laat staan van te voren kunnen inschatten.

quote:

Op zondag 8 juni 2025 11:59 schreef SymbolicFrank het volgende:

[..]
SCRUM. Iedereen hun taak en hun blokje, iteratie in plaats van plannen. Geen overzicht.

Hoeveel scrum projecten heb jij gedaan? Dit slaat namelijk nergens op.
Wat je beschrijft lijkt vooral op hoe LIDL 500 miljoen verbrande op hun SAP implementatie. Namelijk helemaal geen management methodiek gebruiken.
Het LIDL SAP-debacle staat bekend als een schoolvoorbeeld van wat er mis kan gaan bij het ontbreken van een duidelijke projectmanagementmethodiek, effectieve governance en verandermanagement. De aanpak was vooral ad hoc, met te veel maatwerk, te weinig interne regie en onvoldoende sturing vanuit de top. Dit alles leidde tot een van de duurste ERP-fiasco’s in Europa, zonder dat er sprake was van een methodische, best practice-gebaseerde project- of programmamanagementaanpak.

quote:

Op zondag 8 juni 2025 12:10 schreef SymbolicFrank het volgende:

[..]
Als je SCRUM ziet als een lopende band voor massaproductie, werkt het goed. Aan de andere kant moet het natuurlijk ook mogelijk zijn om nieuwe dingen op te lossen door iteratie. Het ontwerp is meestal een initiële taakverdeling en de documentatie doe je achteraf, zodat je opvolger er ook mee uit de voeten kan. En het is natuurlijk ook zo, dat steeds minder mensen het geheel nog kunnen overzien, laat staan van te voren kunnen inschatten.

Nee SCRUm gaat over het snel en voorspelbaar opleveren van waarde, hierbij ga je uit van snelle feedback loops omdat het gevaar van een van te voren bedacht plan in de praktijk misschien niet goed uitpakt, hiermee verlies je dus onnodig tijd en mankracht. Het is hierbij wel van essentieel belang om te begrijpen of jouw project hier geschikt voor is, een mobiele app waarbij je nieuwe features wilt toevoegen is heel wat makkelijker dan Software die een Belasting berekening moet maken, waarbij je niet zomaar even wat zaken achteraf kunt bijstellen.

Welke methodiek je moet gebruiken hangt ook erg af van het soort project wat je doet. Voor het bouwen van een fabriek of schip zou ik eerder klassiek waterval nemen, voor het ontwikkelen van software APP is SCRUM zeer geschikt.

quote:

Op zondag 8 juni 2025 12:14 schreef raptorix het volgende:

[..]
Nee SCRUm gaat over het snel en voorspelbaar opleveren van waarde, hierbij ga je uit van snelle feedback loops omdat het gevaar van een van te voren bedacht plan in de praktijk misschien niet goed uitpakt, hiermee verlies je dus onnodig tijd en mankracht. Het is hierbij wel van essentieel belang om te begrijpen of jouw project hier geschikt voor is, een mobiele app waarbij je nieuwe features wilt toevoegen is heel wat makkelijker dan Software die een Belasting berekening moet maken, waarbij je niet zomaar even wat zaken achteraf kunt bijstellen.

Hou op, belastingdienst. tegen de rijd dat je een eerste versie in testen hebt is de wet en regelgeving weer veranderd en moet je de shit weer aanpassen. Tegelijkertijd wil de politiek daar niet van leren en dan brengen ze ook nog veel meer verantwoordelijkheden daar naar toe. De boel was destijds gevuld met extrenen die dan ook nog weer eens werden ingehuurd via het detacheringsbureau dat privé eigendom was van de directeur. Wat een Fucking Puinhoop

In mijn ervaring heeft ieder bedrijf een unieke manier om SCRUM te doen, die vaak alleen op de andere manieren lijkt door de gebruikte naamgeving. Met meer of minder onderhandeling over de duur en de inhoud van de individuele sprints. Er gewoon aan beginnen en een iteratieve benadering kom je meestal wel tegen.

quote:

Op zondag 8 juni 2025 12:20 schreef SymbolicFrank het volgende:
In mijn ervaring heeft ieder bedrijf een unieke manier om SCRUM te doen, die vaak alleen op de andere manieren lijkt door de gebruikte naamgeving. Met meer of minder onderhandeling over de duur en de inhoud van de individuele sprints. Er gewoon aan beginnen en een iteratieve benadering kom je meestal wel tegen.

Dat is een ziekte bij veel bedrijven, ze vinden hun eigen processen zoooo speciaal en ze zijn zooo bijzonder dat ze geen standaard SW willen gebruiken. Dit is wat er mis ging bij LIDL, Men wilde SAP, SAP wilde LIDL, maar vervolgens wilde LIDL hun eigen processen hanteren met een fundamenteel andere manier van werken dan waar SAP op gebaseerd is (Bijvoorbeeld retail prijzen vs inkoopprijs als leidraad)

quote:

Op zondag 8 juni 2025 12:20 schreef Jan_Onderwater het volgende:

[..]
Hou op, belastingdienst. tegen de rijd dat je een eerste versie in testen hebt is de wet en regelgeving weer veranderd en moet je de shit weer aanpassen. Tegelijkertijd wil de politiek daar niet van leren en dan brengen ze ook nog veel meer verantwoordelijkheden daar naar toe. De boel was destijds gevuld met extrenen die dan ook nog weer eens werden ingehuurd via het detacheringsbureau dat privé eigendom was van de directeur. Wat een Fucking Puinhoop

Omdat dit soort partijen door corrupte banden met de grote IT detacheerders er een zooitje van maken, als je weet dat de requirements vrij dynamisch zijn moet je daar in je Software rekening mee houden, maar goed aangezien ik vaker met dit soort partijen samen werk, weet ik precies wat ze doen, zodra een project een klein beetje staat, dan rammen ze hun juniors of waardeloze mensen erin, en zetten ze weg voor een Senior tarief, vervolgens krijg je dat ze op zich redelijke bestaande software op zo een manier omschrijven dat het Spaghetti word, en niemand die aan de bel trekt, tot de hele boel vast is gelopen, en dan begint het verhaaltje weer opnieuw met een nieuwe aanbesteding. Niemand geeft een fuck, er is toch geen eigenaarschap.

quote:

Op zondag 8 juni 2025 12:24 schreef raptorix het volgende:

[..]
Omdat dit soort partijen door corrupte banden met de grote IT detacheerders er een zooitje van maken, als je weet dat de requirements vrij dynamisch zijn moet je daar in je Software rekening mee houden, maar goed aangezien ik vaker met dit soort partijen samen werk, weet ik precies wat ze doen, zodra een project een klein beetje staat, dan rammen ze hun juniors of waardeloze mensen erin, en zetten ze weg voor een Senior tarief, vervolgens krijg je dat ze op zich redelijke bestaande software op zo een manier omschrijven dat het Spaghetti word, en niemand die aan de bel trekt, tot de hele boel vast is gelopen, en dan begint het verhaaltje weer opnieuw met een nieuwe aanbesteding. Niemand geeft een fuck, er is toch geen eigenaarschap.

De belastingbetaler heeft oneindig veel geld.

quote:

Op zondag 8 juni 2025 12:25 schreef Jan_Onderwater het volgende:

[..]
De belastingbetaler heeft oneindig veel geld.

Daarnaast hebben ze doorgaans ook zeer goede arbeidsvoorwaarden, waarbij niemand een fuck geeft, en dan krijg je dit:

quote:

People in a hierarchy such as a business or government will be promoted until they suck at their jobs, at which point they will remain where they are. As a result, the world is filled with people who suck at their jobs.

quote:

Op zondag 8 juni 2025 12:24 schreef Jan_Onderwater het volgende:

[..]
Dat is een ziekte bij veel bedrijven, ze vinden hun eigen processen zoooo speciaal en ze zijn zooo bijzonder dat ze geen standaard SW willen gebruiken. Dit is wat er mis ging bij LIDL, Men wilde SAP, SAP wilde LIDL, maar vervolgens wilde LIDL hun eigen processen hanteren met een fundamenteel andere manier van werken dan waar SAP op gebaseerd is (Bijvoorbeeld retail prijzen vs inkoopprijs als leidraad)

Ja, bij de meeste bedrijven "is het zo gegroeid" en dat zien ze als hun meerwaarde. (En dus ook de meerwaarde van de medewerkers.) En daar gaan dus ook alle kosten in zitten. Je bent tegenwoordig veel beter uit door het gewoon op de "normale" manier te doen. Dan kun je het meestal ook uitbesteden door de bestaande software en systemen van je handelspartners te gebruiken.

Helaas weten de mensen die over zulke dingen de beslissingen nemen zelden iets van software en processen.

quote:

Op zondag 8 juni 2025 12:30 schreef SymbolicFrank het volgende:

[..]
Ja, bij de meeste bedrijven "is het zo gegroeid" en dat zien ze als hun meerwaarde. (En dus ook de meerwaarde van de medewerkers.) En daar gaan dus ook alle kosten in zitten. Je bent tegenwoordig veel beter uit door het gewoon op de "normale" manier te doen. Dan kun je het meestal ook uitbesteden door de bestaande software en systemen van je handelspartners te gebruiken.

Helaas weten de mensen die over zulke dingen de beslissingen nemen zelden iets van software en processen.

Het meest giftige wat ik heb meegemaakt en ook bij mijn huidige organisatie word gedaan is dat hoger Management SCRUM als een meetmethode ziet en letterlijk scrumpunten als Metric gebeurt, nu zal het mij een worst wezen, wij runnen onze projecten met zijn tweeën en officieel onder leiding van een PM waarbij we gezegd hebben: Wij zijn allebei senior genoeg om het zelf te plannen, aangezien management uiterst content met onze projecten is vind zij het ook best. Het enige waar we commitment aangeven is een soort van Kwartaal doel, en dat lukt prima, we doen niet aan standups maar bespreken 2 keer per week even kort wat we gaan doen, alle zaken die tussendoor komen lossen we bij voorkeur direct op zodat we geen backlog opbouwen.

quote:

Op zondag 8 juni 2025 12:39 schreef raptorix het volgende:

[..]
Het meest giftige wat ik heb meegemaakt en ook bij mijn huidige organisatie word gedaan is dat hoger Management SCRUM als een meetmethode ziet en letterlijk scrumpunten als Metric gebeurt, nu zal het mij een worst wezen, wij runnen onze projecten met zijn tweeën en officieel onder leiding van een PM waarbij we gezegd hebben: Wij zijn allebei senior genoeg om het zelf te plannen, aangezien management uiterst content met onze projecten is vind zij het ook best. Het enige waar we commitment aangeven is een soort van Kwartaal doel, en dat lukt prima, we doen niet aan standups maar bespreken 2 keer per week even kort wat we gaan doen, alle zaken die tussendoor komen lossen we bij voorkeur direct op zodat we geen backlog opbouwen.

Klinkt praktisch, maar is het dan nog SCRUM?

Het is natuurlijk ook iets anders als je onderhoud/ondersteuning doet, of iets compleet nieuws gaat bouwen. Het gezegde dat een goed vooronderzoek het halve werk is gaat nog steeds op, alleen moet je van te voren al weten hoe het er uit gaat zien en hoeveel het gaat kosten. En je moet ook meteen beginnen met bouwen (produceren), want al die andere dingen worden al snel gezien als onkunde of geldverspilling.

Ik draai het altijd om: ik bedenk wat de beste manier is om iets uit te voeren en dan hoor ik achteraf wel of dat ook een bestaande methodiek is. Meestal door alles te normaliseren en uit te zoeken wat nou eigenlijk het doel is wat ze er mee proberen te bereiken.

quote:

Op zondag 8 juni 2025 12:39 schreef raptorix het volgende:

[..]
Het meest giftige wat ik heb meegemaakt en ook bij mijn huidige organisatie word gedaan is dat hoger Management SCRUM als een meetmethode ziet en letterlijk scrumpunten als Metric gebeurt, nu zal het mij een worst wezen, wij runnen onze projecten met zijn tweeën en officieel onder leiding van een PM waarbij we gezegd hebben: Wij zijn allebei senior genoeg om het zelf te plannen, aangezien management uiterst content met onze projecten is vind zij het ook best. Het enige waar we commitment aangeven is een soort van Kwartaal doel, en dat lukt prima, we doen niet aan standups maar bespreken 2 keer per week even kort wat we gaan doen, alle zaken die tussendoor komen lossen we bij voorkeur direct op zodat we geen backlog opbouwen.

Een SCRUM Projectmanager???? Of begrijp ik je nu verkeerd?

quote:

Op zondag 8 juni 2025 12:48 schreef Jan_Onderwater het volgende:

[..]
Een SCRUM Projectmanager???? Of begrijp ik je nu verkeerd?

Nouja, ze weten het zelf niet, officieel mogen we het geen SCRUM noemen geloof ik, daarom lopen er ook nog Agile Coaches rond, geloof dat de Projectmanager officieel Portfolio Manager heten, omdat het een soort van mix tussen SAFE en en Scrum is waarbij de Agile Coaches er een beetje richting aan proberen te geven. SAFE is ook weer een heel ander verhaal, ik ken iemand die zelf 1 van de best SAFE specialisten is in Nederland en die zegt ook: SAFe werkt vooral bij Amerikaanse bedrijven om iedereen waarvan niet duidelijk is wat die nou precies doet er uit te werken. In Nederland werkt dat natuurlijk niet omdat die mensen gewoon blijven zitten.

quote:

Op zondag 8 juni 2025 12:47 schreef SymbolicFrank het volgende:

[..]
Klinkt praktisch, maar is het dan nog SCRUM?

Het is natuurlijk ook iets anders als je onderhoud/ondersteuning doet, of iets compleet nieuws gaat bouwen. Het gezegde dat een goed vooronderzoek het halve werk is gaat nog steeds op, alleen moet je van te voren al weten hoe het er uit gaat zien en hoeveel het gaat kosten. En je moet ook meteen beginnen met bouwen (produceren), want al die andere dingen worden al snel gezien als onkunde of geldverspilling.

Ik draai het altijd om: ik bedenk wat de beste manier is om iets uit te voeren en dan hoor ik achteraf wel of dat ook een bestaande methodiek is. Meestal door alles te normaliseren en uit te zoeken wat nou eigenlijk het doel is wat ze er mee proberen te bereiken.

Met de huidige software methodes kun je ook prima bestaande zaken inpassen, je moet dan wel goed weten hoe dat moet en het is zeker ook niet goedkoop maar wel betrouwbaar.

quote:

Op zondag 8 juni 2025 12:54 schreef raptorix het volgende:

[..]
Met de huidige software methodes kun je ook prima bestaande zaken inpassen, je moet dan wel goed weten hoe dat moet en het is zeker ook niet goedkoop maar wel betrouwbaar.

Grootste gemene deler.

Eind vorige eeuw werd je als software ontwikkelaar geacht alles zelf te kunnen: met de opdrachtgevers gaan praten, meekijken bij de gebruikers, een ontwerp en offerte maken, de productie, overdracht, opleidingen en nazorg. Tegenwoordig heeft een bedrijf daar al gauw 10 verschillende mensen voor in dienst, als ze het niet gewoon over de schutting gooien.

Kortom, het is in hapklare brokjes gehakt en iedereen doet hun ding. Het is vereenvoudigd totdat de gemiddelde mens het met de juiste opleiding kan doen.

Als je gewend bent om dat allemaal zelf te doen en bij ieder bedrijf een totaal andere manier van werken tegenkomt, maak je je daar allemaal niet druk om. Het is meer een kwestie van wat er op dit moment in de mode is.

quote:

Op zondag 8 juni 2025 13:05 schreef SymbolicFrank het volgende:

[..]
Grootste gemene deler.

Eind vorige eeuw werd je als software ontwikkelaar geacht alles zelf te kunnen: met de opdrachtgevers gaan praten, meekijken bij de gebruikers, een ontwerp en offerte maken, de productie, overdracht, opleidingen en nazorg. Tegenwoordig heeft een bedrijf daar al gauw 10 verschillende mensen voor in dienst, als ze het niet gewoon over de schutting gooien.

Kortom, het is in hapklare brokjes gehakt en iedereen doet hun ding. Het is vereenvoudigd totdat de gemiddelde mens het met de juiste opleiding kan doen.

Als je gewend bent om dat allemaal zelf te doen en bij ieder bedrijf een totaal andere manier van werken tegenkomt, maak je je daar allemaal niet druk om. Het is meer een kwestie van wat er op dit moment in de mode is.

Uiteindelijk is Agile meer een mindset dan strikt het SCRUM framework. Je moet toch kijken wat het beste werkt voor de organisatie of zelfs soms team (of squad zoals ze inmiddels bij ons heten).

Moeilijkste is wel de ceremonies van nut laten zijn, heb wel eens meegemaakt dat we ze gingen doen omdat het "moest". Dan ben je het halve team zo kwijt. Terwijl als je ervoor zorgt dat ze wel degelijk van nut zijn, men ook minder snel loopt te klagen over het aantal meetings etc.

quote:

Op zaterdag 7 juni 2025 14:08 schreef michaelmoore het volgende:

[..]
in de ogen van de programma maker iets fout doen, daarom moet de programmamaker ook werkervaring op doen
want inderdaad vaak , / meestal ligt de fout bij de programmamaker, die begrijpt de routine niet , of de redenering erachter

Mwah mijn ervaring is dat met in-house build software dat soort issues wel meevallen. Die lijntjes zijn tegenwoordig vrij kort bij veel bedrijven.

Koop je software aan dan begint het al wat lastiger te worden, want dan kan de eigen IT vaak weinig aanpassen.

Ik werk nu met aangekochte software waar wij een o.a. een ETL laag voor schrijven, soms lopen we dan gewoon tegen de grenzen van het aangekochte systeem aan.. Dan is het toch vaak dat er eventueel procedures aangepast moeten worden.

Dat gold overigens nog meer voor mijn vorige project, het huidige project is iets met geospatial data wat vrij nieuwe is binnen de sector; procedures zijn er dus nog niet echt. Die mogen o.a. onze BA's maken.

quote:

Op maandag 9 juni 2025 07:28 schreef The-BFG het volgende:

[..]
Mwah mijn ervaring is dat met in-house build software dat soort issues wel meevallen. Die lijntjes zijn tegenwoordig vrij kort bij veel bedrijven.

Koop je software aan dan begint het al wat lastiger te worden, want dan kan de eigen IT vaak weinig aanpassen.

Ik werk nu met aangekochte software waar wij een o.a. een ETL laag voor schrijven, soms lopen we dan gewoon tegen de grenzen van het aangekochte systeem aan.. Dan is het toch vaak dat er eventueel procedures aangepast moeten worden.

Dat gold overigens nog meer voor mijn vorige project, het huidige project is iets met geospatial data wat vrij nieuwe is binnen de sector; procedures zijn er dus nog niet echt. Die mogen o.a. onze BA's maken.

Dat is het probleem met biebjes. Tegenwoordig gebruiken teams al gauw het werk van honderden andere teams in hun software. Het begint bijvoorbeeld met een datum-tijd selecteer dialoogje. Dat is vreselijk veel werk, dus dan kun je beter iets pakken wat al bestaat. Maar dat is weer een buitenkantje voor een datum-tijd bibliotheek, want dat wil je ook niet moeten maken. Die weer een bibliotheek met conversiefuncties gebruikt, wat ook weer gespecialiseerd werk is. En uiteindelijk zitten er ook gewoon een paar hele simpele functies in die wat aparte dingen doen. Dat zijn al gauw meer dan tien verschillende projecten, die ook allemaal bijgehouden moeten worden.

En ja, dan heb je zo wat dingen bij elkaar gesprokkeld en die met een style sheet wat uniform gemaakt. Maar dan gaat iemand datumtijden invoeren in een grid en dan wordt er geklaagd dat de stijl totaal anders is en daar werk van gemaakt moet worden. Hm, een grid. Ook zo'n ding wat je zelf niet wilt maken als daar meer dan platte tekst in moet. En zelfs dan. Dat is dus ook een hele set biebjes die je ergens van het internet hebt geplukt. Dan moet je van 1 of twee van die componenten uit gaan zoeken hoe ze in elkaar zitten en je eigen versie maken.

Maar ja, die achterliggende biebjes worden ook regelmatig aangepast en ververst. Daar moet je dan ook aan mee gaan doen: regelmatig nieuwe versies downloaden, aanpassen naar je eigen versie, indien nodig compileren en/of bouwen en dan kijken of het nog werkt. En die achterliggende projectjes worden geforkt, of de ontwikkeling wordt gestopt, of het wordt vervangen door wat anders. En er zijn meer teams die allemaal een eigen variant bijhouden. Dus na een tijdje valt het om. Als je dan een nieuwe collega krijgt, kan die geen werkende versie meer installeren. Dus moet je een kopietje van jouw ontwikkelomgeving maken en je eigen versie gaan samenstellen en onderhouden.

Hedendaagse softwareontwikkeling in een notendop

Je kunt het ook gewoon allemaal zelf doen, als je weet hoe het werkt. Initieel wat meer werk, maar dan ben je meteen van al die ellende af. Totdat je een nieuw front-end en programmeertaal moet gaan gebruiken. Of het allemaal naar de cloud moet. Of de database te groot wordt. Enzovoorts. Als de mode verandert, dus.