De Devschuur Coffee Corner - Iteratie ⓫

[DevWouter]

alienfruit schreef op maandag 16 juli 2018 @ 10:48:
Soms herschrijven wij gedeelten van projecten voornamelijk omdat SAP nu de mogelijkheid ingebouwd heeft en zodoende vervolgens SAP's zijn zorg is

Dat is wat ik dan ook een partial rewrite noem. Een complete rewrite is vanaf 0 beginnen.

ThomasG schreef op maandag 16 juli 2018 @ 11:43:
[...]
Dat is natuurlijk zo als je er vanuit gaat dat er goede code geschreven is; dus niet of het voldoet aan de (gewijzigde) requirements, maar of het onderhoudbaar is e.d.

Het gaat niet om kwaliteit van de code, maar of de code onderhouden moet worden. Als de code niet onderhouden hoeft te worden, dan zal de opdrachtgever noch de ontwikkelaar geïnteresseerd zijn in de kwaliteit van de code.
Uiteraard eist de opdrachtgever van de ontwikkelaar wel dat het onderhoudbaar is omdat er maar weinig software is waar uiteindelijk geen onderhoud aan gepleegd moet worden.

farlane schreef op maandag 16 juli 2018 @ 12:30:
[...]

Dus wat mij betreft ligt de burden of proof bij jou wat betreft de claim dat hij geen autoriteit is.

Eerder https://yourlogicalfallacyis.com/the-fallacy-fallacy bovendien weet ik niet of Joel een expert is op complete rewrites. Hij draagt in dat verhaal alleen anekdotes van anderen aan waar het fout ging. Er zijn ook minder bekende verhalen waar het goed ging (zoals Twitter en BaseCamp). Verder is er ook geen empirisch onderzoek waardoor een autoriteit moeilijk te verifiëren is.

[Mugwump]

Het is ook een beetje een definitiekwestie. Een full rewrite is niet per definitie een bigbangproces waarbij je in één klap een nieuw systeem neerzet, maar een geleidelijk proces waarbij je steeds meer stukjes functionaliteit van oud systeem A over zet naar systeem B.

[.oisyn]

DevWouter schreef op maandag 16 juli 2018 @ 12:55:
https://yourlogicalfallacyis.com/the-fallacy-fallacy

Beetje slecht voorbeeld:

Example: Recognising that Amanda had committed a fallacy in arguing that we should eat healthy food because a nutritionist said it was popular, Alyse said we should therefore eat bacon double cheeseburgers every day.

Iedereen weet dat bacon double cheeseburgers een valide antwoord is op alles

[farlane]

DevWouter schreef op maandag 16 juli 2018 @ 12:55:
[...]
Eerder https://yourlogicalfallacyis.com/the-fallacy-fallacy bovendien weet ik niet of Joel een expert is op complete rewrites. Hij draagt in dat verhaal alleen anekdotes van anderen aan waar het fout ging. Er zijn ook minder bekende verhalen waar het goed ging (zoals Twitter en BaseCamp). Verder is er ook geen empirisch onderzoek waardoor een autoriteit moeilijk te verifiëren is.

Ik weet het ook niet, maar zijn "authority" wordt in twijfel getrokken terwijl als je even verder kijkt het duidelijk is dat hij behoorlijk wat ervaring heeft.

Daarbij wordt zijn "programmeerkennis" ter discussie gesteld terwijl de beslissing of een rewrite verstandig is of niet daar relatief weinig mee te maken heeft.

[Vincentio]

alienfruit schreef op maandag 16 juli 2018 @ 10:48:
Soms herschrijven wij gedeelten van projecten voornamelijk omdat SAP nu de mogelijkheid ingebouwd heeft en zodoende vervolgens SAP's zijn zorg is

Wij hebben juist een keer iets van SAP geheel herschreven. Wat een ramp waren die eerste gen SAP CRM Fiori Apps. Die voldoen niet echt aan de guidelines van SAP

Alleen heeft onze versie helaas ook geen lang leven begreep ik laatst, aangezien men daar nu aan het kijken is naar SalesForce voor CRM

[Hydra]

gold_dust schreef op zondag 15 juli 2018 @ 10:36:
Daar ben ik het niet mee eens, software heeft absoluut een maximale houdbaarheidsdatum.

Misschien moet je het artikel ook eens lezen

Hij zegt niet dat dat software niet herschreven moet worden. Hij zegt dat je het niet weg moet flikkeren en helemaal van nul moet beginnen. Het strangler pattern is een bekend voorbeeld van een patroon dat hier gebruikt kan worden. Het is een van de basisprincipes achter evolutionary architectures; de applicatie blijft vaak enorm lang bestaan en dus zul je veranderingen moeten omarmen.

Als je daadwerkelijk het artikel helemaal ff gelezen had, dus wel bij de conclusie aangekomen was, had je ook een aantal alternatieven voor een complete rewrite 'from scratch' gezien.

[alienfruit]

@Vincentio Volgens mij hebben wij ooit eens de workflow meuk van SAP herschreven

[DevWouter]

farlane schreef op maandag 16 juli 2018 @ 14:07:
[...]

Ik weet het ook niet, maar zijn "authority" wordt in twijfel getrokken terwijl als je even verder kijkt het duidelijk is dat hij behoorlijk wat ervaring heeft.

Daarbij wordt zijn "programmeerkennis" ter discussie gesteld terwijl de beslissing of een rewrite verstandig is of niet daar relatief weinig mee te maken heeft.

Ik benoem de "fallacy fallacy" omdat @gold_dust zijn argument onderbouwde met iets wat niet juist was. Joel is namelijk wel een expert op het gebied van software en software ontwikkeling gezien zijn achtergrond bij Microsoft en zijn werk in VBA.

Verder betwijfel ik of hij een expert is op "complete rewrites van scratch". Zijn autoriteit op dat gebied lijkt zich te ontlenen dat hij vaak in combinatie van het onderwerp genoemd wordt, maar niet op zijn prestaties in tegenstelling tot iemand zoals David Heinemeier Hansson (BaseCamp), welke gedurende de discussie niet genoemd werd en juist een voorstander is van rewrites.
Echter bij DHH kan je ook twijfel hebben omdat hij "maar" twee succesjes op zijn naam heeft.

We hebben dus een situatie waarbij de "meeste genoemde autoriteit" tegengesproken wordt door een "autoriteit met meer publieke prestaties". En er zijn geen empirische gegevens om één van beide te ondersteunen.

Het zou dus een fallacy fallacy zijn om te zeggen dat "Complete rewrites slecht zijn omdat Joel, een expert, dat aangeeft".
Ja, ik ben me bewust dat jij dat niet claimt

Mugwump schreef op maandag 16 juli 2018 @ 13:13:
Het is ook een beetje een definitiekwestie. Een full rewrite is niet per definitie een bigbangproces waarbij je in één klap een nieuw systeem neerzet, maar een geleidelijk proces waarbij je steeds meer stukjes functionaliteit van oud systeem A over zet naar systeem B.

Goed punt. Er zijn genoeg scenario's te bedenken waar je over kan discussiëren of het wel/niet een full rewrite is.

[gold_dust]

Die Joel Spolsky is een ondernemer, hij heeft verschillende bedrijven gehad en runt nu een website. Dat stuk over 'how to price software' herinner ik me vooral, dat was goed en doeltreffend en maakt duidelijk dat hij meer een 'business' type is. Die artikelen over software ontwikkeling of 'how to hire a programmer' zijn soms tenenkrommend. Het is prima dat hij overal een duidelijke mening over heeft maar kondig dat dan niet als absolute waarheid aan.

Ik denk dat hij snel z'n mening zou herzien over software refactoring(aka puin ruimen) als hij eenmaal bij de legacy clubjes waar ik gezeten heb op bezoek is geweest. Bovendien gaan goede ontwikkelaars helemaal geen puin van iemand anders ruimen maar die gaan op zoek naar een bedrijf waar ze interessante software kunnen ontwikkelen. Hij is met z'n duidelijke voorkeur voor refactoring misschien wel wat minder goed dan dat hij zelf denkt dat hij is.

[incaz]

Maar toch he, @gold_dust, heb je ook inhoudelijkere argumenten? Want als je Spolky's autoriteit verwerpt, dan is 'de legacy clubjes waar ik gezeten heb' van een willekeurige Tweaker niet echt een sterke onderbouwing, toch?
Spolsky noemt in dat artikel een aantal behoorlijk concrete argumenten waarom totaal van de grond opbouwen van nieuwe code vaak niet oplevert wat het belooft. Met welke van die argumenten ben jij het oneens en waar baseer je dat op? Dat maakt het een stuk interessanter dan alleen maar persoonlijke kritiek.

[Mugwump]

DevWouter schreef op maandag 16 juli 2018 @ 16:37:


[...]


Goed punt. Er zijn genoeg scenario's te bedenken waar je over kan discussiëren of het wel/niet een full rewrite is.

Het hele idee achter de strangler design pattern is dat je een legacy systeem geleidelijk aan uitfaseert.
Big bang faalt heel vaak. Ik zie projecten om bijvoorbeeld een CRM systeem te vervangen ook vaak genoeg grandioos falen. Ooit een keer een feestje gehad omdat collega's na pakweg 2,5 jaar een CRM migratietraject hadden afgerond, maar een week later moest de oude boel weer terug en moest het hele project opnieuw gedaan worden. Inmiddels zijn we pakweg vier jaar verder en ik hoor van oud-collega's dat ze nog steeds niet in staat zijn om het oude systeem uit te zetten. Ook wel lekker qua licentiekosten.

[Merethil]

Mugwump schreef op maandag 16 juli 2018 @ 19:24:
[...]


Het hele idee achter de strangler design pattern is dat je een legacy systeem geleidelijk aan uitfaseert.
Big bang faalt heel vaak. Ik zie projecten om bijvoorbeeld een CRM systeem te vervangen ook vaak genoeg grandioos falen. Ooit een keer een feestje gehad omdat collega's na pakweg 2,5 jaar een CRM migratietraject hadden afgerond, maar een week later moest de oude boel weer terug en moest het hele project opnieuw gedaan worden. Inmiddels zijn we pakweg vier jaar verder en ik hoor van oud-collega's dat ze nog steeds niet in staat zijn om het oude systeem uit te zetten. Ook wel lekker qua licentiekosten.

Heb zelf net een migratie van een oud CRM naar een nieuwe (Salesforce) achter de rug en merk dat we dit niet hadden kunnen doen als we niet alles automatisch lieten syncen tussen het nieuwe en oude systeem. Zolang niet alle mogelijkheden in de nieuwe zat, konden ze daarvoor nog het oude systeem gebruiken en bleef de data toch prima in sync.

Nu dat we om zijn merken we heel veel voordelen, maar de aanpak van geen big-bang heeft hier zoveel geholpen en ervoor gezorgd dat we mensen niet teleurgesteld hebben met "feature A is er nog niet", wat de customer service continue even hoog heeft gehouden als voorheen.

[Alex)]

Vincentio schreef op maandag 16 juli 2018 @ 14:15:
[...]

Alleen heeft onze versie helaas ook geen lang leven begreep ik laatst, aangezien men daar nu aan het kijken is naar SalesForce voor CRM

Ik heb onlangs eens voor de grap naar Salesforce CRM gekeken en werd daar niet heel enthousiast van als ik eerlijk ben. Als je je hele leven in SAP GUI hebt gewerkt zal SF vast een hele vernieuwing zijn* maar in vergelijking met wat Microsoft voor CRM in huis heeft vond ik het nou niet wereldschokkend.

SF heeft dan natuurlijk wel de rest van het ecosysteem eromheen.

* Niks mis met SAP GUI an sich, maar er is wel te merken dat het is bedacht door engineers.

[gold_dust]

incaz schreef op maandag 16 juli 2018 @ 19:10:
Maar toch he, @gold_dust, heb je ook inhoudelijkere argumenten? Want als je Spolky's autoriteit verwerpt, dan is 'de legacy clubjes waar ik gezeten heb' van een willekeurige Tweaker niet echt een sterke onderbouwing, toch?

Hij verkondigt in iets van een 'things you should never do list' dat 'rewrite from scratch' daar toe behoort, de precieze bewoording weet ik niet meer. Zo zwart/wit is het niet, er zijn genoeg scenario's waar herschrijven de enige oplossing is.

Wat die Amerikanen roepen moet je met een korrel zout nemen. Ik heb er zelf ook gewoond en het is allemaal behoorlijk overdreven. Zo goed zijn ze technisch uiteindelijk niet en het ontbreekt aan een stuk nuchterheid. Dat zie ook terug in die techblogs.

Ik werk nu ook voor een groot Amerikaans bedrijf en blijkbaar nemen die toch liever een remote Europeaan ondanks al die briljante Amerikanen zoals Joel Spolsky en z'n team. De 'getting things done' mentaliteit ontbreekt bij Amerikanen vaak, hoe mooi ze zich ook in een blog kunnen verkopen.

[ Voor 5% gewijzigd door gold_dust op 16-07-2018 20:59 ]

[incaz]

gold_dust schreef op maandag 16 juli 2018 @ 20:56:
[...]
Hij verkondigt in iets van een 'things you should never do list' dat 'rewrite from scratch' daar toe behoort, de precieze bewoording weet ik niet meer.

Lees het eens terug, want hij zegt dat niet zomaar, hij geeft daarbij ook een behoorlijke onderbouwing. Als je het daar niet mee eens bent, ben ik meer geinteresseerd in welk deel van die onderbouwing jij niet vindt kloppen dan in je vooroordelen richting personen, beroepen of nationaliteiten.

[gekkie]

incaz schreef op maandag 16 juli 2018 @ 21:01:
[...]


Lees het eens terug, want hij zegt dat niet zomaar, hij geeft daarbij ook een behoorlijke onderbouwing. Als je het daar niet mee eens bent, ben ik meer geinteresseerd in welk deel van die onderbouwing jij niet vindt kloppen dan in je vooroordelen richting personen, beroepen of nationaliteiten.

Ik denk dat het probleem hem vooral zit in de absolutisme van:

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

Klinkt niet echt genuanceerd of wel ?
Zit ik dan met m'n ponskaartjes met machine code voor die veredelde buizen rekenmachine ter grote van een gymzaal. Nee baas .. de enige echte grote strategische vergissing die je ook maar ooit zou kunnen maken is een rewrite .. nieuwe hardware eronder en gaan met die banaan.
Nee het absolutisme de andere kant op, rewriten om het rewriten omdat nieuw gras altijd nog groenerderderder is is ook geen goed idee, maar iets genuanceerders als "bezint eer ge begint" zal het wel niet redden ... hier in NL al niet meer, maar aan de andere zijde van de grote plas al helemaal niet vrees ik.

In sommige gevallen kun je het best lang uitzingen met je legacy bijna ponskaartachtige systemen, neem de banken met hun cobol en batchgewijze verwerking (zeker bij interbankair verkeer). Al schuurt dat nu ook steeds harder met de verwachting van de klanten dat alles instant overgeboekt is (en het alleen overgeboekt laten lijken is ook maar een beperkt lapmiddel).

Maar goed als je systeem al enigzins modulair is zal naar waarschijnlijkheid een partial rewrite meestal wel beter uitpakken door de geleidelijkheid waarmee het proces dan kan worden doorlopen. Ook zal het wellicht zelfs nog kunnen lonen op als het tegen niet al te grote inspanning mogelijk is je legacy code meer modulair te maken als het dat nog niet is en voor een partial rewrite te kiezen ipv een full rewrite.
Toch zullen er situaties zijn waarin het niet loont, dus "the single worst" en "any software company" zijn mij te absoluut.

[ Voor 55% gewijzigd door gekkie op 16-07-2018 21:56 ]

[DevWouter]

gold_dust schreef op maandag 16 juli 2018 @ 20:56:
Zo zwart/wit is het niet, er zijn genoeg scenario's waar herschrijven de enige oplossing is.

<troll-lol-lol-lol>
Je begint met een nuance ("het is niet zo zwart-wit") om vervolgens met een absoluut termen te eindigen ("de enige oplossing").
</troll-la-la-la>

Net zoals incaz heb ik mijn twijfels bij deze uitspraak. Er zullen vast scenario's te bedenken waarbij herschrijven een oplossing is, echter ik kan me er geen "genoeg" bedenken waar het een echt goeie keus is. Kan jij op basis van mijn opsomming eerder aangeven welke scenario's jij mis en waarom een herschrijving daar meer voorkeur zou moeten hebben?

---

gekkie schreef op maandag 16 juli 2018 @ 21:27:
Ik denk dat het probleem hem vooral zit in de absolutisme van:

Goed gevonden! Bij mij was automatisch de koreltje-zout-filter geactiveerd

[gekkie]

DevWouter schreef op dinsdag 17 juli 2018 @ 00:59:
Goed gevonden! Bij mij was automatisch de koreltje-zout-filter geactiveerd

Oh bij mij ook wel hoor, het wat scherper neer zetten is een niet ongebruikelijk stijlfiguur wat ook goed werkt als je wat discussie er over los wilt krijgen (zoals je hier ook nog ziet tig jaar na dato )


On another note ... uit de uitspraak behorende bij:
nieuws: Kaspersky wint zaak over krantenartikel met hackclaims van 'Nieuwsuur...

in de zaak van

de besloten vennootschap met beperkte aansprakelijkheid
KASPERSKY LAB B.V.,
gevestigd te Utrecht,
eiseres in conventie bij dagvaarding van 15 juni 2018,
verweerster in reconventie,

advocaat mr. O.G. Trojan te 's-Gravenhage,

Toeval of humor ?

[mcDavid]

Ik vind het vooral mooi dat de verdediging van de Telegraaf zich beroept op "Maar mensen weten toch wel dat het onzin is wat wij publiceren?"

[Mugwump]

Het stuk van Joel gaat misschien ook meer op voor het type software als een wijdverspreide desktopbrowser die je niet makkelijk centraal bijwerkt. In mijn ogen zie je dat ook aan de gevallen waarin een full rewrite slaagt en die waar het mislukt. Bij zaken als webbrowsers en operating systems zie je veel mislukkingen, terwijl er genoeg voorbeelden van online platformen zoals ebay zijn met (meerdere) complete rewrites. Het grote voordeel bij zo'n platform is dat er doorgaans slechts één productieversie is. Dit in tegenstelling tot de version hell die je krijgt als je software uitlevert aan partijen waardoor je vaak minimaal tientallen versies van een codebase moet supporten. Dan krijg je inderdaad het soort nadelen dat hij noemt waarbij je hele development op andere versies stil komt te liggen.
Collega's van me zijn bijvoorbeedl bezig met een rewrite van zo'n oude situatie (uitgeleverde applicatie) naar een SaaS oplossing die als vervanging dient te komen. Ja, dat kost je capaciteit op je oude software, maar als het niet gebeurt, dan mis je wel een duidelijke markttrend en wordt je overschaduwd door concurrenten. Dus wat dat betreft geldt voor dit net zo goed dat je met het niet gaan voor een flinke rewrite uiteindelijk je marktpositie verliest.

Er zitten ook wel wat aannames in het stuk van Joel die voor lang niet alle software opgaan zoals deze:

Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it.

Ik heb heel wat projecten gezien. Het komt vaak genoeg voor dat er helemaal niet 'goed getest' is. Of er wordt zoals in een recent project best aardig getest, maar één of andere tyrannieke, incompetente developer poeiert testers en business af waardoor met een stuk software accepteert dat op geen enkele wijze voldoet en vol met bugs en quirks zit.
Of tijd en budget zijn op een gegeven moment gewoon op en dan wordt maar geaccepteerd wat er gebouwd is. Deze claim zou eerder moeten zijn:

Old code that has been running in production and adopted by the business has been used. If there was any budget for incremental improvement there have been a lot of bugfixes. In the current state it is acceptable to the business.

Maar ja, helaas is dit bij lange na niet altijd de realiteit van een softwareproject.

[DevWouter]

Mugwump schreef op dinsdag 17 juli 2018 @ 10:30:
[...]

Ik heb heel wat projecten gezien. Het komt vaak genoeg voor dat er helemaal niet 'goed getest' is. Of er wordt zoals in een recent project best aardig getest, maar één of andere tyrannieke, incompetente developer poeiert testers en business af waardoor met een stuk software accepteert dat op geen enkele wijze voldoet en vol met bugs en quirks zit.

Hmm... Ik lees dat eerder als "bewezen in de praktijk".

Anekdote tijd!

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[mcDavid]

@DevWouter huh? Dat kon je toch oplossen door de gebruiker te vertellen wat 'ie verkeerd doet?

[incaz]

Maar, voor je ervan uitgaat dat het de gebruiker is die iets fout doet: de kans is groot dat er een andere situatie is waarin het nodig is om op enter te drukken voor er iets gebeurt. Dat soort ingeslepen gewoontes hebben vaak een bredere achtergrond dan 'snapt het niet.'
En dat is belangrijk, omdat het dan dus ook kan betekenen dat het bijna niet aan te leren is voor een gebruiker van een programma om het anders te doen - niet omdat het een ingewikkeld concept is, maar omdat je twee tegengestelde patronen moet automatiseren. In die situaties is het toch veel gebruiksvriendelijker om dat gebruik serieus te nemen, dan vast te houden aan hoe je als dev dent dat het moet.

(Dat verschilt per situatie, maar ik heb toch wel heel vaak gezien dat gebruikershandelingen vaak logischer zijn dan het op het eerste gezicht lijkt. Note: omdat het hier vaak om onbewuste handelingen gaat zijn ze ten eerste niet zo makkelijk om te vormen, en ten tweede weten mensen vaak niet precies waarom ze ze doen.)

[Mugwump]

DevWouter schreef op dinsdag 17 juli 2018 @ 13:16:
[...]


Hmm... Ik lees dat eerder als "bewezen in de praktijk".

Anekdote tijd!

***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[DevWouter]

mcDavid schreef op dinsdag 17 juli 2018 @ 13:47:
@DevWouter huh? Dat kon je toch oplossen door de gebruiker te vertellen wat 'ie verkeerd doet?

Het gaat er niet zo zeer om wie wat goed of fout doet, maar wat het beste is voor het team.

Mugwump schreef op dinsdag 17 juli 2018 @ 14:05:
[...]
***members only***

Ah, juist, nu ik het herlees zie ik inderdaad dat je iets heel anders bedoelde dan wat ik las. Bedankt dat je dat recht hebt gezet en excuses voor de verwarring.

[gold_dust]

gekkie schreef op dinsdag 17 juli 2018 @ 09:53:
Oh bij mij ook wel hoor, het wat scherper neer zetten is een niet ongebruikelijk stijlfiguur wat ook goed werkt als je wat discussie er over los wilt krijgen (zoals je hier ook nog ziet tig jaar na dato )

Dat bijna 20 jaar nadat hij z'n mening zat te verkondigen dat nog steeds als waarheid wordt gezien is wel knap inderdaad. Dat moet ik hem nageven.

[Sandor_Clegane]

gold_dust schreef op dinsdag 17 juli 2018 @ 16:27:
[...]

Dat bijna 20 jaar nadat hij z'n mening zat te verkondigen dat nog steeds als waarheid wordt gezien is wel knap inderdaad. Dat moet ik hem nageven.

Lijkt een beetje op het 640k Bill Gates geneuzel, momentum enzo.

[armageddon_2k1]

Volgens mij is er ook wel een verschil met:
- herschrijven want de codebase is ruk en je voegt niks nieuws toe
- herschrijven met het doel meteen functionaliteit toe te voegen die anders niet kon

Dat laatste heeft meer validiteit, want anders blijf je met je ponskaarten zitten.

[kenneth]

Over ponskaarten gesproken. Ik hoor net dat mijn vrouw soms dna-sequenties moet uitdraaien en dat de pagina's wel eens door elkaar raken. Zit je daar met honderden vellen ATCG ATCG ATCG

[ThomasG]

kenneth schreef op dinsdag 17 juli 2018 @ 18:17:
Over ponskaarten gesproken. Ik hoor net dat mijn vrouw soms dna-sequenties moet uitdraaien en dat de pagina's wel eens door elkaar raken. Zit je daar met honderden vellen ATCG ATCG ATCG

Wat is het nut van het uitprinten daar eigelijk van?

[kenneth]

ThomasG schreef op dinsdag 17 juli 2018 @ 18:28:
[...]
Wat is het nut van het uitprinten daar eigelijk van?

Ik was zo flabbergasted dat ik geen verdere vragen durfde te stellen. Ook iets met paginanummers ...

[gekkie]

Hmm de Lidl is beter met groente en fruit dan met SAP geloof ik.
In het kader van van scratch beginnen en fijn geld verbranden in een megaproject:
https://www.heise.de/news...wt_mc=rss.ho.beitrag.atom
Hadden ze nou GoT (of Joel) maar gelezen

[ Voor 7% gewijzigd door gekkie op 17-07-2018 19:13 ]

[Mugwump]

ThomasG schreef op dinsdag 17 juli 2018 @ 18:28:
[...]
Wat is het nut van het uitprinten daar eigelijk van?

Misschien leveren ze die weer uit aan oogartsen.

[Sandor_Clegane]

gekkie schreef op dinsdag 17 juli 2018 @ 19:13:
Hmm de Lidl is beter met groente en fruit dan met SAP geloof ik.
In het kader van van scratch beginnen en fijn geld verbranden in een megaproject:
https://www.heise.de/news...wt_mc=rss.ho.beitrag.atom
Hadden ze nou GoT (of Joel) maar gelezen

Leuk als er volgende keer gezegd wordt dat alleen de overheid ICT projecten verneukt.

Het is ook overal hetzelfde lijkt, IT blijft moeilijk.

[Mugwump]

Sandor_Clegane schreef op dinsdag 17 juli 2018 @ 20:07:
[...]


Leuk als er volgende keer gezegd wordt dat alleen de overheid ICT projecten verneukt.

Het is ook overal hetzelfde lijkt, IT blijft moeilijk.

Volgens mij zegt ook niemand dat zo zwart-wit. Het "falen" van IT projecten is een bekend fenomeen dat zich echt niet enkel tot de overheid beperkt. Ik deed een tijdje terug poging #4 van een project bij een commerciële partij. Die is uiteindelijk wel live gegaan, maar adoptie vanuit de business is nihil en dat gold voor meer projecten daar.
Ook in het bedrijfsleven zijn er vele projecten die simpelweg echt falen en nog veel meer die lang niet opleveren wat er wordt verwacht, wanneer dat wordt verwacht en tegen de prijs waarvoor dat werd verwacht.

[Sandor_Clegane]

Mugwump schreef op dinsdag 17 juli 2018 @ 20:21:
[...]


Volgens mij zegt ook niemand dat zo zwart-wit. Het "falen" van IT projecten is een bekend fenomeen dat zich echt niet enkel tot de overheid beperkt. Ik deed een tijdje terug poging #4 van een project bij een commerciële partij. Die is uiteindelijk wel live gegaan, maar adoptie vanuit de business is nihil en dat gold voor meer projecten daar.
Ook in het bedrijfsleven zijn er vele projecten die simpelweg echt falen en nog veel meer die lang niet opleveren wat er wordt verwacht, wanneer dat wordt verwacht en tegen de prijs waarvoor dat werd verwacht.

Denk dat je wat vaker in de comments op de frontpage moet neuzen. Is redelijk zwart wit vaak. Maar ik snap je punt.

Doet me denken aan een achtbaan, boom en een schommel.

[gekkie]

Bij de overheid zal het vooral wat lastiger zijn om alle vuile was binnen te houden. Dan krijg je uiteindelijk van die 99% zwart gelakte WOB rapportjes. Maar in zich zelf geeft dat ook al wel weer aan dat dan 99% is om je voor dood te schamen, anders kon het wel openbaar worden .

[Mugwump]

Sandor_Clegane schreef op dinsdag 17 juli 2018 @ 20:40:
[...]


Denk dat je wat vaker in de comments op de frontpage moet neuzen. Is redelijk zwart wit vaak. Maar ik snap je punt.

Doet me denken aan een achtbaan, boom en een schommel.

Ach, zeiken op ambtenaren lijkt af en toe wel volkssport nummer één, maar wat IT betreft moet je ook niet vergeten dat het een gigantische organisatie is met enorm complexe processen die bovendien ook nog wel regelmatig op de kop mogen omdat die processen weer onderhevig zijn aan democratische processen.

Natuurlijk spelen er zaken als gebrekkige kennis van IT in de eigen organisatie en afhankelijkheid van externe adviseurs die niet zelden zelf wat strijdige belangen hebben, maar zelfs dat zie je ook in het bedrijfsleven. Veel detacheerders azen er net zo goed op om veel mensen binnen te loodsen bij partijen die zelf niet al te veel expertise in huis hebben.

[Sandor_Clegane]

Internet en nuance......

[ZaZ]

Wat staat er op de grafsteen van een ambtenaar?
Hier rust
hij verder

[Hydra]

Mugwump schreef op dinsdag 17 juli 2018 @ 22:15:
Ach, zeiken op ambtenaren lijkt af en toe wel volkssport nummer één, maar wat IT betreft moet je ook niet vergeten dat het een gigantische organisatie is met enorm complexe processen die bovendien ook nog wel regelmatig op de kop mogen omdat die processen weer onderhevig zijn aan democratische processen.

Ik heb zelf 'grote' projecten genoeg gedaan, zowel binnen de overheid (IND Indigo project om er maar eentje te noemen die bekend is van TV ) als daarbuiten, en het is 100% een management kwestie. Goeie software engineers willen uberhaupt niet voor dat soort managers werken die nog helemaal in het oude "programmeurs zijn fabrieksarbeiders" denken zitten. Die ambtenaren kunnen het uberhaupt niet hebben dat zo'n 'onderdaan' een stuk meer verdient dan zijzelf, laat staan dat zo'n ambtenaar initiatief en passie beloont.

Bij de overheid is al een hele tijd geleden een Dead Sea Effect gecreerd waarbij de enige mensen die er willen blijven werken zelf die cultuur in stand houden. Als er dan een keer een goeie software engineer binnengehaald wordt, wordt 'ie in no time gillend gek. Het is te positief om het een 'zesjescultuur' te noemen; een 5.5 is ook ruim voldoende.

Zo lang 'managers' in de ambtenarij geen enkel benul hebben van engineering culture zal het mis blijven gaan. Het salaris is slechts een van de problemen; als je niet snapt hoe je software bouwt moet je er ook gewoon niet aan beginnen. Zonde van ons geld.

[Sandor_Clegane]

Het lijkt wel alsof het ver-managen van alles een doodsteek is voor heel veel werkzaamheden. Probleem is alleen dat Nederland echt een managers cultuur is.

[ThomasG]

Sandor_Clegane schreef op donderdag 19 juli 2018 @ 10:29:
Het lijkt wel alsof het ver-managen van alles een doodsteek is voor heel veel werkzaamheden. Probleem is alleen dat Nederland echt een managers cultuur is.

Het probleem daarvan is dat de managers vaak ook degene zijn die het voor het zeggen hebben, en die zullen uit zichzelf nooit zichzelf of andere managers wegsturen. Managers houden de managers-cultuur ,aldanniet onbewust, in stand,

[armageddon_2k1]

Sandor_Clegane schreef op donderdag 19 juli 2018 @ 10:29:
Het lijkt wel alsof het ver-managen van alles een doodsteek is voor heel veel werkzaamheden. Probleem is alleen dat Nederland echt een managers cultuur is.

ThomasG schreef op donderdag 19 juli 2018 @ 10:42:
[...]
Het probleem daarvan is dat de managers vaak ook degene zijn die het voor het zeggen hebben, en die zullen uit zichzelf nooit zichzelf of andere managers wegsturen. Managers houden de managers-cultuur ,aldanniet onbewust, in stand,

Ach ja, de knee-jerk reactie om alles weer op de managers te gooien. Is lekker makkelijk ook, want het zal nooit eens aan anderen liggen. Alle anderen doen natuurlijk het werk helemaal perfect. (Ja, enigsinds gechargeerd).

Waar haal je vandaan dat Nederland een managers-cultuur is? T.o.v. welke andere landen? Welke branches? Allemaal?

We zijn een vrij productief en mondig volkje die niet echt van de traditionele hierarchie in veel bedrijven houden. Mijn ervaring (lekker wetenschappelijk ja) is dat we vrij plat georganiseerd zijn regelmatig, helemaal na ervaringen met Amerikaanse, Duitse, Chinese en Indonesische bedrijven in mijn afgelopen werk. Wat ik veel mis zie gaan is dat er gewoon kut gecommuniceerd wordt en de know-how niet op orde is en een soort warsheid van processen en sturing waardoor zeker stugge engineers hun kont tegen de krib gooien en het hele proces vertragen met hun stugheid en de manager overal de schuld van geven .

Ja, er zijn echt wel slechte managers. Ja, je kan dingen kapot managen. Maar dat verhaal dat managers alles kapot maken was in 1998 al oud aan het worden.

Misschien kan het er ook mee te maken hebben dat er maar weinig technici zijn die en goed requirements kunnen schrijven, en ze kunnen implementeren, en goed kunnen communiceren danwel escaleren. Voor zichzelf kunnen ze het al bijna niet. Heck, ik ken genoeg duurbetaalde programmeurs die zichzelf senior-architecten noemen die geen unit-tests van tevoren kunnen definieren. Wat de fuck ga je dan maken als je niet eens weet waartegen je het verifieert?

Of, misschien kan het er ook mee te maken hebben dat we door dat aanbestedingssysteem altijd plannen en budgetten krijgen die zwaar ondergebudgeteerd zijn, met te korte planningen, gebaseerd op eisen en wensen van mensen die geen eisen en wensen op kunnen stellen.

[ Voor 34% gewijzigd door armageddon_2k1 op 19-07-2018 11:59 ]

[ThomasG]

armageddon_2k1 schreef op donderdag 19 juli 2018 @ 11:52:
[...]


[...]


Ach ja, de knee-jerk reactie om alles weer op de managers te gooien. Is lekker makkelijk ook, want het zal nooit eens aan anderen liggen. Alle anderen doen natuurlijk het werk helemaal perfect. (Ja, enigsinds gechargeerd).

Waar haal je vandaan dat Nederland een managers-cultuur is? T.o.v. welke andere landen? Welke branches? Allemaal?

We zijn een vrij productief en mondig volkje die niet echt van de traditionele hierarchie in veel bedrijven houden. Mijn ervaring (lekker wetenschappelijk ja) is dat we vrij plat georganiseerd zijn regelmatig, helemaal na ervaringen met Amerikaanse, Duitse, Chinese en Indonesische bedrijven in mijn afgelopen werk. Wat ik veel mis zie gaan is dat er gewoon kut gecommuniceerd wordt en de know-how niet op orde is en een soort warsheid van processen en sturing waardoor zeker stugge engineers hun kont tegen de krib gooien en het hele proces vertragen met hun stugheid en de manager overal de schuld van geven .

Ja, er zijn echt wel slechte managers. Ja, je kan dingen kapot managen. Maar dat verhaal dat managers alles kapot maken was in 1998 al oud aan het worden.

Het ligt in veel gevallen ook aan het management, en soms zelfs hogerop. Er zijn zat bedrijven en overheidsinstanties waar van boven wordt bepaald welke software er nodig, en de mensen die er mee moeten werken daar niets over te zeggen hebben. Dat heb ik zelf een aantal keer meegemaakt. Documenten van honderden pagina's vol met requirements, en miljoenen euro's later is er software waar niemand iets aan heeft. Dat is natuurlijk niet alleen de schuld van het management maar ook de software bouwer die niet aan de bel trekt, maar bij veel bedrijven en instellingen heerst een verkeerde cultuur qua software.

[ Voor 5% gewijzigd door ThomasG op 19-07-2018 12:05 ]

[Sandor_Clegane]

Heel simpel, wil je goed verdienen moet je manager worden in Nederland. Al het andere telt niet bij veel bedrijven, zit je aan de top van je functie, wordt je manager want dan kan je wel hogerop komen.

Door de bank genomen heb je hier geen functies voor uitmuntende technici als Senior Fellow oid.

Het verhaal van de brugwachter is hier tot kunst verheven lijkt het wel, kijk maar in de zorg. De mensen die het werk doen zijn ondergeschikt aan de grillen van diegene die de aansturing doet terwijl deze vaak geen subject matter expert is. Niets zo irritant als een manager die vroeger hetzelfde werk heeft gedaan maar door zijn nieuwe functie niet meer zijn kennis op orde heeft maar wel denkt te kunnen zeggen wat de juiste manier is om iets te doen.

Nu heb ik de schurft aan amerikaanse bedrijfsvoering maar daar is het wel doorgedrongen dat de manager de obstakels voor zijn uitvoerend personeel weghaalt en niet als expert fungeert, daar zijn de mensen voor namelijk.

Edit: Dit hangt een beetje samen met het idee dat om goed te kunnen managen moeten we "grip" hebben op de zaken en deze dus ook meten. Dan komt er een bos aan KPI's de hoek om zeilen en als deze dan binnen de perken blijven "dan doen we het goed" en "hebben we grip op zaken".

Ik wil niet zeggen dat je niks moet meten maar vaak krijg je dan van die dingen als: wat we doen doen we goed, terwijl niemand zich af vraagt of je wel de goede dingen doet.

Dan krijg je van die situaties dat de helpdesk het qua KPIs prima doet want de calls worden binnen de tijd opgelost, maar het bedrijf belt gewoon niet meer omdat ze toch niet geholpen worden. Of de afdeling heeft een externe partij genomen want daar kun je nog wel redelijk zaken mee doen. ( Shadow IT )

Ook gechargeerd

[ Voor 27% gewijzigd door Sandor_Clegane op 19-07-2018 12:50 ]

[Mugwump]

Hydra schreef op donderdag 19 juli 2018 @ 09:57:
[...]


Ik heb zelf 'grote' projecten genoeg gedaan, zowel binnen de overheid (IND Indigo project om er maar eentje te noemen die bekend is van TV ) als daarbuiten, en het is 100% een management kwestie. Goeie software engineers willen uberhaupt niet voor dat soort managers werken die nog helemaal in het oude "programmeurs zijn fabrieksarbeiders" denken zitten. Die ambtenaren kunnen het uberhaupt niet hebben dat zo'n 'onderdaan' een stuk meer verdient dan zijzelf, laat staan dat zo'n ambtenaar initiatief en passie beloont.

Bij de overheid is al een hele tijd geleden een Dead Sea Effect gecreerd waarbij de enige mensen die er willen blijven werken zelf die cultuur in stand houden. Als er dan een keer een goeie software engineer binnengehaald wordt, wordt 'ie in no time gillend gek. Het is te positief om het een 'zesjescultuur' te noemen; een 5.5 is ook ruim voldoende.

Zo lang 'managers' in de ambtenarij geen enkel benul hebben van engineering culture zal het mis blijven gaan. Het salaris is slechts een van de problemen; als je niet snapt hoe je software bouwt moet je er ook gewoon niet aan beginnen. Zonde van ons geld.

Aan de andere kant is het ook wel weer 'des professionals' om te wijzen naar de managersklasse.
Naar mijn bescheiden mening kent de wereld van de professionals ook heel veel middelmaat die een belangrijke oorzaak is voor het falen van veel IT klussen. Schaarste doet een markt lang niet altijd goed.
Het voordeel van 'de markt' is dat specifieke partijen klein kunnen beginnen met een groepje gelijkgestemd talent en daarbij kritisch kunnen zijn op wie ze wel of niet aannemen. Zeker bij de grote corporates zitten ook veel teams vol met 'dood hout'.

[Olaf van der Spek]

Mugwump schreef op donderdag 19 juli 2018 @ 12:52:
[...]


Aan de andere kant is het ook wel weer 'des professionals' om te wijzen naar de managersklasse.
Naar mijn bescheiden mening kent de wereld van de professionals ook heel veel middelmaat die een belangrijke oorzaak is voor het falen van veel IT klussen. Schaarste doet een markt lang niet altijd goed.
Het voordeel van 'de markt' is dat specifieke partijen klein kunnen beginnen met een groepje gelijkgestemd talent en daarbij kritisch kunnen zijn op wie ze wel of niet aannemen. Zeker bij de grote corporates zitten ook veel teams vol met 'dood hout'.

Is het niet aan management om dit vast te stellen en actie te ondernemen?

[Sandor_Clegane]

Olaf van der Spek schreef op donderdag 19 juli 2018 @ 13:04:
[...]

Is het niet aan management om dit vast te stellen en actie te ondernemen?

Dat wilde ik ook opmerken.

[Mugwump]

Olaf van der Spek schreef op donderdag 19 juli 2018 @ 13:04:
[...]

Is het niet aan management om dit vast te stellen en actie te ondernemen?

Dan ga je er vanuit dat dat niet gebeurt. Als jij een trainer voor een voetbalelftal zet met een selectie van 25 hele matige spelers, dan kan hij zelf nog zoveel voetbalkennis en ervaring hebben, als er gewoon geen budget is om andere spelers aan te trekken bijvoorbeeld dan houdt het op.
En als heel veel van die spelers zichzelf dan ook nog eens heel goed vinden, een hele sterke mening hebben en ga zo maar door, dan is het lastig om daar wat mee te doen.

[Olaf van der Spek]

Mugwump schreef op donderdag 19 juli 2018 @ 14:24:
als er gewoon geen budget is om andere spelers aan te trekken bijvoorbeeld dan houdt het op.

Budget is toch ook de verantwoordelijkheid van management (hoger op)?

[Hydra]

Mugwump schreef op donderdag 19 juli 2018 @ 12:52:
Aan de andere kant is het ook wel weer 'des professionals' om te wijzen naar de managersklasse.
Naar mijn bescheiden mening kent de wereld van de professionals ook heel veel middelmaat die een belangrijke oorzaak is voor het falen van veel IT klussen. Schaarste doet een markt lang niet altijd goed.
Het voordeel van 'de markt' is dat specifieke partijen klein kunnen beginnen met een groepje gelijkgestemd talent en daarbij kritisch kunnen zijn op wie ze wel of niet aannemen. Zeker bij de grote corporates zitten ook veel teams vol met 'dood hout'.

Helemaal mee eens. Maar ook dat is een managementprobleem. Je kunt moeilijk van de andere developers verwachten dat ze gaan klagen dat Jantje de hele dag geen fuck uitvoert en Pietje een netto negatieve bijdrage aan het project levert. dat is voor die developers vaak echt een eindstation; je collega's voor de bus duwen is niet erg collegiaal.

Mugwump schreef op donderdag 19 juli 2018 @ 14:24:
Dan ga je er vanuit dat dat niet gebeurt. Als jij een trainer voor een voetbalelftal zet met een selectie van 25 hele matige spelers, dan kan hij zelf nog zoveel voetbalkennis en ervaring hebben, als er gewoon geen budget is om andere spelers aan te trekken bijvoorbeeld dan houdt het op.
En als heel veel van die spelers zichzelf dan ook nog eens heel goed vinden, een hele sterke mening hebben en ga zo maar door, dan is het lastig om daar wat mee te doen.

Ik heb in m'n vorige project nog een teamgenoot van me eruit gewerkt, samen met 2 andere developers. Dat heeft echt enorm veel tijd en energie gekost en daarbij ben ik genoeg van een 'eikel' om daar energie in te willen steken. Die andere twee devs hadden dat nooit uit zichzelf gedaan.

Onze 'manager' had er ook weinig zin in en toonde eigenlijk geen eigen initiatief. Zelfs toen het besluit genomen was, moest ik hem er nog een paar keer aan herinneren dat we afgesproken hadden dat Jantje per direct zou stoppen (Jantje was ZZPer gelukkig). Als het een interne medewerker was geweest, was het me waarschijnlijk nooit gelukt.

Wat betreft het budget; als een manager zo denkt is dat enorm kortzichtig. Als iemand zo slecht is dat andere mensen er pissig van worden dan kan het uitstellen van het ontslag van die persoon er toe leiden dat juist de mensen die je wil houden weggaan.

[ Voor 5% gewijzigd door Hydra op 19-07-2018 15:06 ]

[Mugwump]

Hydra schreef op donderdag 19 juli 2018 @ 15:05:
Ik heb in m'n vorige project nog een teamgenoot van me eruit gewerkt, samen met 2 andere developers. Dat heeft echt enorm veel tijd en energie gekost en daarbij ben ik genoeg van een 'eikel' om daar energie in te willen steken. Die andere twee devs hadden dat nooit uit zichzelf gedaan.

Onze 'manager' had er ook weinig zin in en toonde eigenlijk geen eigen initiatief. Zelfs toen het besluit genomen was, moest ik hem er nog een paar keer aan herinneren dat we afgesproken hadden dat Jantje per direct zou stoppen (Jantje was ZZPer gelukkig). Als het een interne medewerker was geweest, was het me waarschijnlijk nooit gelukt.

In mijn huidige project hebben we als externen ook een andere externe uit het team laten gooien omdat hij een negatieve bijdrage leverde en zich daarbij ook nog eens volkomen sfeerverziekend gedroeg. Vooral dat laatste helpt wel om iemand eruit te krijgen. Het eerste is veel lastiger hard te maken bij de klant.
Een andere externe vertrekt uit zichzelf en was op zich een best prettige collega, maar droeg eerlijk gezegd wel erg weinig bij.
Dan hebben we nog een interne die ook flinke investering vergt van de externe seniors, maar dat is dan ook een bewuste keuze van het bedrijf zelf.

Wat betreft het budget; als een manager zo denkt is dat enorm kortzichtig. Als iemand zo slecht is dat andere mensen er pissig van worden dan kan het uitstellen van het ontslag van die persoon er toe leiden dat juist de mensen die je wil houden weggaan.

Dat is wat anders. Ik doel meer op het feit dat je a) niet zomaar van mensen afkomt en daardoor b) niet altijd geld of mogelijkheid hebt om prima gekwalificeerde mensen aan te trekken.

[Hydra]

Mugwump schreef op donderdag 19 juli 2018 @ 15:47:
Dat is wat anders. Ik doel meer op het feit dat je a) niet zomaar van mensen afkomt en daardoor b) niet altijd geld of mogelijkheid hebt om prima gekwalificeerde mensen aan te trekken.

Daar ben ik het mee eens hoor. Alleen zijn dat van die "ja maar" redenaties die IMHO niet afdoen aan wat ik zei dat het meestal een managementprobleem is. Als er geen budget is om iemand te wieberen en software engineers vertrekken omdat ze het zat zijn, is dat altijd nog het probleem van het management. Zij hebben de sleutelrol en dienen hierin initiatief te nemen. Helaas zie ik erg veel managers een compleet passieve houding aannemen als het op engineering culture aankomt. Die managers zijn in mijn optiek mensen die veelal hun salaries niet waar kunnen maken.

[armageddon_2k1]

Hydra schreef op donderdag 19 juli 2018 @ 17:18:
[...]
Helaas zie ik erg veel managers mensen een compleet passieve houding aannemen als het op engineering culture aankomt. Die managers Dat zijn in mijn optiek mensen die veelal hun salaries niet waar kunnen maken.

FTFY

De 80/20 regel gaat ook bij de werknemers veelal op, en dan schaar ik managers ook onder werknemers (want dat zijn ze in essentie, tenzij ze directeur/eigenaar zijn).

Wat ik hiermee zeg is: 80% van het werk wordt door 20% van de mensen gedaan en dat geldt voor zowel de operationele (engineers) als voor de bestuurlijke laag (managers denkt de lading niet echt).

Wat nog erger is is dat er maar weinig mensen besluiten durven te nemen. Dat zie ik overal en ik vind het ook niet altijd even makkelijk. Maar bij de bestuurlijke laag zijn de effecten veel groter en langduriger. En dat raakt dan wel een beetje de kern van het vak bestuurder. Je moet de besluiten durven maken die anderen niet kunnen, mogen of durven.

Helaas zijn veel managers/bestuurders veredelde Excel-managers die hier en daar een traininkje Six Sigma en Lean hebben gehad en denken dat een afdeling met kennis-professionals hetzelfde werkt als een productie-lijn van een Toyota.

Die 20% van de groep die wel goed is doet al het moeilijke werk. Ik weet niet of de mensen hier wel eens ervaring gehad hebben met goede managers? Nou, dat is me toch wel fijn hoor

Een van mijn managers was zo'n goeie:
- bijna onzichtbaar tijdens het operationele werk
- uitermate bereikbaar voor advies en als je iets moest escalleren
- ging er in de eerste instantie altijd vanuit dat jij gelijk had, maar stelde wel kritische vragen
- heeft er geen moeite mee eerlijk en direct te zijn in z'n kritiek en mensen te stimuleren ergens anders heen te gaan
- is altijd van de 2e kansen

Helaas is ie uiteindelijk weg gegaan

Maar daarom heb ik dus een hekel aan dat geklaag over managers in het algemeen. Er zitten namelijk toppers bij. Maar het nadeel van die 80% aan middelmaat is dat hun apathie zo merkbaar is.

[gold_dust]

Het is vooral van belang om vooraf eerlijk te zijn wat wederzijds de verwachtingen zijn en dingen niet mooier voor te spiegelen dat ze zijn.

Wat ik in mijn ervaring zie is dat enerzijds veel bedrijven ontzettend slechte code bases hebben zonder documentatie, onderliggend design, of tests, dat teams vol met scheikundigen/natuurkundigen/wiskundigen/vul maar in zitten die maar wat aanprutsen, dat bedrijven eigenlijk vooral op zoek zijn naar ontwikkelaars om hun legacy zooi op te lappen terwijl de enige reële optie een volledige rewrite is, dat dit allemaal vooraf niet wordt gecommuniceerd en dat er geen bereidheid is om goed te betalen.

Het is ook niet zo gek dat je als nieuwe ontwikkelaar ergens niet in het team past als je ook maar een beetje bovengemiddeld goed bent. Anderzijds lopen er ontzettend veel slechte ontwikkelaars rond die er werkelijk helemaal niks van bakken. In mijn 10+ jaar ervaring heb ik nog nooit een collega gehad die ik zelf zou willen aannemen en dat is eigenlijk best wel schokkend. Ik kan me ook voorstellen dat bedrijven klagen dat ze niemand kunnen vinden.

[armageddon_2k1]

gold_dust schreef op vrijdag 20 juli 2018 @ 11:49:
Wat ik in mijn ervaring zie is dat enerzijds veel bedrijven ontzettend slechte code bases hebben zonder documentatie, onderliggend design, of tests, dat teams vol met scheikundigen/natuurkundigen/wiskundigen/vul maar in zitten die maar wat aanprutsen, dat bedrijven eigenlijk vooral op zoek zijn naar ontwikkelaars om hun legacy zooi op te lappen terwijl de enige reële optie een volledige rewrite is, dat dit allemaal vooraf niet wordt gecommuniceerd en dat er geen bereidheid is om goed te betalen.

Nogmaals, ik lurk in dit topic omdat ik het interessant vind. Ik zit namelijk in de productontwikkeling, mechanisch. Daar zie je precies hetzelfde, namelijk producten/platforms/systemen met enorme legacy door een hele lading aan redenen. Sommige logisch, sommige niet. Wat mij betreft moet je maar omarmen dat dat de realiteit is.

Wat betreft de scheikundigen/natuurkundigen/wiskundigen. Ik heb ook wel met programmeurs samengewerkt en ik sla juist stijl achterover van het lage niveau aan wiskunde kennis of uberhaubt algoritme kennis. De big O notatie niet begrijpen of zelfs niet kennen, of niet een simpel set aan vergelijkingen kunnen oplossen. Nogal wiedes dat als je niet weet welke datastructuren wel en niet efficient zijn in welke situatie dat je dan een brakke applicatie krijgt.

Zoals altijd ligt de sweet-spot ergens in het midden en moet je teams hebben die meerdere facetten kunnen bedienen en niet te beroerd zijn naar elkaar te luisteren.

Anderzijds lopen er ontzettend veel slechte ontwikkelaars rond die er werkelijk helemaal niks van bakken. In mijn 10+ jaar ervaring heb ik nog nooit een collega gehad die ik zelf zou willen aannemen en dat is eigenlijk best wel schokkend. Ik kan me ook voorstellen dat bedrijven klagen dat ze niemand kunnen vinden.

Dat vind ik ook schokkend. Eventjes plagen: Zouden zij dat ook vinden? Is het misschien in de technische sector, of uberhaubt in elke sector, dat men ook aan chronische zelfoverschatting doet. Net als dat 90% van de mensen denkt dat ze bij de 10% beste automobilisten horen? (Disclaimer: niet naar jou gericht, maar in het algemeen).

[alienfruit]

Iemand hier enig idee of je met een REST API nieuwe virtuele machines en SAP HANA databases kan aanmaken in de SAP cloud? E.g. bijv voor elke klant zijn eigen VM+HANA?

[downtime]

armageddon_2k1 schreef op vrijdag 20 juli 2018 @ 11:56:
[...]

Dat vind ik ook schokkend. Eventjes plagen: Zouden zij dat ook vinden? Is het misschien in de technische sector, of uberhaubt in elke sector, dat men ook aan chronische zelfoverschatting doet. Net als dat 90% van de mensen denkt dat ze bij de 10% beste automobilisten horen?

Jij zegt wat ik dacht. Elke keer als mensen afgeven op hun "incompetente" collega's/voorgangers/klanten/managers zet ik daar onwillekeurig vraagtekens bij.

Het voelt als de automobilist die op de radio hoort dat er een spookrijder gesignaleerd is en bij zichzelf denkt, "wat? een spookrijder? het zijn er honderden!"
Weten incompetente mensen van zichzelf dat ze incompetent zijn? Of misschien denken ze wel dat zij de enige competente persoon in hun omgeving zijn en dat alle kritiek komt van mensen die er gewoon niks van snappen.

[Mugwump]

downtime schreef op vrijdag 20 juli 2018 @ 14:44:
[...]

Jij zegt wat ik dacht. Elke keer als mensen afgeven op hun "incompetente" collega's/voorgangers/klanten/managers zet ik daar onwillekeurig vraagtekens bij.

Het voelt als de automobilist die op de radio hoort dat er een spookrijder gesignaleerd is en bij zichzelf denkt, "wat? een spookrijder? het zijn er honderden!"
Weten incompetente mensen van zichzelf dat ze incompetent zijn? Of misschien denken ze wel dat zij de enige competente persoon in hun omgeving zijn en dat alle kritiek komt van mensen die er gewoon niks van snappen.

Als je 'nooit met iemand hebt gewerkt die je zou aannemen' dan heb je inderdaad niet zo'n heel realistisch zelfbeeld of werk je bij bedrijven waar je nooit een fatsoenlijke collega naast je hebt. Vraag me gezien de opstelling van g_d in het recruiter-shitpraktijken-topic wel af of hij het überhaupt leuk vindt om met andere mensen samen te werken.

Ik heb toch met genoeg mensen gewerkt die ik morgen nog zou aannemen. Ook genoeg die zeker op pure programmeervaardigheden of software architectuur beter / verder zijn dan ik. Het is wel zo dat er ook enorm veel middelmaat in de sector rondloopt en dat ik vaak genoeg in teams heb gezeten waar het mantra '20% van de mensen doet 80% van het werk' inderdaad betekende dat ik 3/4 man moest meezeulen en uiteindelijk alsnog het gros van het werk zelf deed.

[Vincentio]

alienfruit schreef op vrijdag 20 juli 2018 @ 13:55:
Iemand hier enig idee of je met een REST API nieuwe virtuele machines en SAP HANA databases kan aanmaken in de SAP cloud? E.g. bijv voor elke klant zijn eigen VM+HANA?

Standaard kan dit In ieder geval niet voor de HANA databases en ik vermoed voor de VM's ook niet.

De HANA databases moet je gewoon eerst een licentie contract met SAP voor afsluiten en dan moet er iemand bij SAP op een knopje drukken om de HANA database aan te maken en aan de juiste SAP Cloud Platform account te koppelen. (En dat kan soms heel moeilijk zijn )

Misschien dat nu met het consumption (tokens) based model er wat mogelijk is, maar dat licentie model ben ik nog niet echt ingedoken.

Heb je geen HANA nodig, dan zou je natuurlijk op Cloud Foundry wel wat kunnen met andere databases.

Andere oplossing is natuurlijk Multi Tenancy en daar zijn ook verschillende modellen voor te verzinnen.
Bijvoorbeeld:
https://blogs.sap.com/201...-sap-hana-cloud-platform/
Echt nette Multi Tenant Database Containers zijn volgens mij nog niet (en worden waarschijnlijk ook niet) beschikbaar op NEO.
Vermoedelijk wel op HANA op de CF stack, maar daar heb ik nog niet echt ervaring mee.

[alienfruit]

Nou ja, SAP is de sponsor dus qua licentie zal het wel goed zitten
Ik wist niet dat bij HANA nog steeds een SAPer op een knop moet drukken dat is wel stom

Ja, we hebben eigenlijk geen HANA nodig maar ja zie hierboven 🤷♂
Volgens mij gebruiken we inderdaad NEO

[Vincentio]

alienfruit schreef op vrijdag 20 juli 2018 @ 15:39:
Nou ja, SAP is de sponsor dus qua licentie zal het wel goed zitten
Ik wist niet dat bij HANA nog steeds een SAPer op een knop moet drukken dat is wel stom

Ja, we hebben eigenlijk geen HANA nodig maar ja zie hierboven 🤷♂
Volgens mij gebruiken we inderdaad NEO

Tsja aan de andere kant is het natuurlijk wel handig / fijn, dat je eerst een licentie moet afsluiten ervoor en niet gewoon wat dingen aan kan zetten en daarna de rekening krijgt.

Zeker in het geval van HANA, als je daar dan even de 1TB variant aan kan zetten en later de rekening krijgt, wordt men denk ik niet vrolijk. Al zou dat dan weer wel moeten kunnen met het Consumption model.

https://cloudplatform.sap.com/pricing.html

[alienfruit]

Alsof je ooit vrolijk wordt van de SAP prijzen

[Mugwump]

alienfruit schreef op vrijdag 20 juli 2018 @ 15:55:
Alsof je ooit vrolijk wordt van de SAP prijzen

Fixed.

[dcm360]

Welke prijzen? Er staat bij mij alleen een generiek verhaaltje over SAP op die pagina

Want de cookie-consent tool wordt ingeladen vanaf een domein dat in mijn tracking blocker zit (denk ik). Niet echt handig ontworpen

[Matis]

Pff, mijn Polar RS300X heeft de geest gegeven. Na het wisselen van de batterij het klepje niet goed gesloten. Hierdoor is bij de eerste zwempartij het horloge volledig nat komen te staan

Na alles gedroogd te hebben, leek hij het weer te doen. Echter werkt de ontvanger voor de analoge hartslag niet meer. Na een aantal secondes van registratie stopt hij er mee. Dit doet hij bij mijn beide hartslagmeters

Nu op zoek naar een vervanger, maar alle sporthorloges moeten tegenswoordig voorzien zijn van Bluetooth en GPS, en kosten minimaal 100+ euro.

Ik ben op zoek naar een eenvoudige Polar horloge met alleen analoge ontvangst voor mijn hartslagmeters (beide van Polar). De RS300X kostte 3,5 jaar geleden maar 74 euro en daar zat nog een hartslagmeter+band bij ook

[XWB]

Matis schreef op zaterdag 21 juli 2018 @ 10:03:
Pff, mijn Polar RS300X heeft de geest gegeven. Na het wisselen van de batterij het klepje niet goed gesloten. Hierdoor is bij de eerste zwempartij het horloge volledig nat komen te staan

Ik ben op zoek naar een eenvoudige Polar horloge met alleen analoge ontvangst voor mijn hartslagmeters (beide van Polar). De RS300X kostte 3,5 jaar geleden maar 74 euro en daar zat nog een hartslagmeter+band bij ook

Ik heb nog een Polar RS100 liggen. Stuur maar een DM als je interesse hebt.

[Matis]

XWB schreef op zaterdag 21 juli 2018 @ 23:07:
Ik heb nog een Polar RS100 liggen. Stuur maar een DM als je interesse hebt.

Bedankt voor het aanbod. Ik heb wat nieuws besteld. Misschien bevalt het ook wel, al die nieuwe snufjes.

[Antrax]

Nooit geweten wat een SAP is. Waarom niet een eigen custom implementatie?

[ThomasG]

Antrax schreef op zondag 22 juli 2018 @ 15:28:
Nooit geweten wat een SAP is. Waarom niet een eigen custom implementatie?

SAP is net als Oracle, proprietary rommel met een groot marktandeel (hoe is mij een raadsel). En zodra bedrijven er eenmaal aan vast zitten, komen ze er bijna nooit meer van af. Gewoon van wegblijven

[Antrax]

ThomasG schreef op zondag 22 juli 2018 @ 17:00:
[...]
SAP is net als Oracle, proprietary rommel met een groot marktandeel (hoe is mij een raadsel). En zodra bedrijven er eenmaal aan vast zitten, komen ze er bijna nooit meer van af. Gewoon van wegblijven

Klinkt een beetje als Dynamics Nav, bij meerdere firma's geweest voor migraties maar die bedrijven komen daar echt niet vanaf tenzij ze diepe portemonneetjes hebben. Proprietary spul blijft vreemd om te gebruiken.

[Ryur]

Antrax schreef op zondag 22 juli 2018 @ 17:38:
[...]

Klinkt een beetje als Dynamics Nav, bij meerdere firma's geweest voor migraties maar die bedrijven komen daar echt niet vanaf tenzij ze diepe portemonneetjes hebben. Proprietary spul blijft vreemd om te gebruiken.

SAP is de allergrootste, is ook echt geschikt voor enorme bedrijven (Fortune 500 bedrijven).

Ik werk zelf in Dynamics NAV en die is voor de iets "kleinere" bedrijven geschikt.
Je hebt ook nog Dynamics AX en die is wel voor de grotere bedrijven (net zoals SAP) geschikt.

Maar ik snap niet waarom je er vanaf zou willen als het goed werkt?

[Antrax]

Ryur schreef op maandag 23 juli 2018 @ 08:09:
[...]

SAP is de allergrootste, is ook echt geschikt voor enorme bedrijven (Fortune 500 bedrijven).

Ik werk zelf in Dynamics NAV en die is voor de iets "kleinere" bedrijven geschikt.
Je hebt ook nog Dynamics AX en die is wel voor de grotere bedrijven (net zoals SAP) geschikt.

Maar ik snap niet waarom je er vanaf zou willen als het goed werkt?

Ik kom vaak in omgevingen waar er te weinig kennis is en daardoor wordt het vaak fout gebruikt. Na een fix en mensen naar een cursus sturen, gaat het op zich redelijk.

[DevWouter]

Antrax schreef op maandag 23 juli 2018 @ 09:56:
[...]

Ik kom vaak in omgevingen waar er te weinig kennis is en daardoor wordt het vaak fout gebruikt. Na een fix en mensen naar een cursus sturen, gaat het op zich redelijk.

Dat is sowieso een dingetje dat mij vaak opvalt. Vaak klagen mensen terwijl het probleem een gebrek van kennis is dat niet aangepakt wordt. En dat geldt voor zo'n beetje alles en niet alleen SAP of Dynamics. Nu ben ik het type Dee Dee ("Ooh! What does this button do?"), maar als ik dan toch een keer op zoek moet naar kennis dan zoek ik vaak alleen het antwoord voor mijn ene probleem ipv dat ik het systeem probeert te leren.

[ThomasG]

DevWouter schreef op dinsdag 24 juli 2018 @ 08:58:
[...]


Dat is sowieso een dingetje dat mij vaak opvalt. Vaak klagen mensen terwijl het probleem een gebrek van kennis is dat niet aangepakt wordt. En dat geldt voor zo'n beetje alles en niet alleen SAP of Dynamics. Nu ben ik het type Dee Dee ("Ooh! What does this button do?"), maar als ik dan toch een keer op zoek moet naar kennis dan zoek ik vaak alleen het antwoord voor mijn ene probleem ipv dat ik het systeem probeert te leren.

Het is natuurlijk niet zo zwart-wit. Soms is het probleem inderdaad een gebrek aan kennis. Maar op het moment dat het systeem niet zonder handleiding te begrijpen is, deugt het systeem niet. Veel systemen hebben een UX van het stenentijdperk en zijn gewoon niet te begrijpen. Een UI hoort intuïtief te zijn, dat je in een oogopslag kunt zien wat er van je verwacht wordt en wat je er mee kunt doen. Natuurlijk zijn er altijd uitzonderingen, want als ervaren gebruiker van een applicatie wil je bepaalde acties zus en zo doen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 3% gewijzigd door ThomasG op 24-07-2018 10:00 ]

[Vincentio]

ThomasG schreef op dinsdag 24 juli 2018 @ 09:58:
[...]
Natuurlijk zijn er altijd uitzonderingen, want als ervaren gebruiker van een applicatie wil je bepaalde acties zus en zo doen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Crazy D]

Ryur schreef op maandag 23 juli 2018 @ 08:09:
Maar ik snap niet waarom je er vanaf zou willen als het goed werkt?

Kosten? Wat vaak kort door de bocht is, als je in het meest positieve geval een terugverdientijd hebt van een paar jaar....

[DevWouter]

ThomasG schreef op dinsdag 24 juli 2018 @ 09:58:
[...]
Het is natuurlijk niet zo zwart-wit. Soms is het probleem inderdaad een gebrek aan kennis. Maar op het moment dat het systeem niet zonder handleiding te begrijpen is, deugt het systeem niet. Veel systemen hebben een UX van het stenentijdperk en zijn gewoon niet te begrijpen. Een UI hoort intuïtief te zijn, dat je in een oogopslag kunt zien wat er van je verwacht wordt en wat je er mee kunt doen. Natuurlijk zijn er altijd uitzonderingen, want als ervaren gebruiker van een applicatie wil je bepaalde acties zus en zo doen.


***members only***

<trol-lol-lol>
UX = User Experience, de ervaring die de gebruiker ervaart.
UI = User Interface, hoe de gebruiker interactie heeft.

Een "systeem" dat "UX van het stenentijdperk heeft" bestaat niet tenzij het systeem een gebruiker is
</trol-la-la>

Om inhoudelijk te reageren, wat er beschreven werdt was de afwezigheid om te willen leren. Als we dat doortrekken naar software (om aan te sluiten op jouw verhaal) dan zou ik het beschrijven als iemand die klaagt dat hij continue zijn gebruikersnaam en wachtwoord moet invullen en nooit klikt op "Bewaar mijn inloggegevens".
Of iemand die er wel op klikt, maar altijd zijn browser in incognito mode draait en dan niet wilt begrijpen dat het juist de bedoeling is dat het niks onthoudt

[ThomasG]

DevWouter schreef op dinsdag 24 juli 2018 @ 11:13:
[...]

Om inhoudelijk te reageren, wat er beschreven werdt was de afwezigheid om te willen leren. Als we dat doortrekken naar software (om aan te sluiten op jouw verhaal) dan zou ik het beschrijven als iemand die klaagt dat hij continue zijn gebruikersnaam en wachtwoord moet invullen en nooit klikt op "Bewaar mijn inloggegevens".
Of iemand die er wel op klikt, maar altijd zijn browser in incognito mode draait en dan niet wilt begrijpen dat het juist de bedoeling is dat het niks onthoudt

Nee, dat is niet hetzelfde. Waar het om gaat is verkeerd ontworpen software, of in ieder geval een verkeerde UI. In mijn voorbeeld: als je voor 30 studenten een cijfer wilt invoeren, dan moet je voor iedere student van voor af aan beginnen. Je kunt niet voor alle 30 studenten tegelijk het cijfer invoeren in een lijst. Je moet het jaar selecteren, vak selecteren, onderdeel selecteren, student selecteren, cijfer invoeren, bevestigen, e.d. en vervolgens weer helemaal opnieuw beginnen. Een cijfer batch invoeren kan niet. En dat is niet zoiets simpels als als ze bewaren hun inloggevens niet. Nee, het kan niet op een andere manier want dat staat de software simpelweg niet toe. Dan kun je mensen wel op een cursus sturen, maar dan blijft het probleem slech ontworpen software.

[Mugwump]

DevWouter schreef op dinsdag 24 juli 2018 @ 11:13:
Om inhoudelijk te reageren, wat er beschreven werdt was de afwezigheid om te willen leren. Als we dat doortrekken naar software (om aan te sluiten op jouw verhaal) dan zou ik het beschrijven als iemand die klaagt dat hij continue zijn gebruikersnaam en wachtwoord moet invullen en nooit klikt op "Bewaar mijn inloggegevens".
Of iemand die er wel op klikt, maar altijd zijn browser in incognito mode draait en dan niet wilt begrijpen dat het juist de bedoeling is dat het niks onthoudt

Er zijn ook gewoon klanten die voor sommige accounts een ééndagsrotatie instellen voor passwords.
Dan ook nog een superomslachtige inlogprocedure waarbij je twee andere accounts nodig hebt en je bent elke ochtend weer 10 minuten verder voordat je daadwerkelijk ingelogd bent in tooling die je nodig hebt.

[Motrax]

Ryur schreef op maandag 23 juli 2018 @ 08:09:
[...]

SAP is de allergrootste, is ook echt geschikt voor enorme bedrijven (Fortune 500 bedrijven).

Ik werk zelf in Dynamics NAV en die is voor de iets "kleinere" bedrijven geschikt.
Je hebt ook nog Dynamics AX en die is wel voor de grotere bedrijven (net zoals SAP) geschikt.

Maar ik snap niet waarom je er vanaf zou willen als het goed werkt?

Elk ERP systeem is lastig. Kennis van je processen EN je systeem is en blijft lastig. Maar het is zooo makkelijk om het systeem de schuld te geven, want dat werkt niet mee. Dat een ERP systeem je bedrijfsbrede processen volgt en dat 1 medewerker maar 1 stukje overziet en dan dus het ERP systeem lastig vind... tsja.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Crazy D]

ThomasG schreef op dinsdag 24 juli 2018 @ 11:21:
[...]
Nee, dat is niet hetzelfde. Waar het om gaat is verkeerd ontworpen software, of in ieder geval een verkeerde UI. In mijn voorbeeld: als je voor 30 studenten een cijfer wilt invoeren, dan moet je voor iedere student van voor af aan beginnen. Je kunt niet voor alle 30 studenten tegelijk het cijfer invoeren in een lijst. Je moet het jaar selecteren, vak selecteren, onderdeel selecteren, student selecteren, cijfer invoeren, bevestigen, e.d. en vervolgens weer helemaal opnieuw beginnen. Een cijfer batch invoeren kan niet. En dat is niet zoiets simpels als als ze bewaren hun inloggevens niet. Nee, het kan niet op een andere manier want dat staat de software simpelweg niet toe. Dan kun je mensen wel op een cursus sturen, maar dan blijft het probleem slech ontworpen software.

Klopt, maar dan kun je nog steeds wel via training dit duidelijk maken. Maar het blijft klote software

Motrax schreef op dinsdag 24 juli 2018 @ 12:36:
Elk ERP systeem is lastig. Kennis van je processen EN je systeem is en blijft lastig. Maar het is zooo makkelijk om het systeem de schuld te geven, want dat werkt niet mee. Dat een ERP systeem je bedrijfsbrede processen volgt en dat 1 medewerker maar 1 stukje overziet en dan dus het ERP systeem lastig vind... tsja.

Klopt, heb regelmatig meegemaakt dat mensen op de vloer het voor hun stukje van het werk vooral klote vonden maar ze niet zagen dat het voor het bedrijf als geheel een flinke stap vooruit was. Dat is trouwens wel met goede demo''s te vertellen. Is het soms nog steeds vervelend in specifieke gevallen (soms moet iemand inderdaad wat omslachtiger z'n dingen doen) maar je moet duidelijk kunnen maken wat de winst voor het bedrijf als geheel is. En dat lukt gelukkig vaak genoeg wel.

[DevWouter]

ThomasG schreef op dinsdag 24 juli 2018 @ 11:21:
[...]
Nee, dat is niet hetzelfde. Waar het om gaat is verkeerd ontworpen software, of in ieder geval een verkeerde UI. In mijn voorbeeld: als je voor 30 studenten een cijfer wilt invoeren, dan moet je voor iedere student van voor af aan beginnen. Je kunt niet voor alle 30 studenten tegelijk het cijfer invoeren in een lijst. Je moet het jaar selecteren, vak selecteren, onderdeel selecteren, student selecteren, cijfer invoeren, bevestigen, e.d. en vervolgens weer helemaal opnieuw beginnen. Een cijfer batch invoeren kan niet. En dat is niet zoiets simpels als als ze bewaren hun inloggevens niet. Nee, het kan niet op een andere manier want dat staat de software simpelweg niet toe. Dan kun je mensen wel op een cursus sturen, maar dan blijft het probleem slech ontworpen software.

Zoals ik al in mijn vorige reactie aangaf heb ik het over de afwezigheid om te leren en de problemen die daaruit ontstaan.

[mcDavid]

Crazy D schreef op dinsdag 24 juli 2018 @ 12:58:
[...]

Klopt, heb regelmatig meegemaakt dat mensen op de vloer het voor hun stukje van het werk vooral klote vonden maar ze niet zagen dat het voor het bedrijf als geheel een flinke stap vooruit was. Dat is trouwens wel met goede demo''s te vertellen. Is het soms nog steeds vervelend in specifieke gevallen (soms moet iemand inderdaad wat omslachtiger z'n dingen doen) maar je moet duidelijk kunnen maken wat de winst voor het bedrijf als geheel is. En dat lukt gelukkig vaak genoeg wel.

Dit is ZO belangrijk en wordt zó vaak vergeten... niet alleen op ict gebied. Als je begrijpt waarom je iets moet doen en wat de voordelen ervan zijn, is het veel makkelijker te accepteren dan wanneer het alleen maar moet omdat de baas/manager/whatever zegt dat het moet.

[Sandor_Clegane]

De C in ICT is voor veel bedrijven erg lastig. Zelfs als ze pretenderen een ICT bedrijf te zijn.,

[Mugwump]

Motrax schreef op dinsdag 24 juli 2018 @ 12:36:
[...]
Elk ERP systeem is lastig. Kennis van je processen EN je systeem is en blijft lastig. Maar het is zooo makkelijk om het systeem de schuld te geven, want dat werkt niet mee. Dat een ERP systeem je bedrijfsbrede processen volgt en dat 1 medewerker maar 1 stukje overziet en dan dus het ERP systeem lastig vind... tsja.


***members only***

Mensen onderschatten denk ik sowieso hoe complex bedrijfsprocessen an sich zijn. Software die bedrijfsprocessen ondersteund of automatiseerd is daarmee net zo complex.

[farlane]

Mugwump schreef op dinsdag 24 juli 2018 @ 18:32:
[...]
Software die bedrijfsprocessen ondersteund of automatiseerd is daarmee net zo complex.

Even afgezien van het feit dat ik het ook met de inhoud niet echt eens ben

[ Voor 17% gewijzigd door farlane op 24-07-2018 22:58 ]

[Mugwump]

farlane schreef op dinsdag 24 juli 2018 @ 22:57:
[...]




Even afgezien van het feit dat ik het ook met de inhoud niet echt eens ben

Het zal de hitte zijn, maar misschien leuk om met de inhoudelijke reactie te komen dan.

[DevWouter]

Mugwump schreef op dinsdag 24 juli 2018 @ 23:40:
[...]


Het zal de hitte zijn, maar misschien leuk om met de inhoudelijke reactie te komen dan.

<trol-lol-lol>Nou, als de temperatuur stijgt dan wordt het warm... </trol-la-la>

Jouw stelling: "Software die (complexe) bedrijfsprocessen ondersteund of automatiseer is daarmee net zo complex."

Laten we doen alsof dat een zwart-wit stelling is. (is niet zo, maar polarisatie is geweldig voor discours )
Ook kies ik ervoor om "ondersteund" te negeren gezien het open voor interpretatie is wat wel/niet kwalificeert als ondersteunend. (Want cherry-picking in forums is geweldig voor discours )

Als we een software programma definiëren als een functie/proces waarbij dezelfde input altijd leidt tot hetzelfde resultaat dan wordt de complexiteit van de software bij definitie bepaalt door zijn functie/functie en door de de input (ik beschouw dit een axioma).

Dat betekent ook dat je de complexiteit van software kan zowel positief als negatief kan veranderen door de functie van de software te veranderen of door de input minder te veranderen.

Tot dusver onderbouwt mijn argument jouw stelling. Immers als het "handmatige" proces complex is dan verandert dat niet als het een "automatisch" proces wordt. Alleen de uitvoerder verandert van mens naar computer.

Mijn tegenargument:
De bovenstaande argument gaat alleen op als het om exact hetzelfde proces gaat dat op exact dezelfde manier wordt uitgevoerd. Echter dat is vaak niet het geval. Voorbeeld: Sommige controles in processen zijn alleen nuttig wanneer het een "handmatig" handeling betreft, terwijl sommige controles juist alleen nuttig zijn bij "automatische" handelingen.
Hiermee verandert het gedrag van proces en dus ook de complexiteit.

Op het moment dat we accepteren dat gedeeltes van het proces anders mogen zijn dan kunnen we ook andere procesoptimalisaties uitvoeren. We kunnen dus de complexiteit van het proces reduceren (als dat het doel van de optimalisatie is). Vaak heeft dit wel gevolgen voor andere zaken zoals performance.

Tot dus ver ging ik uit van een groot monolithisch proces waarbij dit soort optimalisaties vaak in de marges zitten. De winst is dan vrij beperkt en zoals ik ook eerder aangaf kan de complexiteit ook groter worden.
Zeker bij een monolithisch proces is dat lastig.

Echter ga je het proces beschouwen als een modular proces dan wordt vergroting op schaal een belangrijk factor in de discussie.
Bij handmatige processen kan je het aantal "actors" (lees: mensen op de werkvloer) veel lastiger schalen. Je bent dus gebaat bij efficiënte mensen die makkelijker complexere functies kunnen uitvoeren. Terwijl bij automatische inefficiënte processen veel makkelijker kan schalen.

Nu ken ik zelf maar weinig 100% geautomatiseerde processen en is er eerder sprake van een hybride proces waarbij 99% automatisch is en 1% handmatig. Die 1% is dan vaak bedoeld voor edgecases/uitval.

Een keuze voor een hybride proces is dan vaak omdat de software (voor de "automatische proces") niet dezelfde mate van complexiteit aankan als de mens (bedoeld voor het "handmatig proces"). Bij een hybride proces is de ook complexiteit ongelijk verdeeld tussen "automatisch" en "handmatig".

* DevWouter gaat alvast koffie zetten en koekjes halen
Moet ik nog popcorn meenemen?

[Mugwump]

DevWouter schreef op woensdag 25 juli 2018 @ 10:05:
Mijn tegenargument:
De bovenstaande argument gaat alleen op als het om exact hetzelfde proces gaat dat op exact dezelfde manier wordt uitgevoerd. Echter dat is vaak niet het geval. Voorbeeld: Sommige controles in processen zijn alleen nuttig wanneer het een "handmatig" handeling betreft, terwijl sommige controles juist alleen nuttig zijn bij "automatische" handelingen.
Hiermee verandert het gedrag van proces en dus ook de complexiteit.

Op het moment dat we accepteren dat gedeeltes van het proces anders mogen zijn dan kunnen we ook andere procesoptimalisaties uitvoeren. We kunnen dus de complexiteit van het proces reduceren (als dat het doel van de optimalisatie is). Vaak heeft dit wel gevolgen voor andere zaken zoals performance.

Tot dus ver ging ik uit van een groot monolithisch proces waarbij dit soort optimalisaties vaak in de marges zitten. De winst is dan vrij beperkt en zoals ik ook eerder aangaf kan de complexiteit ook groter worden.
Zeker bij een monolithisch proces is dat lastig.

Echter ga je het proces beschouwen als een modular proces dan wordt vergroting op schaal een belangrijk factor in de discussie.
Bij handmatige processen kan je het aantal "actors" (lees: mensen op de werkvloer) veel lastiger schalen. Je bent dus gebaat bij efficiënte mensen die makkelijker complexere functies kunnen uitvoeren. Terwijl bij automatische inefficiënte processen veel makkelijker kan schalen.

Nu ken ik zelf maar weinig 100% geautomatiseerde processen en is er eerder sprake van een hybride proces waarbij 99% automatisch is en 1% handmatig. Die 1% is dan vaak bedoeld voor edgecases/uitval.

Een keuze voor een hybride proces is dan vaak omdat de software (voor de "automatische proces") niet dezelfde mate van complexiteit aankan als de mens (bedoeld voor het "handmatig proces"). Bij een hybride proces is de ook complexiteit ongelijk verdeeld tussen "automatisch" en "handmatig".

Het argument gaat alleen mank bij 'procesoptimalisatie'. Ik stel dat software minstens zo complex is als het proces dat het ondersteunt (of zelfs automatiseert). Als je dat optimaliseert is de software nog steeds net zo complex als het proces, alleen is het proces simpeler geworden.

Procesoptimalisatie staat los van software, al kan software er wel bij helpen. Het tegengestelde zie je ook juist vaak. Men heeft proces dat redelijk organisch is geëvolueerd en wil een nieuw stuk software inzetten om bestaande software te vervangen. Vaak is nieuw stukje software X een bestaand pakket met mogelijkheid tot extra maatwerk. In plaats van dat men het proces eens kritisch onder de loep neemt en de mogelijkheden en beperkingen van het nieuwe softwarepakket als factor meeneemt probeert men gewoon het oude proces klakkeloos over te nemen met veelal falende (of in ieder geval budgetoverschrijdende) projecten tot gevolg.

[farlane]

Mugwump schreef op dinsdag 24 juli 2018 @ 23:40:
[...]
Het zal de hitte zijn, maar misschien leuk om met de inhoudelijke reactie te komen dan.

Als het proces complex is, zal i.h.a. met automatisering getracht worden het (in ieder geval voor de gebruiker) makkelijker te maken om zo fouten (kosten) te voorkomen.

Bedoelde je eigenlijk dat de hitte de oorzaak van je spellingsfouten was? Of de oorzaak van het ontbreken van mijn inhoudelijke reactie?

[Tjolk]

Mozeskriebel...

In het lokale dorpsblaadje stond laatst een oproep voor een webmaster (content management). Is allemaal vrijwilligerswerk en omdat het blaadje toch echt wel een functie heeft in het dorp dacht ik: laat ik eens reageren. Inmiddels wat van het broddelwerk gezien, volgens mij hebben ze meer aan iemand die daadwerkelijk de techniek eens onderhanden neemt. Maar ja; de site wordt al jaren gratis onderhouden en gehost door een lokale "webdesigner" zoals hij zichzelf noemt. Ook vrijwilligerswerk, dus dat compleet affakkelen zal een hoop diplomatie van me vragen (niet mijn sterkste punt).

Maar echt; gewoon alles zonder inlog beschikbaar (vandaar dat ik het hier maar even niet noem), file uploads via een flash ding, HTML output die aan alle kanten rammelt, etc. Kom ik eens op de site van die kerel die dus zijn diensten verhuurt, klik ik daar zonder credentials in te vullen op de login button, zie ik hele rare output. View source, na een paar HTML regels komt ik dit tegen:

PHP:

<pho
if($_GET['factuur']){
    $factuur = $_GET['factuur']
}
include("conn.php");
 require "Mollie/API/Autoloader.php";

if isset($GET["new"]){
$SqlAmount="select * from 'factuur' where id="$id" OR fatuur="$factuur"";
    $ophalen = mysql_query($SqlAmount) or die(mysql_error()); 
while($record = mysql_fetch_object($ophalen)){
    $amount=record->amount;
}
}
?>

Het is dat er werkelijk alleen maar openbare informatie op die site staat en nergens met persoonsgegevens o.i.d. omgegaan wordt, dat geeft me nog wat tijd om dit op een nette manier aan te vliegen. Maar ik denk dat ik naast content managen toch ook maar even de techniek naar me toe ga trekken, man man man...

[XWB]

Tjolk schreef op woensdag 25 juli 2018 @ 12:05:

PHP:

$factuur = $_GET['factuur'];

$SqlAmount="select * from 'factuur' where id="$id" OR fatuur="$factuur"";

[Tjolk]

Yup...

En gezien dat zelfs op zijn bedrijfsmatige website (waar hij zijn kwaliteiten aanprijst) zonder enig hackwerk naar voren komt, vrees ik voor de rest.

[DevWouter]

Mugwump schreef op woensdag 25 juli 2018 @ 11:43:
Het argument gaat alleen mank bij 'procesoptimalisatie'. Ik stel dat software minstens zo complex is als het proces dat het ondersteunt (of zelfs automatiseert). Als je dat optimaliseert is de software nog steeds net zo complex als het proces, alleen is het proces simpeler geworden.

Dat... is eigenlijk heel goed punt. Het enige wat nog blijft staan is dat bepaalde complexiteit optimalisaties exclusief zijn. Echter ik geef daar ook dat dit in het voordeel van zowel handmatig als automatische processen kan vallen. Plus kan ik geen voorbeelden bedenken behalve die marginaal verschil maken.

farlane schreef op woensdag 25 juli 2018 @ 11:43:
Als het proces complex is, zal i.h.a. met automatisering getracht worden het (in ieder geval voor de gebruiker) makkelijker te maken om zo fouten (kosten) te voorkomen.

Ah, dat argument wilde ik ook maken tot dat ik bedacht me dat het een argument van kosten is en niet complexiteit. Een andere argument dat ik wilde aandragen was snelheid, maar dat voelde aan alsof ik de doelposten ging verplaatsen (ook leuk voor discourse).

Tot mijn spijt moet ik erkennen dat ik tot nu toe geen gaten in zijn exacte stelling kan vinden.

[downtime]

Tjolk schreef op woensdag 25 juli 2018 @ 12:05:

Het is dat er werkelijk alleen maar openbare informatie op die site staat en nergens met persoonsgegevens o.i.d. omgegaan wordt, dat geeft me nog wat tijd om dit op een nette manier aan te vliegen. Maar ik denk dat ik naast content managen toch ook maar even de techniek naar me toe ga trekken, man man man...

Tip van een ervaringsdeskundige: Doe alsof jij je maar 6 maanden met die site wil bemoeien en het daarna over moet dragen aan iemand met veel minder technische kennis. Maak er een standaard Wordpress/Joomla/Drupal/whatever site van die iedereen kan onderhouden. Anders zit je er levenslang aan vast omdat je nooit iemand zult vinden die het beheer kan/wil overnemen.

[Tjolk]

Ja, daar zal het uiteindelijk wel op neerkomen. Maar eerst mijn diplomatie skills opzoeken op zolder...

[DevWouter]

downtime schreef op woensdag 25 juli 2018 @ 12:32:
[...]

Tip van een ervaringsdeskundige: Doe alsof jij je maar 6 maanden met die site wil bemoeien en het daarna over moet dragen aan iemand met veel minder technische kennis. Maak er een standaard Wordpress/Joomla/Drupal/whatever site van die iedereen kan onderhouden. Anders zit je er levenslang aan vast omdat je nooit iemand zult vinden die het beheer kan/wil overnemen.

Als ex-penningmeester vind ik dat nogal een vreemde houding om 6 maanden "druk te wezen". Het is lastig om aan vrijwilligers te komen en het liefst wil je zo lang mogelijk houden. Een vrijwilliger doet vrijwilligerswerk vrijwillig. Dat betekent ook dat je op elk moment het werk kan neerleggen. Zij kunnen jou ook nergens toe verplichten.

@Tjolk, als je met modder gaat gooien worden jouw handen ook vies

Uit je verhaal begrijp ik dat de webmaster nog steeds betrokken is en jij alleen verantwoordelijk bent voor de content. Speel de kaarten dan ook zo (en wees neutraal/feitelijk als je kritiek hebt). Stuur eerst een screenshot van het probleem waarbij je de handeling uitlegt die je gedaan hebt. Letterlijk: "Hoi WebMaster, toen ik XXX deed kreeg ik het onderstaande".

Afhankelijk van hoe er gereageerd wordt weet jij of de zaak verbeterd wordt, of je dit moet escaleren naar het bestuur (omdat er een conflict ontstaat) of dat je beter kan vertrekken.

Nogmaals, jij bent vrijwilliger en je kan niet verplicht worden om dingen te doen waar je geen zin in hebt. Ook ben jij niet verantwoordelijk voor het oplossen van problemen die anderen maken (dat mag de webmaster doen). En als er een conflict ontstaat praat dan met het bestuur.

Vrijwilligerswerk is best leuk (en goed voor je sociale leven), maar het kan ook zwaar en veeleisend zijn (zeker als bestuurder).

[downtime]

DevWouter schreef op woensdag 25 juli 2018 @ 13:22:
[...]

Als ex-penningmeester vind ik dat nogal een vreemde houding om 6 maanden "druk te wezen". Het is lastig om aan vrijwilligers te komen en het liefst wil je zo lang mogelijk houden. Een vrijwilliger doet vrijwilligerswerk vrijwillig. Dat betekent ook dat je op elk moment het werk kan neerleggen. Zij kunnen jou ook nergens toe verplichten.

Ik denk dat je me verkeerd begrijpt. Ik probeer alleen aan continuïteit te denken. Het verloop van vrijwilligers is groot en dan wil je jezelf niet afhankelijk maken van die ene vrijwilliger die unieke skills heeft.
Als vereniging hebben we niks aan een IT'er die een mooie website neerzet die niet meer onderhouden kan worden als die IT'er het straks te druk heeft met andere zaken. Ik heb liever dat hij zijn kennis gebruikt om iets neer te zetten wat ook zonder hem kan blijven voortbestaan.

Juist omdat het lastig is om aan vrijwilligers te komen moet je rekening houden met het feit dat kennis die je vandaag in huis hebt morgen misschien weer vertrokken is.