De technische kant van agile ontwikkelen

[Yucon]

Korte intro: ik werk als een vliegende keep in een metaalbedrijf waar men ook een flinke IT tak heeft. Mijn roots liggen in software bouw. Dat was vroeger, geleidelijk verschoof m’n interesse en ben ik vooral bedrijfskundig bezig.

Tldr; ik ben benieuwd naar interessante inzichten. Softwarebouw gaat stroef, optimalisatie wordt gezocht in het proces en niet in de techniek terwijl daar volgens mij ook veel te winnen is.

Een aanzienlijk deel van de IT inspanning die we op dit moment hebben zit in interfaces en maatwerk. Meestal zijn dat losse applicaties die business logic van diverse API’s combineren. Sommige van die apps hebben ook nog een stevige reken- of datatransformatiecomponent. De stack is azure based met als streven ontkoppeling via een service bus en overwegend C# microservices.

Maar het loopt niet lekker. Uitlopende planningen, budgetoverschrijdingen en dergelijke. Als tegenbeweging zie je dat er ook her en der amateuroplossingen in elkaar geknutseld worden die niet altijd even doordacht in elkaar zitten. Denk daarbij aan veel te ingewikkelde rommelige SQL die voor business logic speelt waar niemand meer uit kan komen en dat soort dingen. Kortom het verhaal van de man met de hamer die alleen maar spijkers ziet.

Procesmatig wordt er al flink aan de weg getimmerd. Een tijdje geleden zijn we net zoals zo’n beetje overal met een losse interpretatie van agile aan de slag gegaan en dat lijkt wel aardig te werken. Waar het blijft wringen is dat de implementatietijd voor relatief simpele dingen te lang is.

Naar mijn mening bestaat de huidige situatie uit twee uitersten: of we bouwen een aan elkaar getapede golfplaten bouwsels (de SQL/PowerApps/access/weetikveel oplossingen) en anders bouwen we een stenen huis met marmer en eikenhout (c# microservice apps). Er zit niet zoiets als een houten schuurtje tussenin. Die mis ik, want met name bij interfaces en datatransformaties heb je gaandeweg veel voortschrijdend inzicht.. eigenlijk moet je dat eerst als een prototype kunnen testen om het design te laten rijpen. Als ik nu echter een redelijk rechttoe-rechtaan interface zou laten bouwen (klantorder aanmaken in systeem a zorgt automatisch voor een klantorder in systeem b) ben ik minimaal een week of meer kwijt. Dat is niet te verkopen en het is een drijvende kracht om die houtje-touwtje oplossingen veel te ver door te drijven. Wat weer z’n eigen problemen oplevert.

Bij een recent project heb ik het anders aangepakt. Ik heb met Python een paar scripts gemaakt die een brondatabase uitlezen, wat transformeerden, en webservices van het doelpakket aanriepen. Voordelen: snel klaar, wat moeilijkheidsgraad betreft betrekkelijk eenvoudig en de onderliggende SQL is veel overzichtelijker dan bij allemaal in elkaar geknoopte stored procedures. En wijzigingen zijn best door een beetje technisch aangelegde functionele gebruikers te doen zodat de logica goed kan rijpen. Deze oplossing is vanzelfsprekend niet zo bullet proof als een ‘echte’ interface en daarom moet goed bekeken worden of het hogere risico aansluit bij de mate waarin iets bedrijfskritisch is.

Zodra het te verantwoorden is dat er echt gebouwd wordt ligt er werkende code als referentie waardoor het ondubbelzinnig is hoe de nieuwe code moet gaan werken, dus ik hoop dat dat tzt de implementatiesnelheid ook ten goede komt. Nu ben ik er wel wat huiverig voor nog een aanvullende prutsoplossing te introduceren. Volgens mij zit dit wel op het goede evenwicht tussen simpel en degelijk, maar mocht iemand betere suggesties hebben sta ik daar zeker voor open.

Maar wat me vooral verbaast is dat ik hier redelijk alleen in lijk te staan. De meeste collega’s zitten volledig in een van de twee uitersten. En waar zoals gezegd wel aandacht is voor verbeteringen wat betreft proces zie ik zowel binnen ons bedrijf als online eigenlijk zo goed als geen aandacht voor het wat meer ‘agile’ maken van de techniek zelf.

Volgens mij is dit probleem voor ons toch totaal niet uniek, hoe gaat dat bij jullie?

[Falcon]

Als dit niet intern te bespreken valt en het daarna ook niet gezien word als een probleem, dan zou ik persoonlijk eerst eens goed overwegen of jij hier wel energie in moet gaan stoppen.

---

Even voor de duidelijkheid, jullie leveren een dienst om systemen met elkaar te integreren. Levert dit een product op die gehost word door de klant of door jullie zelf?

[Yucon]

Het is voor eigen gebruik. Ja, het is zeker de moeite waard aangezien dit een hele grote bottleneck is. Dat zien wel meer mensen. Het feit dat er realistisch gezien verbetering mogelijk is echter niet. Hoewel het niet mijn directe verantwoordelijkheid is valt het wel binnen m'n functie dit indien ik het nodig vind op te pakken.

Na het schrijven van de OP realiseerde ik me dat dat hamers/spijkers verhaal misschien ook wel niet alleen voor de knutselaars geldt. De echte devs hebben dat net zo goed.. alleen dan binnen hun eigen tooling.

[Falcon]

De uitdagingen die jij omschrijft, vraagt om een cultuursverandering en is niet met even wat technieken en tooling op te lossen.

Daarnaast vind ik het ongelooflijk dat een "prutsoplossing" uberhaupt langs een code review moment kan komen. Een pull-request voor merge naar de master/baas repo kan niet zomaar gecomplete worden, maar moet serieus lokaal getest zijn en tegen de requirements aangehouden worden maar ook tegen de architectuurafspraken/standaarden.

Volgens mij moeten jullie aan de linkerkant van jullie applicatieontwikkeling je gaan richten op verbeteringen (dit begint al bij het eerste gesprek met "business"/markt met te omschrijven wat willen, pre-refiments, refinements, spike-pbi opnemen voor meer analyse/uitzoek werkzaamheden en de acceptatie-criteria's.)

Termen als Definition Of Ready (DOR) en Definition Of Done. Scrum. DevOps, Product Risico Analyses en Quality Gateways binnen je CD/CI pipelines.

[Voor 14% gewijzigd door Falcon op 09-07-2020 18:45]

[Yucon]

Falcon schreef op donderdag 9 juli 2020 @ 18:43:
De uitdagingen die jij omschrijft, vraagt om een cultuursverandering en is niet met even wat technieken en tooling op te lossen.

Mee eens. Onderdeel daarvan is mensen, met name wat hoger in de boom, het besef geven dat er nog een weg is die gekozen kan worden. Ik hecht verder ook niet bijzonder aan Python, al lijkt het wel goed te voldoen. Tooling is in zoverre wel belangrijk dat ik sterk de indruk heb dat onze huidige tooling gewoon niet geschikt is om dit soort vraagstukken op een efficiente manier aan te pakken.

Daarnaast vind ik het ongelooflijk dat een "prutsoplossing" uberhaupt langs een code review moment kan komen. Een pull-request voor merge naar de master/baas repo kan niet zomaar gecomplete worden, maar moet serieus lokaal getest zijn en tegen de requirements aangehouden worden maar ook tegen de architectuurafspraken/standaarden.

Die prutsoplossingen komen daar niet eens langs omdat dat om shadow IT gaat. Dat is bij ons net even iets groter dan gangbaar omdat we historisch gezien geen IT bedrijf zijn.

Overigens betekent dat ook dat er voor dit deel niet zoiets als een 'pull request' of zelfs maar een 'repo' is.

Volgens mij moeten jullie aan de linkerkant van jullie applicatieontwikkeling je gaan richten op verbeteringen (dit begint al bij het eerste gesprek met "business"/markt met te omschrijven wat willen, pre-refiments, refinements, spike-pbi opnemen voor meer analyse/uitzoek werkzaamheden en de acceptatie-criteria's.)

Termen als Definition Of Ready (DOR) en Definition Of Done. Scrum. DevOps, Product Risico Analyses en Quality Gateways binnen je CD/CI pipelines.

Voor het formele deel zijn deze punten aardig goed op orde. Desondanks duurt het in uren gewoon relatief lang om dingen op te leveren. Zelfs als de specs 100% helder en juist zijn. Ik ga niet in de valkuil trappen om met verouderde dev kennis code reviews uit te gaan voeren, maar toch ben ik ook niet helemaal blind en ik heb sterk de indruk dat het microservice premium of iets dat daar op lijkt bij ons van toepassing is.

Wat betreft je eerste opmerking over de linkerkant twijfel ik. "De requirements moeten beter in kaart gebracht worden" lijkt een soort standaard reflex te zijn. Bij normale businesssoftware is dit ook zonder meer haalbaar. Bij integraties loop je er in mijn ervaring onvermijdelijk tegenaan dat je niet tot het detailniveau kunt gaan dat je nodig hebt, tenzij je echt extreem veel gedetailleerde scenarios uitschrijft. Je moet dan namelijk nog veel verder gaan dan alleen een unit test. Dat kost dan echter zo ongelofelijk veel tijd dat je meer tijd verliest bij het op papier testen dan dat je wint bij development. Over de hele keten gezien is dat ook niet verstandig.

Om die reden heeft het ook gewoon voordelen om technisch aangelegde functionele analisten quick&dirty code te laten schrijven. Kwaad kan het ook niet als het tenminste niet te ingewikkeld is, maar je moet wel vantevoren incalculeren dat je die code later gewoon weg zult moeten gooien. Volgens mij is dat in de data science ook geen ongebruikelijke aanpak en in zekere zin zijn de onzekerheden die je daar tegenkomt gewoon de overtreffende trap van integraties.

Ik maak me echt niet de illusie dat diezelfde code later door een echte developer een beetje bijgeschaafd kan worden en daarmee ineens van een goed niveau is.

edit: er zit wel een interessant aspect aan je post. Je focust heel sterk op het bouwen van "goede software", wat vanuit je QA achtergrond ook logisch is. Onze devs delen die mening en vaak zit daar de impliciete aanname achter dat dat op termijn goedkoper is. Maar wat nu als "op termijn" helemaal niet van toepassing is? Dan is het juist zaak om op een heel efficiente manier iets voor de korte termijn te bouwen. En dat staat juist weer haaks op het langetermijn kader.

[Voor 10% gewijzigd door Yucon op 09-07-2020 20:24]

[Falcon]

Wat is nu het probleem dan? Want ik kan deze reactie gaan weerleggen met je eigen startpost

In de startpost heb je het over slechte kwaliteit en projecten die teveel tijd kosten. Door korter te gaan itereren met minder grote blokken aan werk moet in combinatie van verre gang van automatisering te accelereren zijn en met een voorspelbaardere time-to-market en de afgesproken(!) kwaliteit.

Daar moeten de hoge heren toch ook het voordeel van inzien?

Om dit te kunnen doen vraagt ook om goed voorbereid werk. Dit kan bereikt worden door soms ook kleine blokken aan onderzoekswerk (afgebakend door tijd) op te nemen, maar pas aan het echte werk te beginnen wanneer dit volledig kan worden uitgevoerd tegenover de capaciteit die beschikbaar in de periode die voor de iteratie is vastgesteld.

Dat hele shadow IT gebeuren zou je wat mij betreft nog wel mogen uitleggen, en geen versiebeheer op code/oplossingen is vragen om problemen.

Dat jullie geen IT bedrijf van oorsprong zijn heeft jullie doen redden in de tijden dat jullie nog klein waren en het allemaal wat pragmatischer kon (aanname). Nu krijg je waarschijnlijk te maken met grotere bedrijven die gewend zijn aan kwaliteit en als dat niet gebeurt moet jullie organisatie nu ontzettend rennen met alle gevolgen van dien. Want er ligt waarschijnlijk een iets harder contract dan vroeger.

[Voor 58% gewijzigd door Falcon op 09-07-2020 20:38]

[Yucon]

Falcon schreef op donderdag 9 juli 2020 @ 20:25:

Dat jullie geen IT bedrijf van oorsprong zijn heeft jullie doen redden in de tijden dat jullie nog klein waren en het allemaal wat pragmatischer kon (aanname). Nu krijg je waarschijnlijk te maken met grotere bedrijven die gewend zijn aan kwaliteit en als dat niet gebeurt moet jullie organisatie nu ontzettend rennen met alle gevolgen van dien. Want er ligt waarschijnlijk een iets harder contract dan vroeger.

Het ligt iets anders dan dit. Onze software is voor intern gebruik, dus er is niets zoiets als grotere bedrijven/klanten. En ook geen contract. En we zijn overigens nog steeds geen IT bedrijf en dat blijft ook zo. Ik heb ook bij echte IT bedrijven gewerkt en dit maakt de situatie echt fundamenteel anders

Wat is nu het probleem dan? Want ik kan deze reactie gaan weerleggen met je eigen startpost

In de startpost heb je het over slechte kwaliteit en projecten die teveel tijd kosten. Door korter te gaan itereren met minder grote blokken aan werk moet in combinatie van verre gang van automatisering te accelereren zijn en met een voorspelbaardere time-to-market en de afgesproken(!) kwaliteit.

Daar moeten de hoge heren toch ook het voordeel van inzien?

Dat van die overschrijdingen stond er wat ongelukkig zie ik nu. Deels is dat nog perceptie vanuit het verleden toen er inderdaad wel nog vooruitgang op het gebied van planning te halen is. Dat is een aanjager voor gehobby omdat dat beeld wel nog blijft hangen.

De schattingen van formele softwarebouw kloppen tegenwoordig wel behoorlijk. Alleen zijn ze te hoog. En dat maakt alternatieven weer aantrekkelijk. Het aantal uur was op zich misschien nog net op het randje van acceptabel als je niet al vantevoren wist dat er door voortschrijdend inzicht en dus nieuwe nieuwe functionele eisen toch weer rework op zou komen.

Ik ben er vrij zeker van dat de hoge heren in kwestie niet onder de indruk van je argumenten zullen zijn. Door ervaringen uit het verleden heerst sterk het idee 'kwaliteit = duur' samen met 'we doen het eigenlijk nu al te goed'. In die zin neigt men er ondertussen naar om dan maar wat meer de hobbyaanpak te kiezen.

Wat bedoelde je trouwens met het uitroepteken achter 'afgesproken'? Ik twijfel een beetje, stel je nu voor om uit kostenoogpunt een lagere kwaliteit met de devs af te spreken en ze zo voor een simpelere architectuur te laten kiezen?

Om dit te kunnen doen vraagt ook om goed voorbereid werk. Dit kan bereikt worden door soms ook kleine blokken aan onderzoekswerk (afgebakend door tijd) op te nemen, maar pas aan het echte werk te beginnen wanneer dit volledig kan worden uitgevoerd tegenover de capaciteit die beschikbaar in de periode die voor de iteratie is vastgesteld.

De essentie is dat de flows binnenin de te integreren pakketten in de regel heel erg complex zijn. Om die reden valt de volledige analyse pas te maken als je een werkend algoritme hebt. Wat mij betreft in een excel macro _{maar dat koppelt weer zo onhandig, vandaar de suggestie voor python}, maar iig niet in een geschreven spec.

Dat hele shadow IT gebeuren zou je wat mij betreft nog wel mogen uitleggen, en geen versiebeheer op code/oplossingen is vragen om problemen.

Dat ontbreken van versiebeheer vind ik ook onbegrijpelijk. Die shadow IT zelf is zo vreemd nog niet. Als ik in ca 2-4 uur een integratie bouw die een echte dev op de nette manier 4 dagen kost denk ik dat ik wel een business case zie, vooral aangezien ik vervolgens kleine wijzigingen ook heel snel kan doorvoeren. De echte knutseloplossing zal in de praktijk trouwens ook niet veel minder dan 4 dagen zijn omdat dergelijke code per definitie lastig te onderhouden is. Even snel wat voortschrijdend inzicht verwerken is dan ineens ongemerkt flink tijdrovend. Dus die knutselvariant wil ik evengoed elimineren, maar helaas blijkt dat gebruikte aantal uren niet uit urenboekingen want dit wordt gewoon als interne kosten gezien. Op die manier is het lastig om dit duidelijk te maken.

Je lijkt ook principieel wat weerstand te hebben om v1 van een interface als wegwerpproduct te zien. Klopt dat?

[Skating_vince]

Falcon schreef op donderdag 9 juli 2020 @ 18:43:
De uitdagingen die jij omschrijft, vraagt om een cultuursverandering en is niet met even wat technieken en tooling op te lossen.

Daarnaast vind ik het ongelooflijk dat een "prutsoplossing" uberhaupt langs een code review moment kan komen. Een pull-request voor merge naar de master/baas repo kan niet zomaar gecomplete worden, maar moet serieus lokaal getest zijn en tegen de requirements aangehouden worden maar ook tegen de architectuurafspraken/standaarden.

Volgens mij moeten jullie aan de linkerkant van jullie applicatieontwikkeling je gaan richten op verbeteringen (dit begint al bij het eerste gesprek met "business"/markt met te omschrijven wat willen, pre-refiments, refinements, spike-pbi opnemen voor meer analyse/uitzoek werkzaamheden en de acceptatie-criteria's.)

Termen als Definition Of Ready (DOR) en Definition Of Done. Scrum. DevOps, Product Risico Analyses en Quality Gateways binnen je CD/CI pipelines.

Hier ben ik het mee eens. Wanneer in de organisatie de toegevoegde waarde van een goed proces voor stabiele en onderhoudbare software niet wordt gezien, gaat het je niet lukken om dit te veranderen. Mogelijk wanneer er een keer iets goed misgaat met een "golfplaten oplossing" en dit het bedrijf geld kost, dat er ruimte voor verbetering komt.

Een goede interface tussen systemen maken is inderdaad iets wat je meestal niet volledig van te voren kan doorzien, maar even goed nadenken over mogelijke wensen en consequenties is erg belangrijk. Daarnaast kost goede software, inclusief (unit)tests en peer review nu eenmaal meer tijd dan even iets in elkaar klikken wat lijkt te werken. Tot het in het weekend misgaat en je met een probleem zit. Of je uiteindelijk een heleboel "golfplaten oplossingen" in allerlei tooling hebt en niemand meer weet hoe het allemaal samenwerkt. Dan durft niemand meer iets aan te passen en blijf je met een hoop "technical debt" zitten.

[Craven]

Even een observaties / aanname uit de posts van hierboven.Correct me if I'm wrong.

Jij (en alleen jij dus) ziet een probleem met de kwaliteit van de software en de invloed die dat heeft op dev tijd. De ene helft van je collega's bouwt het houwtje touwtje. De andere helft bouwt een bunker. Als alleen jij dit probleem ziet kun je je hier een aantal zaken afvragen:

1. Zaken verbeteren waarvan alleen jij het probleem ziet binnen een bedrijf is zo goed als onmogelijk. Het is inherent aan personen om weerstand te bieden als ze het probleem niet zien/begrijpen (vrij logisch en menselijk). Dus zul je eerst het probleem aan licht moeten zien te brengen. Laat de zooi een keer klappen i.p.v brandjes(laten) blussen. Of maak een gedegen analyse wat er fout zit, wat er te verbeteren valt, hoeveel tijd dat gaat kosten en wat dat gaat opleveren
2. Weet je zeker dat er een probleem is? Het zal niet de 1e keer zijn dat iemand problemen ziet die er niet zijn (mogelijk geïnspireerd door enige frustratie, mogelijk historisch en vanwege andere redenen). Met name omdat ik begrijp dat je de enige bent
3. Je bent te volwassen (professioneel gezien) voor dit bedrijf. Het is een gevecht dat je niet gaat winnen en je gaat je hierop mogelijk kapot bijten. Met veel frustratie en mogelijk een burn out ten gevolge.

Ik ben ook nieuwsgierig, zie je een patroon in welke personen er het liefste houwtje touwtje bouwen en wie er een bunker bouwen? Is dat toevallig business vs dev?

En last but not least, wie is er verantwoordelijk voor de IT tak en meer specifiek de dev kant daarvan (ik neem dat je ook beheerders oid in dienst hebt). Of eigenlijk is een overzichtje van de structuur van de organisatie aan de IT kant wel handig.

De reden dat ik dat vraag is omdat je technische oplossingen aandraagt die in een proces gegoten moeten worden. Het is vrij normaal bij nieuw te ontwikkelen zaken dat je dat niet meteen in een taal als C++ (overdreven) doet maar dat je het eerst in elkaar krast als prototype (in python idd bvb). Maar als je dat soort werkwijzes niet in regels/ processen/ DOR / DOD whatever vastlegt dan heb je er niks aan. Nog los van het feit dat er iemand als een project manager, product manager of product owner een vorm van overzicht moet houden. Een techneut doet zonder toezicht over het algemeen toch wat hij het fijnste vind werken. Dat is voor iedere dev weer wat anders.

[Yucon]

Craven schreef op vrijdag 10 juli 2020 @ 08:47:
Even een observaties / aanname uit de posts van hierboven.Correct me if I'm wrong

Je zit met een aantal punten behoorlijk goed

Jij (en alleen jij dus) ziet een probleem met de kwaliteit van de software en de invloed die dat heeft op dev tijd. De ene helft van je collega's bouwt het houwtje touwtje. De andere helft bouwt een bunker. Als alleen jij dit probleem ziet kun je je hier een aantal zaken afvragen:

1. Zaken verbeteren waarvan alleen jij het probleem ziet binnen een bedrijf is zo goed als onmogelijk. Het is inherent aan personen om weerstand te bieden als ze het probleem niet zien/begrijpen (vrij logisch en menselijk). Dus zul je eerst het probleem aan licht moeten zien te brengen. Laat de zooi een keer klappen i.p.v brandjes(laten) blussen. Of maak een gedegen analyse wat er fout zit, wat er te verbeteren valt, hoeveel tijd dat gaat kosten en wat dat gaat opleveren
2. Weet je zeker dat er een probleem is? Het zal niet de 1e keer zijn dat iemand problemen ziet die er niet zijn (mogelijk geïnspireerd door enige frustratie, mogelijk historisch en vanwege andere redenen). Met name omdat ik begrijp dat je de enige bent
3. Je bent te volwassen (professioneel gezien) voor dit bedrijf. Het is een gevecht dat je niet gaat winnen en je gaat je hierop mogelijk kapot bijten. Met veel frustratie en mogelijk een burn out ten gevolge.

Zo'n beetje iedereen in het bedrijf ziet dat dit erg stroef loopt. Waar ik wel nogal alleen in sta is in de visie dat de oplossing wel eens in een middenweg zou kunnen liggen. Er zijn de laatste tijd wel wat individuele collega's die het met me eens zijn als ik het aankaart, maar binnen het management is nog een weg te gaan.

Ik ben volgens mij de enige die zowel bedrijfskundig als van IT een diepe inhoudelijke kennis heeft._{(twee losse studies)}

Ik ben ook nieuwsgierig, zie je een patroon in welke personen er het liefste houwtje touwtje bouwen en wie er een bunker bouwen? Is dat toevallig business vs dev?

En last but not least, wie is er verantwoordelijk voor de IT tak en meer specifiek de dev kant daarvan (ik neem dat je ook beheerders oid in dienst hebt). Of eigenlijk is een overzichtje van de structuur van de organisatie aan de IT kant wel handig.

Er zijn grofweg drie betrokken afdelingen: applicatiebeheer, softwareontwikkeling en data science. Hoewel er ook zeker politiek meespeelt durf ik wel te zeggen dat de betrokkenen handelen uit oprechte overtuiging van het eigen gelijk. Softwareontwikkeling bouwt degelijk. Deze afdeling is recent en heeft veel inhuur, en in de rest van het bedrijf bestaan vraagtekens of men na een woelige en heel erg dure startperiode wel op het juiste niveau gestabiliseerd is.

Data science bouwt houtje-touwtje en vat de opdracht 'help de business met slimme toepassingen' nogal breed op, dus apps worden daar ook onder geschoven. Hier wordt veel geknutseld. Het zwakke punt is dat men eigenlijk niet zo'n verstand van software bouw heeft en daarom maar blijft copy/pasten van een werkwijze die leek te werken. Men staat wel heel erg open voor het principe dat er een goede business case moet zijn en het zijn vanzelfsprekend heel slimme mensen, maar door het gebrek aan development achtergrond ziet men zowel scherpe randjes aan de gebruikte werkwijze als mogelijke alternatieven niet zo. Deze aanpak lijkt oppervlakkig prima te werken en is voor het hogere management bij discussies over dit onderwerp daarom al snel een aantrekkelijk alternatief voor formele softwarebouw.

Dan heb je nog applicatiebeheer. Dat is een mengvorm, maatwerk in bestaande applicaties wordt uitbesteed met dezelfde issues als interne softwareontwikkeling, en ook daar doet men wel eens wat met losse scriptjes.

Alle afdelingen zijn betrokken bij interfacebouw, iedereen doet het op z'n eigen manier en nergens loopt het soepel.

De reden dat ik dat vraag is omdat je technische oplossingen aandraagt die in een proces gegoten moeten worden. Het is vrij normaal bij nieuw te ontwikkelen zaken dat je dat niet meteen in een taal als C++ (overdreven) doet maar dat je het eerst in elkaar krast als prototype (in python idd bvb). Maar als je dat soort werkwijzes niet in regels/ processen/ DOR / DOD whatever vastlegt dan heb je er niks aan. Nog los van het feit dat er iemand als een project manager, product manager of product owner een vorm van overzicht moet houden. Een techneut doet zonder toezicht over het algemeen toch wat hij het fijnste vind werken. Dat is voor iedere dev weer wat anders.

Helemaal mee eens. Het doel is ook om zo'n proces in te richten. Om dat te kunnen doen is het wel nodig dat het besef ontstaat dat het ook anders kan en daarvoor ben ik nu ook eens de technische mogelijkheden aan het verkennen. Als het besef dat het realistisch mogelijk is er zou zijn was het in een dag geregeld.

[Voor 3% gewijzigd door Yucon op 10-07-2020 11:28]

[Knutselsmurf]

Ik heb de indruk dat de mindset moet veranderen. Je schrijft dat er verschillen zijn met ander softwareontwikkelaars, omdat de software toch alleen maar voor intern gebruik is. Ik denk dat die gedachte niet juist is. Jullie (de software-afdeling) hebben de andere afdelingen als klant en op die manier moet ook het volledige ontwikkelproces ingericht worden. Op dat punt hoort het niet uit te maken of de klant een andere afdeling is die een verdieping lager zit of extern is.

Dit ontwikkelproces zal wellicht iets minder strikt vastgelegd hoeven te worden als bij sommige bedrijven gebeurt, maar het is toch handig om vast te leggen hoe een verzoek voor software bij jullie ingediend wordt, hoe vervolgens in samenspraak met de indiener precies vastgelegd wat de wensen/eisen en randvoorwaarden (bijvoorbeeld een deadline) zijn, en hoe er vervolgens voor gezorgd kan worden dat dit netjes opgeleverd kan worden. Ook de al eerder genoemde versiebeheer hoort hier bij.

Daarnaast kan het nuttig zijn om binnen de ontwikkelafdeling te kiezen voor een beperkte set met tools/ programmeertalen/frameworks die gebruikt moeten worden. Dit om te voorkomen dat er wildgroei ontstaat ontstaat, want dat staat doorontwikkeling/onderhoud van de bestaande producten in de weg. Door een kleine set te kiezen, kan er gegarandeerd worden dat iedere medewerker deze volledige set beheerst, zodat je voor onderhoud van een specifiek stukje software niet afhankelijk bent van de originele ontwikkelaar, die 4 jaar geleden vertrokken is.Dit betekent uiteraard niet dat deze set niet kan wijzigen. Als daar noodzaak voor is, is dat geen probleem. Maar dat moet wel een bewuste keuze van de afdeling zijn, en niet het gevolg van de persoonlijke voorkeur van een individu.

Dit teruglezend heb ik de indruk dat het grootste probleem het ontbreken van structuur is. Er is niet 1 ontwikkelafdeling, maar is een een collectie programmeurs. Dat zal omgezet moeten worden naar een afdeling die als één geheel werkt. Dat vergt echter in eerste instantie een organisatorische aanpassing/ wijziging in manier van werken, en daaruit volgen dan pas de technische hulpmiddelen.

[Hydra]

Je hebt een mensen-probleem en dat los je niet op met techniek of processen.

[raxon]

Wat ik lees, in dit stuk is het volgende:

er moeten moeilijke algoritmen bedacht worden in een vooraf bepaalde tijd. Het is een illussie om dat te kunnen in schatten. Dan kun je nog zo ervaren zijn, het gaat niet werken en je haalt je gestelde doel niet. Ik denk dat je zelf veel van de materie begrijpt en snel een oplossing kan verzinnen die het grootste deel van je algoritme benodigd. de afwijking daarvan klinkt houdje touwtje maar is het niet. Het gaat om maat specifieke oplossingen zoals ik begrijp uit de story. Ikzelf heb verschillende werkervaring opgebouwd en merkte voornamelijk bij mijn laatste werkgever dat moeilijke stukken nu eenmaal veel tijd in beslag nemen. Het is ook maatwerk en 1 logge applicatie. Waarbij er volgens een framework wordt gewerkt maar ik toch regelmatig moet zoeken in code naar fragmenten. Dat zoeken wordt steeds langer omdat je zoveel fragmenten code hebt. Copy pasten is een werkwijze die menig developer gebruikt en dan daarop aanpassingen doet indien nodig. Wat je nodig hebt is eenheid.Begin te scrummen met een doorlooptijd van 3 weken. Alles met een technisch ontwerp en daarna pas kan je uren inschatten.

[BEHM]

@Yucon

Laat ik beginnen met je afsluitende vraag in je openingspost. Nee, ik denk niet dat jullie daar uniek in zijn. Maar in aanvulling tot wat hierboven allemaal benoemd wordt, denk ik niet dat het probleem alleen in de procesimplementatie van agile zit.

Hoever jullie zijn in agile maturity weet ik niet, maar ook een hele agile mature organisatie heeft last van het probleem dat jij schetst. De weg naar de oplossing is alleen verschillend.

Dat requirements niet helder te krijgen zijn aan het begin van een traject, en waarbij een snel prototype je wel inzicht kan geven is ook heel logisch. Een extra extra analyst, data-scientist of een ander soort resource zullen ook niet met toekomstige/toekomst vaste scenario’s/oplossingen, tenzij het er eentje is van consultancy bedrijf “De Glazen Bol BV - voor alle voorspellingen uit de toekomst nu op uw road map” Dus een prototype bijschaven totdat je exact weet wat je wilt lijkt mij dan ook een prima strategie.
Ik lees dat er bij jullie micro-services worden gebouwd. Dat gaat dagen duren bij een klein prototype, tot een tijd die je niet kan schatten wanneer de software groter wordt.

En ook je opmerking of een prototype überhaupt wel uitgroeit tot een volwaardig software product is business wise gezien een logische. Je wilt snel in kunnen springen op de markt, waarbij je van te voren niet weet of je daar succesvol wordt. En om de volledige analyse vooraf te doen zorgt ervoor dat je waarschijnlijk de boot mist. Maar ja, dan heb je een werkend prototype voor een nieuwe markt en daar moet je dan een volwaardig product van zien te maken.

Alleen... technisch is dit een uitdaging omdat software vaak niet zo dynamisch is als de business. Continuous refactoring is nodig om de kwaliteit te behouden. In dit proces wordt de software steeds abstracter (= lastiger te begrijpen), en neemt kans op instabiliteit toe (ripple effect) en daarmee de behoefte aan regressietesten (= duur). Dit zorgt ervoor dat naarmate de software groeit het team en de tooling steeds volwassener moeten worden, en de flexibiliteit afneemt.

Ik ben daarom erg benieuwd hoe de anderen dit zien en met deze technische uitdagingen omgaan!

[Tsurany]

Falcon schreef op donderdag 9 juli 2020 @ 18:43:
Daarnaast vind ik het ongelooflijk dat een "prutsoplossing" uberhaupt langs een code review moment kan komen. Een pull-request voor merge naar de master/baas repo kan niet zomaar gecomplete worden, maar moet serieus lokaal getest zijn en tegen de requirements aangehouden worden maar ook tegen de architectuurafspraken/standaarden.

Het is eigenlijk om te huilen hoe vaak dit mis gaat in ontzettend veel bedrijven


Wat ik in de praktijk heel vaak zie gebeuren is dat bedrijven enkel papieren architecten hebben. Die doen niks anders dan pakketselectie en houden zich niet bezig met het opstellen en naleven van standaarden, ze houden zich nauwelijks bezig met hoe applicaties ontwikkeld moeten worden en welke standaarden daarbij gehanteerd moeten worden.

Vervolgens worden er dev teams opgetuigd bestaande uit allerlei externe mensen waarvan verwacht wordt dat ze weten hoe applicaties ontwikkeld moeten worden maar waarvan in de praktijk blijkt dat ze geen idee hebben waar ze mee bezig zijn. Heel toevallig allemaal goedkope Indiërs en Zuid- of Oost-Europeanen omdat management graag met offshore werkt. En natuurlijk kiezen ze niet de ervaren offshore ontwikkelaars uit maar het legertje prutsers dat als "senior developer" verkocht wordt omdat op hun CV staat dat ze 8,24 jaar ervaring hebben in de IT.

Dan zitten er wat internen om heen die het een beetje moeten begeleiden maar helaas weinig technische kennis hebben waardoor ze niet kunnen controleren wat er nu opgeleverd wordt. Code reviews en andere vormen van kwaliteit controle vinden eigenlijk niet plaats omdat al die goedkope dev'ers niet bekend zijn met Quality Assurance.

En uiteindelijk heb je tientallen componenten die houtje-touwtje aan elkaar geknoopt zijn zonder fatsoenlijke interfaces, niet herbruikbaar zijn en zeer lastig te onderhouden zijn omdat developers eerst moeten achterhalen hoe de spaghetti nu in elkaar zit.

En dit is met het hele Agile verhaal alleen maar erger geworden omdat steeds meer verantwoordelijkheid richting de teams gaat zonder dat er mensen in die teams zitten die met deze verantwoordelijkheid om kunnen gaan. Dan krijg je dev teams waarin niemand ooit een cursus testen heeft gevolgd, niemand een design op papier kan zetten en niemand weet wat de business eigenlijk wilt.

[Gomez12]

Tsurany schreef op maandag 27 juli 2020 @ 16:20:
[...]

Het is eigenlijk om te huilen hoe vaak dit mis gaat in ontzettend veel bedrijven

De keerzijde is anders ook om te huilen, namelijk dat mensen 2 jaar gaan specificeren om daarna 3 jaar te gaa watervallen om er dan achter te komen dat er toch een communicatiefutje is geweest maar eigenlijk is dat helemaal niet zo erg, want de software is al 4 jaar achterhaald bij oplevering en presteert voor geen meter.

Dan krijg je dev teams waarin niemand ooit een cursus testen heeft gevolgd, niemand een design op papier kan zetten en niemand weet wat de business eigenlijk wilt.

Ach, je kent de andere kant toch ook wel : 3 jaar gaan designen en de designers bepalen wel even wat de business moet willen.

Wat dat betreft kan ik me wel vinden in wat de TS zegt, de balans is tegenwoordig redelijk zoek, of het is in een uurtje gedaan of het moet een maand kosten om het formeel te doen.
En de klant ziet het verschil niet... Want de beloofde snelhied van het formeel is dat het nog maar 3 weken duurt ipv 4 terwijl het ook in een uurtje te doen is.

[Tsurany]

Gomez12 schreef op maandag 27 juli 2020 @ 16:35:
[...]

De keerzijde is anders ook om te huilen, namelijk dat mensen 2 jaar gaan specificeren om daarna 3 jaar te gaa watervallen om er dan achter te komen dat er toch een communicatiefutje is geweest maar eigenlijk is dat helemaal niet zo erg, want de software is al 4 jaar achterhaald bij oplevering en presteert voor geen meter.


[...]

Ach, je kent de andere kant toch ook wel : 3 jaar gaan designen en de designers bepalen wel even wat de business moet willen.

Wat dat betreft kan ik me wel vinden in wat de TS zegt, de balans is tegenwoordig redelijk zoek, of het is in een uurtje gedaan of het moet een maand kosten om het formeel te doen.
En de klant ziet het verschil niet... Want de beloofde snelhied van het formeel is dat het nog maar 3 weken duurt ipv 4 terwijl het ook in een uurtje te doen is.

Uiteindelijk zijn beide uitersten dramatisch. Agile wordt juist gezien als oplossing voor alle problemen die de klassieke ontwikkelmethoden kennen maar daarbij wordt nauwelijks gekeken naar de eisen die Agile stelt aan de organisatie, aan de development teams en aan de markt waarin je opereert. Agile kent ook zijn uitdagingen en is ook lang niet voor elk project geschikt of de beste keuze. Maar we rammen het er toch maar doorheen omdat een guru ons Agile verkocht heeft.

[The Eagle]

Als ik het zo hoor zijn je systemen en interne procedures inderdaad je bottleneck. Zijn je interne processen wel grotendeels gestandaardiseerd? Zo ja, dan naar Robotic Processs Automation kijken. Zie het maar als de geautomatiseerde Indier die alles overtypt. Kost je (laatste keer dat ik checkte) ca 5 a 10k per geautomatiseerde flow maar heb je er aan personeelslasten danwel developmentkosten zo uit.

[Yucon]

Het heeft in ieder geval heel wat losgemaakt. Naar aanleiding van de eerste serie reacties heb ik het eens goed laten bezinken en me afgevraagd of ik het inderdaad teveel in de techniek zou zoeken. Ik denk het eigenlijk niet; maar tegelijkertijd vraag ik me ook af waar die weerstand die m'n vraag oproept nu precies vandaan komt.

Vergelijk het met een setje zwarte wintervelgen. Als die wat lelijk geworden zijn kun je ze voor 75 euro per velg naar de spuiter brengen maar dat doet vrijwel niemand. De technisch zonder meer slechtere optie is met een busje zwarte action verf die dingen weer wat toonbaarder maken. Maar dat is wel precies wat wel de gangbare keuze is en voor een tientje ben je klaar. Ok, na een paar jaar moet het weer opnieuw maar in de tussentijd doet het wat het moet doen en het alternatief is zo duur dat je daar toch niet voor gekozen zou hebben. En dus als gevolg dat je met aftands uitziende velgen rond blijft rijden. Niemand die moeilijk doet dat het niet voor de eeuwigheid was.. dat wist je immers vooraf en het alternatief was als je wil dat je auto er een beetje netjes uitziet ook niet heel aantrekkelijk.

Ik heb een beetje het gevoel dat ik door een aantal mensen afgefakkeld wordt omdat ik overweeg soms bewust voor het busje action verf te kiezen.

Tegelijkertijd snap ik het ook wel een beetje. De profi devs zijn immers vaak degenen die juist de negatieve kanten van de action spuitbusjes tegenkomen, maar ik vind het te kort door de bocht om het bij voorbaat maar uit te sluiten omdat er naast voordelen ook nadelen aan zitten. Het kan ook wel kloppen dat er procesmatig ook wat te verbeteren valt. Maar net als er soms keiharde technische constraints hebt bestaan er ook gewoon organisatorische constraints die in de praktijk zo goed als keihard zijn. Op je handen gaan zitten omdat andere dingen misschien ook wat beter kunnen zie ik niet zo zitten.

Desondanks is het een flinke eye opener geweest. Ik heb het hier gepost omdat het nu eenmaal over software gaat, maar ik heb er niet bij stilgestaan dat het dan dus ook overwegend hardcore devs zijn die reageren. En die een heel ander referentiekader dan ikzelf hebben. Ik begrijp nu ook wat beter waar de "nee het kan niet simpeler" reflex van m'n dev collega's vandaan komt en dat ik niet kan verwachten dat ze automatisch er vanuit dezelfde optiek als ikzelf naar kijken. Toch betekent dat ook weer niet automatisch dat ze ook 100% gelijk hebben.

Naar aanleiding van dit topic heb ik ook eens die python code nagebouwd in C#, maar dan op de manier zoals een hobbyist met vbscript prutst. Directe queries _{wel beveiligd tegen injections} in plaats van een extra abstractielaag en dergelijk rechttoe-rechtaan werk. Conclusie: het duurt niet heel veel langer dan de python variant. Het lijkt me wel te lastig voor functionele mensen met een technische aanleg. Mede door de weerstand bij de devs ging ik er onbewust toch een beetje vanuit dat het in C# langer zou duren.

Daarnaast was ik toevallig ook zoals @The Eagle voorstelt met RPA aan de slag gegaan. MS Automate (voormalig Flow) ondersteunt nu ook iets wat ze 'UI-Flows' noemen en daarbij kijkt de engine op een soort OCR manier naar de user interface van programma's. Dat mogen ook normale executables zijn en je hebt dus niet zoals vaak het geval is alleen met webclients. Ik weet dat andere pakketten die eventueel ook kunnen en misschien zelfs nog beter. Men is hier nogal microsoft minded, dus het is ook een beetje zoiets van pick your battles. We gaan daarom een pilot opzetten om te kijken hoe goed we met legacy ERP systemen kunnen interfacen hiermee.

Als we daarmee klaar zijn ziet het ernaar uit dat we uit drie keuzes gaan kiezen. In elk van de drie opties wordt het uitgangspunt dat het prototype afhankelijk van de situatie ook best een tijdje in productie kan draaien en tevens dat het uiteindelijk wel weggegooid wordt als een degelijkere oplossing blijkt te zijn.

1) De python oplossing en dan gemaakt door technisch handige functionele collega's op basis van template oplossingen

2) Een soortgelijke oplossing maar dan in simpele C# en gemaakt door professionele programmeurs. Maar wel in nauwere samenwerking met de business en nog steeds met als uitgangspunt dat de code maar tijdelijk bruikbaar is en daarna vervangen moet worden. In dit scenario ga ik als het even kan voorkomen dat ik een technische oplossing ga uitdenken. Het is m'n bedoeling dat dat door een dev gedaan wordt want ik ga een vakman niet vertellen hoe hij z'n vak moet doen. Maar ik ga hem wel gerichter vragen hoe z'n vak uit zou zien als dat binnen bepaalde randvoorwaarden met bijbehorende lagere kwaliteitsnormen zou moeten gebeuren. Misschien had ik in het verleden ook meer in moeten zetten op 'hoe zou het kunnen' in plaats van 'zou het eventueel mogelijk zijn?'. Leermoment.

3) RPA met MS Automate

[Tsurany]

@Yucon houd er vooral rekening mee wie er uiteindelijk verantwoordelijk wordt voor die Python code. Blijf jij dat tot je dood of komt dat uiteindelijk bij iemand terecht die er nooit eerder naar gekeken heeft en nu opeens naast C# ook nog Python moet onderhouden? Vervolgens heb je iemand die handig is met Java en daar even wat in schrijft. Als hij vertrekt moet het toch onderhouden worden, nu moet je al code in drie talen up to date houden.

Dan is nog de vraag in hoeverre die code bestemd is tegen wijzigingen. Wat als opeens de database URL wijzigt, kan die code eenvoudig en met een druk op de knop aangepast worden en direct live gezet worden?
En zijn er unit tests aanwezig om eenvoudig te controleren of die applicatie nog volledig werkt als de database server een update krijgt? Je wilt niet dat iemand gevraagd wordt een regressietest uit te voeren en hij geen idee heeft wat de applicatie doet en hoe hij aangeroepen moet worden.

[The Eagle]

RPA is bij uitstek geschikt om met ERP om te gaan. Ik zou alleen niet specifiek voor de MS variant gaan. Die is van origine ontwikkeld om sharepoint te "automatiseren". Meer zeg ik niet
Kijk ook zeker naar een product als UIpath en anderen.
Kan je even een linkje van een voormalige werkgever geven: https://www.genpact.com/d...ic-process-automation-rpa
Zoeken op die bedrijfsnaam en RPA en je komt al een heel eind. Er is meer dan MS gelukkig.

Ter info: vrijwel niemand kent Genpact, maar het is een van de grootste outsourcers ter wereld en de grootste op BPO voor finance. Doen heel veel procesoptimalisatie ook. Zit echt een shitload aan kennis en ervaring als het om bedrijfsprocessen en optimalisatie gaat. Want outsourcing core business, dus hoe efficienter hoe meer winst. Lage lonen landen ook voor processing uiteraard, dat doe je niet lokaal

[Yucon]

Tsurany schreef op dinsdag 28 juli 2020 @ 16:53:
@Yucon houd er vooral rekening mee wie er uiteindelijk verantwoordelijk wordt voor die Python code. Blijf jij dat tot je dood of komt dat uiteindelijk bij iemand terecht die er nooit eerder naar gekeken heeft en nu opeens naast C# ook nog Python moet onderhouden? Vervolgens heb je iemand die handig is met Java en daar even wat in schrijft. Als hij vertrekt moet het toch onderhouden worden, nu moet je al code in drie talen up to date houden.

Dat zal lastiger liggen dan bij 'echte' software. Of dat acceptabel is is een situatieafhankelijke business keuze. Het eerste project is ondertussen live waarbij dit expliciet geaccepteerd is. Overigens moet je dit ook in een bepaald perspectief zien. Voor sommige dingen heb je geen alternatieven, denk bijvoorbeeld aan whatsapp op je telefoon. Als die app uitvalt ben je gewoon afgesneden van een deel van je communicatie. Er is echter ook software die feitelijk niet meer doet dan geautomatiseerd op wat knopjes drukken zoals men dat vroeger met macro's bedacht had. Als zoiets omvalt kun je gewoon verder als de volumes behapbaar zijn.. alleen moet je dan zelf op wat meer knopjes drukken.

Binnen de support afdeling is op dit moment trouwens ook meer aandacht voor python. Het is nu nog wat pril maar ze zijn wel op weg om wat ermee te kunnen, nog los van de discussie of we dat wel of niet bedrijfsmatig zouden gaan gebruiken.

Dan is nog de vraag in hoeverre die code bestemd is tegen wijzigingen. Wat als opeens de database URL wijzigt, kan die code eenvoudig en met een druk op de knop aangepast worden en direct live gezet worden?
En zijn er unit tests aanwezig om eenvoudig te controleren of die applicatie nog volledig werkt als de database server een update krijgt? Je wilt niet dat iemand gevraagd wordt een regressietest uit te voeren en hij geen idee heeft wat de applicatie doet en hoe hij aangeroepen moet worden.

Dan valt het om. Period.

Unit tests en regressietesten zijn sowieso geen dingen die in deze wereld thuishoren. Natuurlijk hebben die zeker hun bestaansrecht, maar als je redenen hebt om een serieuze behoefte hieraan te hebben dan zit je in een situatie die het gebruik van dit soort prototype scriptjes niet rechtvaardigd. De werking is 'best effort' en als dat onvoldoende is moet je een andere oplossing zoeken in plaats van dat binnen deze oplossing proberen te repareren.

[Voor 5% gewijzigd door Yucon op 30-07-2020 09:45]

[Yucon]

The Eagle schreef op dinsdag 28 juli 2020 @ 20:34:
RPA is bij uitstek geschikt om met ERP om te gaan. Ik zou alleen niet specifiek voor de MS variant gaan. Die is van origine ontwikkeld om sharepoint te "automatiseren". Meer zeg ik niet

Er zijn een paar MS oplossingen. Gaat jouw opmerking ook over de vrij nieuwe variant die om het aangekochte product van WinAutomation heen gebouwd is?

Kijk ook zeker naar een product als UIpath en anderen.
Kan je even een linkje van een voormalige werkgever geven: https://www.genpact.com/d...ic-process-automation-rpa
Zoeken op die bedrijfsnaam en RPA en je komt al een heel eind. Er is meer dan MS gelukkig.

Ter info: vrijwel niemand kent Genpact, maar het is een van de grootste outsourcers ter wereld en de grootste op BPO voor finance. Doen heel veel procesoptimalisatie ook. Zit echt een shitload aan kennis en ervaring als het om bedrijfsprocessen en optimalisatie gaat. Want outsourcing core business, dus hoe efficienter hoe meer winst. Lage lonen landen ook voor processing uiteraard, dat doe je niet lokaal

[Lethalis]

Yucon schreef op vrijdag 10 juli 2020 @ 11:04:
[...]
Softwareontwikkeling bouwt degelijk. Deze afdeling is recent en heeft veel inhuur, en in de rest van het bedrijf bestaan vraagtekens of men na een woelige en heel erg dure startperiode wel op het juiste niveau gestabiliseerd is.

Mijn ervaring is altijd dat een afdeling die met veel ingehuurde mensen werkt, totaal niet efficiënt is.

Dat heeft niet zozeer iets te maken met "degelijk bouwen", maar met slecht op elkaar ingespeeld zijn, waarbij iedere ingehuurde zijn eigen ei kwijt wil. Ook is de feeling met de rest van de organisatie waarschijnlijk ver te zoeken (ze kunnen misschien goed timmeren, maar weten niet wat ze aan het timmeren zijn). Hierdoor krijg je tunnelvisie.

Uiteindelijk wil je dus een vaste afdeling van mensen die lang bij het bedrijf werken en alle facetten ervan kennen. Het is alleen erg lastig om goede mensen te vinden, waardoor je altijd aan loopt te klooien.

Ik vraag me ook af waarom het allemaal verschillende afdelingen zijn. Misschien is het juist beter om er 1 afdeling van te maken, waarbij iedereen van elkaar leert en hecht samenwerkt. Waardoor je elkaar versterkt, in plaats van elkaar in de weg zit.

Als ik aan een boekhoudmodule programmeer, spreek ik dagelijks de boekhouder. Dat idee

Maar goed, is lastig om de boel om te gooien.

En als er ergens niet eens versiebeheer is... man o man.

[The Eagle]

Yucon schreef op donderdag 30 juli 2020 @ 09:44:
[...]

Er zijn een paar MS oplossingen. Gaat jouw opmerking ook over de vrij nieuwe variant die om het aangekochte product van WinAutomation heen gebouwd is?


[...]

De vrij nieuwe variant ken ik niet. Maar gezien het 1. nieuw is en 2. om iets als winautomation gebouwd is en 3. aangekocht is, verwacht ik niet dat het een heel volwassen product zal zijn wat alle kanten van een business workflow af kan dekken.
ALs je echt meters wilt maken ga je bij de marktleiders kijken. Maar hou er wel rekening mee: als je dit gaat doen moet je bedrijfsproces ook uniform zijn. Als je bijvoorbeeld meerdere BU's hebben moeten ze een factur ook allemaal op de zelfde manier inboeken.

[Neverwinterx]

Yucon schreef op donderdag 9 juli 2020 @ 15:51:
Als ik nu echter een redelijk rechttoe-rechtaan interface zou laten bouwen (klantorder aanmaken in systeem a zorgt automatisch voor een klantorder in systeem b) ben ik minimaal een week of meer kwijt. Dat is niet te verkopen en het is een drijvende kracht om die houtje-touwtje oplossingen veel te ver door te drijven. Wat weer z’n eigen problemen oplevert.

Los van de rest van de discussie: ben ik de enige die een week voor een dergelijke change helemaal niet te veel vindt, aangenomen dat reviews en testing etc erbij hoort? Al is het uiteraard moeilijk om de concrete change goed in te schatten met dergelijke beperkte beschrijving (wat begrijpbaar is, je kan hier uiteraard niet in detail treden).
Zijn je verwachtingen wel realistisch?
Je geeft af op anderen die in het verleden zelf snel iets in elkaar hebben geboxt in SQL/PowerApps/access/weetikveel oplossingen, maar tegelijk geef je aan dat je zelf snel iets in elkaar hebt geboxt in Python.
Als je changes goed geimplementeerd en goed getest wilt, dan is dat nu eenmaal niet in 1 dag klaar.

[Yucon]

@Neverwinterx bij interne ontwikkeling is het niet ongebruikelijk dat functionele key users actief meewerken in het ontwikkeltraject voor onder andere testwerk. Die tijd valt dan dus buiten de schatting. Verder zijn reviews niet perse nodig. Maar het is wel een mooi voorbeeld, want reviews dragen bij aan de kwaliteit. Er zijn situaties waarin die kwaliteit helemaal niet gevraagd wordt ('als het werkt dan werkt het') en door ze dan dus toch uit te voeren gooi je in zekere zin geld weg. Dat soort vanzelfsprekendheden is precies wat ik eruit wil snijden.

Wat betreft m'n eigen werk snij je wel een terecht punt aan. Het verschil zit erin dat mijn code op zich nog wel netjes en logisch in elkaar zit. Nu realiseer ik me dat dat makkelijk gezegd is, maar ik heb vroeger geleerd volgens het boekje te programmeren en als ik door die bril ernaar kijk is het op z'n minst toch wel best redelijk.

Als ik dat vergelijk met bijvoorbeeld die SQL dan zitten daar bijvoorbeeld collega's tussen die er geen kwaad in zien super ingewikkelde joins te maken, vervolgens de ongewenste duplicaten te onderdrukken met een distinct 'want ik weet ook niet waar die dubbele ineens vandaan komen' en als kers op de taart een paar onnodige likes met wildcards ertussen duwen. Op die manier blijft er niet veel van de performance over.

Beide varianten zijn op de langere termijn moeilijk te onderhouden. Maar als je een paar weken later een kleinigheidje aan zo'n join wil veranderen is het risico vrij groot dat ergens anders iets omvalt. Met een oplossing gebouwd op basis van if/then/else met wat veel eenvoudigere queries ertussen zie je veel beter wat je doet als je iets wijzigt.

Overigens knippen en plakken die collega's ook maar wat. Als ik ze dus een goed bruikbaar voorbeeld geef om mee te knippen en plakken is het zeker haalbaar hun code veel beter te krijgen. Maar ik kan in alle redelijkheid niet verwachten dat ze dat zelf bedenken omdat ze simpelweg geen goede voorstelling kunnen maken hoe een nettere oplossing eruit ziet. In die zin verwijt ik ze dus ook niets.. en eerlijk gezien vind ik het zelfs behoorlijk knap uit wat voor een code sommigen nog wijs weten te worden.

[Voor 14% gewijzigd door Yucon op 31-07-2020 17:19]

[The Eagle]

Qua development van interfaces: je wilt de interface eigenlijk altijd aan de kant van de aanleverende applicatie. Daar zit immers ook de business logica die je evt aan moet roepen. Als die wijzigt en je interface zit aan de ontvangende kant, moet je op twee plekken wijzigen. Maakt het nodeloos complex en duur. Plus dan moet de business van de ontvangende kant ineens de business logica van de verzendende kant doorgronden, en das vaak makkelijker gezegd dan gedaan