Oude ontwikkelomgeving vlottrekken

[P_Tingen]

Als ontwikkelaar werk ik bij een bedrijf* dat hoogwaardige transportproducten maakt voor diverse industrieën. Het betreft zowel maatwerk als standaard maten. Het bedrijf heeft twee vestigingen, enkele tientallen werknemers en een ontwikkelomgeving van 2 man, waar ik dus 1 van ben.

Het pakket is een 100% maatwerk client-server applicatie van eind 90-jaren. Sinds die tijd is het actief onderhouden en uitgebreid. Er is een diepe integratie met het productieproces. Klanten sturen hun orders via de mail. Deze mail wordt automatisch ingelezen, geparsed en daar worden opdrachten voor gemaakt die rechtstreeks vanuit het pakket naar de productiemachines wordt gestuurd. Die productiemachines sturen op basis daarvan weer de robots en plc's aan, maar dat ligt buiten ons werkgebied. Orders komen soms 's morgens binnen en moeten dan 's middags geleverd worden. Transporteurs kunnen inloggen in ons systeem en zo zelf zien wat ze moeten vervoeren.

Het pakket is gemaakt in een ontwikkeltaal die niet erg gangbaar is. De ontwikkelomgeving zelf werkt prima en is up-to-date, maar ontwikkelaars liggen niet voor het oprapen, vandaar dat met het idee gespeeld wordt het hele pakket op middellange termijn (5-10 jr) te vervangen door iets waar meer support voor is, zowel qua ontwikkelomgeving als ontwikkelaars. Het idee is wel om het maatwerk te laten blijven vanwege de integratie met het productieproces.

Het systeem werkt prima, maar onderhoud wordt wel 'een dingetje'. Wijzigingen die we door willen voeren duren steeds langer en zijn steeds moeilijker. We hebben het idee dat we een beetje vast beginnen te lopen in het pakket. Vandaar dat we op zoek zijn naar mogelijke oplossingen.

Een korte analyse levert het volgende op:

• De database bevat veel tabellen, indexen en velden die niet nodig zijn.
• Er is veel programmatuur die (dus) ook niet nodig is
• Er is redelijk veel dode code
• Er is redelijk veel dubbele code
• Veel zaken worden hard-coded afgehandeld
• Het pakket wordt soms misbruikt met oneigenlijke constructies (bv bij Valuta "controle" invullen en dan in de programmatuur afvangen dat er iets moet gebeuren dat niks met een valutacode te maken heeft)
• Er zijn teveel settings, vinkjes en toggles in het systeem om specifieke problemen op te lossen die programmatuur extra complex maken
• Programmatuur is naar de inzichten van nu te weinig opgeknipt; programma's van enkele duizenden regels code zijn geen uitzondering.
• Scoping van tabellen en variabelen is veel te ruim, zodat als je iets aanpast in een programma, je geen idee hebt wat de gevolgen er van zijn.
• Het pakket werkt voor een groot deel obv een framework uit 1995 dat nu hopeloos verouderd is en waar zelfs geen online documentatie van is
• Logic en UI zijn niet gescheiden
• Er zijn geen unittesten
• Er is zo goed als geen documentatie

Een groot deel hiervan is terug te voeren op het in-huis onderhouden van het pakket. Dat maakt snelle aanpassingen mogelijk. Daarbij is in het verleden weinig aandacht besteed aan het opschonen van code en database ("je hebt er geen last van").

Wat zijn de opties? Ik heb een aantal opties op een rij gezet:

1. Shift-delete + restart
Sounds good, doesn't work. Probleem is dat we met zijn tweeën zijn en ook de dagelijkse ondersteuning moeten doen. Er is geen tijd om gezellig met zijn tweeën in een hok te gaan zitten en over een jaar met een goed pakket te komen.

2. Extra persoon erbij
Zou wellicht te regelen zijn. Probleem is dat die niet snel ingewerkt is en bovendien lastig te vinden. Daarnaast is dit op zich alleen symptoombestrijding omdat het probleem er niet wezenlijk door wordt veranderd. We hebben hooguit meer slagkracht om de problemen aan te pakken.

3. Opstellen documentatie
We zouden alle bedrijfsprocessen in kaart kunnen brengen middels een schema en dat aanvullen met welke programma's daarbij horen plus een uitleg van de achterliggende logica.

4. Code-isolatie
We zouden stap voor stap code uit het oude systeem kunnen halen en dat onderbrengen in aparte programma's waarbij de UI en de business logic gescheiden is, eventueel in micro-services. Tegelijk zouden we daar dan unit testen voor moeten maken.

5. Opschonen
Het pakket zou eens doorlopen moeten worden om ongebruikte zaken eruit te kunnen halen en te verwijderen. Dit zou een en ander wat behapbaarder maken. Programmatuur én database moeten we dan opschonen.

6. Migreren naar ander platform
We zouden ook nu al de migratie naar wat anders in gang kunnen zetten. We moeten er dan ook iemand bij hebben omdat we anders teveel beginnersfouten zouden maken. Bovendien zitten we nog vroeg in het proces waarin we bepalen naar wélke andere omgeving we dan toewillen.


Optie 3,4 en 5 lijken me het meest praktisch op korte termijn.
Hoe kijken jullie hier tegenaan, mis ik opties? Hoe is dit het beste aan te pakken?


* uit privacy voor het bedrijf laat ik de bedrijfsnaam even in het midden.

[P_de_B]

* uit privacy voor het bedrijf laat ik de bedrijfsnaam even in het midden.

krijg ik een koekje als ik de naam kan raden?

[P_Tingen]

P_de_B schreef op vrijdag 27 maart 2020 @ 13:53:
* uit privacy voor het bedrijf laat ik de bedrijfsnaam even in het midden.
krijg ik een koekje als ik de naam kan raden?

Haha, jij niet

[JukeboxBill]

Begin eerst eens met punt 3.
Dat is een eerste vereiste om de vervolgstappen uit te voeren en hiervoor een plan van aanpak te maken.
Het is ook nodig als je besluit om door derden een nieuw systeem te laten bouwen.

[JustAnotherDev]

Zonder te voorbarig te zijn, nooit gaan voor optie 1. Zelden dat het goed gaat wanneer je in een keer een applicatie gaat ombouwen waarbij het 100% foutloos gaat. Vaak denkt een developer, dat kan mooier en blijkt het na de refactor / ombouw, onstabieler, functionaliteit die ontbreekt etc etc.

Optie 3 klinkt goed echter in de praktijk na het opleveren van de documentatie blijkt deze vaak toch niet 100% overeen te komen met hoe de applicatie daadwerkelijk is opgezet en hoe de bedrijfsprocessen (vaak vanuit de business) zijn beschreven. En als je wel documentatie wilt gaan maken die alle ins en outs beschrijft van het systeem, de bedrijfsprocessen en de relatie hiertussen gaat dit erg veel tijd kosten zonder nog enige aanpassing aan het systeem.

Wat ik niet terug zie in je verhaal is, wie de stakeholders zijn. Het belang van elke stakeholder en in hoeverre ze dit belang ook zien. Daarnaast hoe belangrijk is het systeem? Wat gebeurt er als je een nieuwe bug introduceert waardoor het systeem een dag niet werkt? Om welke taal gaat het? Is het echt nodig om het systeem om te schrijven? Of is het refactoren voldoende? Wat is de testcoverage? Kan je garanderen dat wanneer je iets aanpast er niet dingen omvallen? Dat soort zaken.

En ja dit zeg ik vanuit een developer oogpunt. Niks is vervelender dan na 3x belooft te hebben dat het niet meer voor zal komen en daarna alsnog heel de productie stil te leggen door een nieuwe change. Je krijgt stress, verliest vertrouwen en goodwill bij de andere stakeholders en dat soort zaken.

[P_Tingen]

Optie 1 was ook niet mijn voorkeur. Ik heb al een paar keer een 1:1 rewrite meegemaakt en dat is zo ongeveer het moeilijkste wat er is, dus dat gaan we denk ik maar niet doen.

De applicatie is de ruggengraat van het bedrijf. Als het langer dan een uur plat ligt, zal de productie langzaamaan stil komen te liggen, de ene machine wat eerder dan de ander. De productie werkt er mee, orderentry, bestellingen, personeelsadministratie, verkoop. Eigenlijk alles en iedereen zijn moeder, behalve de boekhouding.

Op termijn moet men iets met het systeem. Een optie is herschrijven in een andere ontwikkelomgeving (nu in Progress 4GL) om het voor de toekomst veilig te stellen. Ik zit er tijdelijk en over 10 jaar is mijn collega met pensioen. Maar een nieuw / ander systeem moet ook ergens beginnen en een opgeschoond oud systeem is een goed startpunt. En wellicht is het tegen die tijd zo opgeschoond dat het gemakkelijker te onderhouden is, waardoor het niet eens herschreven hoeft te worden.

Voor de kortere termijn zit ik op de 5-4-3 lijn, dus beginnen met opschonen (stap 5). Dat kan vrij klinisch, met wat tooling en zonder al te veel functionele kennis. Dan stap 4, code isoleren in zelfstandige, losstaande programma's waarbij UI en BL losgekoppeld zijn. Dit kunnen we tussendoor oppakken en in kleine stapjes doorvoeren. Als we daar een begin mee hebben gemaakt, kunnen we verder met stap 3, documenteren aan de hand van die nieuwe componenten.

[Tsurany]

Ik zou voor optie 4 kiezen, code isoleren en tijdens dat isoleren kan je dan opschonen en documenteren. Uiteindelijk houd je dan een hele set aan componenten over die afzonderlijk beheerd en aangepast kunnen worden. Dan kan je een mooie event driven microservice architectuur toepassen.

Dat zal een rewrite later ook makkelijker maken aangezien je niet het hele systeem hoeft te vervangen maar component voor component kan herschrijven.

[xleeuwx]

Ik zou in dit geval gaan voor strangler principles wat uiteindelijk grotendeels neerkomt op je 5-4-3.

Door code te isoleren en apart te draaien kan je bijvoorbeeld tijdelijk dubbel te draaien en dus beide system in productie testen zonder het huidige systeem uit te zetten.

Ik heb nog interessante blogpost hierover:
https://herbertograca.com...ow-i-put-it-all-together/

Let wel met Postgres 4GL ben ik niet bekend, maar dat zou voor overall architectuur niet uit moeten maken.

Het belangrijkste is dat je precies weet wat het systeem doet, dit bereik je door documentatie te schrijven of unit/functional/e2e tests te maken... maakt verder niet hoe, als je maar precies weet wat er in het zwarte doosje gaat (code) en wat er uit hoort te komen.

Daarna kan je het nieuwe systeem uittekenen en stap voor stap onderdelen van het systeem vervangen door nieuwe.

[ Voor 32% gewijzigd door xleeuwx op 27-03-2020 16:16 ]

[YakuzA]

Probleem bij aanpak 4 is vaak dat er ineens 2 systemen onderhouden moeten worden. Inclusief de extra support en werkdruk.
Vaak zie je dat er nieuwe code bijkomt in de nieuwe services, maar dat de codebase van het oude product nog steeds blijft doorgroeien, omdat die ene flow net niet op microservices mapped etc.

[dvdmeer]

Optie 5-4-3 klinkt aardig maar waarom zou je 5 doen als je waarschijnlijk toch van de omgeving af gaat stappen? Of is dit nog niet zeker?
Ik weet trouwens niet hoe toekomst proof Progress 4GL is. We gebruiken bij ons op het werk en ik ontwikkel er ook af en toe wel in maar vind het geen fijne taal. De interface ziet er erg outdated uit en alle nieuwere tools er omheen voelen als een soort hack bovenop het systeem.
De database ben ik ook geen fan van want clustering oplossingen hebben ze niet. We hebben nu een Pro2SQL oplossing om in ieder geval een 2e database te hebben voor reports, etc.
Maar goed, we zijn nu bezig om ons transport management systeem eruit te gooien en zijn behoorlijk ver met het bouwen van een eigen, modern systeem op basis van web met een mssql database er achter. Werkt toch allemaal een stuk lekkerder.

Persoonlijk zou ik niet heel veel jaren meer door blijven draaien met die software. Tuurlijk, als het werkt dan werkt het, maar ik zou toch echt wel kijken naar een andere oplossing.

[SPee]

Ik zou zelf kiezen voor de volgorde:

1. 5. Opschonen code: zodat deze leesbaarder is, beter te begrijpen en weinig duplicatie
2. 3. Documenteren: Door o.a. tijdens het opschonen ook te documenteren, krijg je inzichtelijk wat er nu gebeurd en kun je alvast nadenken aan toekomstige eisen
3. 4 icm 1 of 6. Dus het systeem opsplitsen in modules/componenten en mbv het strangler principe deze vervangen voor een moderne variant

Bedenk wel dat dit een ERP systeem is. Door dat buzzword zullen er bij veel mensen alarmbellen afgaan met; duur, groot, complex. Alternatieven waar je dan als eerste aan denkt zijn; SAP, Exact, Salesforce. Bepaald geen kleintjes of goedkope producten. Dat "zomaar" vervangen zal eerder een CEO beslissing zijn, dan van een ontwikkelaar.
De opties 5 en 3 kun je zelf doen en heb je grotendeels zelf invloed op.
De laatste stap is het langzaam migreren naar een modern platform. Doordat je met 3 de processen, afhankelijkheden en informatiestromen beter in kaart hebt, kan de CEO een betere beslissing maken.

[pedorus]

P_Tingen schreef op vrijdag 27 maart 2020 @ 13:49:
Veel zaken worden hard-coded afgehandeld

Op zich een goede analyse, maar deze zie ik niet als een probleem. https://thedailywtf.com/articles/Soft_Coding anders?

Programmatuur is naar de inzichten van nu te weinig opgeknipt; programma's van enkele duizenden regels code zijn geen uitzondering.

Mwah, duizenden regels code lijkt me eigenlijk vrij normaal voor een compleet programma, zie dat probleem niet zo. Een programma als Excel lijkt me prima werken, heeft vele malen meer regels, en zou ik niet naar een micro-service-architectuur gaan omzetten.

4. Code-isolatie
We zouden stap voor stap code uit het oude systeem kunnen halen en dat onderbrengen in aparte programma's waarbij de UI en de business logic gescheiden is, eventueel in micro-services. Tegelijk zouden we daar dan unit testen voor moeten maken.

Wat mij het handigst lijkt is dat je dingen identificeert die relatief snel in een andere taal kunnen worden geschreven, die gekoppeld kunnen worden, en die snel winst opleveren. Desnoods maak je geeneens unit tests en scheid je ook de UI en business logic niet in aparte programma's. Of dat relevant is hangt namelijk helemaal van het stukje software af, misschien is het een klein scriptje om mee te beginnen, of een proxy die je ergens tussen hangt, of een stukje met vrijwel alleen UI. Vervolgens vervang je langzamerhand net zo veel componenten totdat er geen oude software over is in de ongewenste taal.

Ik heb hier goede ervaringen mee, inmiddels meerdere oude talen volledig weggewerkt, stukje bij beetje. We hebben niet eerst de moeite genomen van optie 5 (oude project in de oude taal opschonen), ook de onbereikbare delen van de oude code staat nog gewoon in het museum in git. Documenteren doe je bij schrijven, niet als aparte stap, want dat vindt bijna niemand leuk en gebeurd dus anders vaak niet (goed). Achteraf nog eens documentatie/tests maken is vaak wishful thinking.

6. Migreren naar ander platform
We zouden ook nu al de migratie naar wat anders in gang kunnen zetten. We moeten er dan ook iemand bij hebben omdat we anders teveel beginnersfouten zouden maken. Bovendien zitten we nog vroeg in het proces waarin we bepalen naar wélke andere omgeving we dan toewillen.

Als er eigenlijk standaardsoftware voor dit soort zaken is dan zou ik een leverancier gaan opzoeken die ook de implementatie doet, dus ik zie dat probleem niet zo in? Het lijkt me gek om zelf maatwerksoftware te gaan maken voor een standaardsituatie, dan klinkt het alsof je nuttigere dingen kan doen.

[Gerco]

pedorus schreef op zondag 29 maart 2020 @ 03:01:
Mwah, duizenden regels code lijkt me eigenlijk vrij normaal voor een compleet programma, zie dat probleem niet zo. Een programma als Excel lijkt me prima werken, heeft vele malen meer regels, en zou ik niet naar een micro-service-architectuur gaan omzetten.

Hiervoor moet je de terminologie van Progress 4GL begrijpen. Een "programma" in Progress 4GL (tegenwoordig ABL) is een enkel bestand, vergelijkbaar met een "class" in Java of C#, bijvoorbeeld.

Als er eigenlijk standaardsoftware voor dit soort zaken is dan zou ik een leverancier gaan opzoeken die ook de implementatie doet, dus ik zie dat probleem niet zo in? Het lijkt me gek om zelf maatwerksoftware te gaan maken voor een standaardsituatie, dan klinkt het alsof je nuttigere dingen kan doen.

Dit x1000! Maatwerk zal waarschijnlijk wel nodig zijn, maar als je een build/buy beslissing moet nemen heb je *hele* goede redenen nodig om daar build uit te halen. 20 jaar geleden was dat misschien anders, maar tegenwoordig is er veel meer software "standaard" beschikbaar en veel standaardpakketten hebben uitgebreide plugin en scripting mogelijkheden om de ontbrekende functionaliteit toe te voegen.

[mcDavid]

Ik zou gaan voor optie 4/5/6. Denk na over een framework, hoe je zou willen dat de architectuur van de "nieuwe" software eruit ziet. En ga vervolgens alle nieuwe functionaliteit op die manier bouwen. En ruim direct daarbij de oude code op. Dan zal er vanzelf steeds meer code uit de oude codebase verdwijnen terwijl de nieuwe codebase groeit.

Voorwaarde is dat je wel een brug hebt om te communiceren tussen codebases. Maar dat kan heel abstract zijn. Een RPC API bijvoorbeeld (zoiets zal waarschijnlijk toch al bestaan voor de cliënt) of desnoods gewoon shell commando's.

[YakuzA]

mcDavid schreef op zondag 29 maart 2020 @ 08:35:
Ik zou gaan voor optie 4/5/6. Denk na over een framework, hoe je zou willen dat de architectuur van de "nieuwe" software eruit ziet. En ga vervolgens alle nieuwe functionaliteit op die manier bouwen. En ruim direct daarbij de oude code op. Dan zal er vanzelf steeds meer code uit de oude codebase verdwijnen terwijl de nieuwe codebase groeit.

Voorwaarde is dat je wel een brug hebt om te communiceren tussen codebases. Maar dat kan heel abstract zijn. Een RPC API bijvoorbeeld (zoiets zal waarschijnlijk toch al bestaan voor de cliënt) of desnoods gewoon shell commando's.

De vraag blijft of je met een ontwikkelteam van 2 man, die ondertussen ook alle support voor het oude systeem moet blijven doen, hier wel capaciteit voor hebt?

Als de resourcing er voor is, kan het idd op deze manier.

[mcDavid]

YakuzA schreef op zondag 29 maart 2020 @ 09:16:
[...]

De vraag blijft of je met een ontwikkelteam van 2 man, die ondertussen ook alle support voor het oude systeem moet blijven doen, hier wel capaciteit voor hebt?

Als de resourcing er voor is, kan het idd op deze manier.

Het is de enige manier.

Ja als je echt alleen maar kunt dweilen met de kraan open, dan gaat het niet. Maar dan gaat het op een andere manier al helemaal niet.

[leto001]

Ik zou voor optie 4 gaan en heb dat ook een keer gedaan met een team. Was een behoorlijk monolithische applicatie met exact dezelfde problemen als jij beschrijft. Team was hier man of 10 groot, domein gigantisch en enorm geïntegreerd met allerlei andere systemen. Inwerken van nieuwe collega’s duurde een maand of 4. Daarnaast was er enorme druk vanuit de rest van het bedrijf op nieuwe features, dus geen optie om optie 1 te volgen, los van de haalbaarheid van die optie.

We hebben toen als team besloten om bij elke nieuwe ontwikkeling te kijken naar de optie om dat stuk code op te schonen en te verservicen. Op die wijze konden we in kleinere stappen schonere code maken, die duidelijk gescheiden was en werd het ook eenvoudiger om front-end en backend te scheiden. Daarmee konden opeens ook andere teams van onze apis gebruik maken.

[PetervdM]

ik zou - als het qua geld en doorlooptijd mogelijk is - gaan voor optie 6. niet migreren, maar van scratch.
dus analyseren wat de functionaliteit is van het huidige systeem en een nieuw ontwerp maken ( 3+ ). zo haal je ook de slack uit het systeem: de dode code, ongebruikte tabellen en velden en oneigenlijk gebruik. daarna het nieuwe systeem bouwen.
dit ga je niet met twee man klaren, daar zul je externen voor moeten inhuren die dit voor je gaan doen. jullie blijven het support aan de bestaande omgeving doen en helpen bij de documentatie van de nieuwe. zo leer je al doende het in de vingers te krijgen.
niet ideaal, maar dat is geen enkele oplossing. ik heb 3-4-5 genoeg zien gebeuren, maar het resultaat was altijd teleurstellend.

[Mavamaarten]

PetervdM schreef op zondag 29 maart 2020 @ 11:01:
ik zou - als het qua geld en doorlooptijd mogelijk is - gaan voor optie 6. niet migreren, maar van scratch.
dus analyseren wat de functionaliteit is van het huidige systeem en een nieuw ontwerp maken ( 3+ ). zo haal je ook de slack uit het systeem: de dode code, ongebruikte tabellen en velden en oneigenlijk gebruik. daarna het nieuwe systeem bouwen.
dit ga je niet met twee man klaren, daar zul je externen voor moeten inhuren die dit voor je gaan doen. jullie blijven het support aan de bestaande omgeving doen en helpen bij de documentatie van de nieuwe. zo leer je al doende het in de vingers te krijgen.
niet ideaal, maar dat is geen enkele oplossing. ik heb 3-4-5 genoeg zien gebeuren, maar het resultaat was altijd teleurstellend.

Dat was ook mijn eerste gedachte. Niet uitgaan van "hoe kan ik dit systeem laten doen wat ik wil", maar "wat moet het systeem kunnen, en we bouwen exact dat". Als je dat allemaal opgelijst krijgt, kan het uiteindelijke resultaat er een pak makkelijker uit zien dan oorspronkelijk gedacht.

Maar ja, zoiets kost centen en laat je niet door degene doen die het systeem momenteel recht houdt, maar door een partij die gespecialiseerd is in het maken van zulke systemen.

[Yucon]

Mavamaarten schreef op zondag 29 maart 2020 @ 11:09:
[...]


Dat was ook mijn eerste gedachte. Niet uitgaan van "hoe kan ik dit systeem laten doen wat ik wil", maar "wat moet het systeem kunnen, en we bouwen exact dat". Als je dat allemaal opgelijst krijgt, kan het uiteindelijke resultaat er een pak makkelijker uit zien dan oorspronkelijk gedacht.

Maar ja, zoiets kost centen en laat je niet door degene doen die het systeem momenteel recht houdt, maar door een partij die gespecialiseerd is in het maken van zulke systemen.

Mee eens. Ongezien durf ik wel te stellen dat voor meer dan de helft van onderstaande punten helemaal geen rationele business case bestaat.

- Het pakket wordt soms misbruikt met oneigenlijke constructies (bv bij Valuta "controle" invullen en dan in de programmatuur afvangen dat er iets moet gebeuren dat niks met een valutacode te maken heeft)
- Er zijn teveel settings, vinkjes en toggles in het systeem om specifieke problemen op te lossen die programmatuur extra complex maken

Overigens zijn moderne ERP systemen ondertussen ook onoverzichtelijke gedrochten. Wat je daarom tegenwoordig steeds meer ziet is geen maatwerk in het systeem te bouwen, maar in plaats daarvan kleine applicaties die als UI werken te bouwen die dan integreren met data en business logic van het ERP pakket. Op die manier kun je voor specifieke rollen specifieke UI's krijgen waar alleen de zinvolle elementen in zichtbaar zijn. Dat is beter hanteerbaar dan uitgebreid in het ERP systeem te gaan sleutelen.

[Joey117]

Wat ik mis in het verhaal is wat het bedrijf zelf wil. Ze 'spelen' met wat ideetjes, maar dat geeft mij meer het gevoel dat ze jullie willen pleasen dan dat ze zelf een bepaald idee hebben voor de toekomst.

Willen ze dit pakket nog 100 jaar gebruiken tot het echt niet meer kan (en dan de pijn pakken)
Willen ze nu de pijn pakken en het risico dat de business een jaar plat ligt, maar dan wel een fantastisch nieuw pakket hebben.

Stap 1: Zorg voor iemand die de business door-en-door-en-door kent en zorg dat je van hem/haar een goede productowner maakt. Die je vragen kan beantwoorden en weet hoe alle stakeholders willen werken met het pakket.
Stap 2: Testen schrijven voor de huidige code en kijken of het ook echt zo werkt als je denkt.
Stap 3: Stukje voor stukje de code opschonen en dan de testen draaien. Dingen loshalen die je kunt loshalen en dan weer de testen draaien.
Stap 4: Gefeliciteerd, je bent nu 3 jaar verder en kunt gaan kijken hoe je je pakket toekomstbestendig gaat maken.

Met een tijdelijke werknemer en andere die bijna met pensioen is, zou je je moeten richten op de mensen die dit in de toekomst kunnen gaan oppakken. Maak hun leven makkelijker. Want naast je support taken moeten jullie dit soort dingen niet willen oppakken. Daar heb je op zijn minst 2 man voor nodig die hier redelijk ongestoord en voor lange tijd aan kunnen werken, in samenwerking met de product owner.

Ik predik hier overigens niet dat jullie nu volledig Agile moeten werken, maar de term productowner dekt wel precies de lading van de derde persoon die jullie nodig gaan hebben.

[ Voor 6% gewijzigd door Joey117 op 29-03-2020 11:20 ]

[koppie]

Mijn advies is toch op hoofdlijnen te documenteren: Met de WWW-vraag: Wie wat wanneer. Op basis daarvan kan je dan toch nog een keer goed analyseren en discussieren waar de grootste problemen zitten, en wat er aan gedaan moet worden.

Dan komen de business-keuzes aan bod:
- Maatwerk of toch een pakket?
- Wat is belangrijk, ook tijdens een migratie/ombouw? Extra functionaliteit of toch een big-bang?

Dus je moet op die basis, je klant betrekken bij de keuzes, en op basis van voor en nadelen een keuze maken waar dan iedereen achter kan staan.

Ik verwacht niet dat je met drie of vier man groot genoeg bent om zo'n migratie in redelijk tijdsbestek te doen, maar het belangrijkste is om je klanten en gebruikers mee te nemen, en niet een 100% herbouw te doen, maar juist de dingen die echt nu belangrijk zijn voor de klant.
(Verhaal hierboven )

[DjoeC]

Je zit met 2 man, jij bent er tijdelijk en je collega nog "een jaar of 10".

Wie zou de applicatie willen vervangen? Stuur jij daar op aan, wil de directie dat - misschien wel omdat ze hints opvangen - wil je collega dat? Zijn er actuele problemen met onderhoud of gaat het erom dat er geen "specialisten" in de markt te vinden zijn? Als ik de constructies van Progress zo zie ishet allemaal niet complex maar is het vooral niet gelikt en geen luxe grafische tool zoals de moderne talen of tools.

Met de mankracht die je hebt is een migratietraject vrijwel zeker gedoemd te mislukken, al is het alleen maar vanwege de verwachtte doorlooptijd. Ik zag je schrijven "op termijn van 5-10 jaar", jij bent tijdelijk en doet er waarschijnlijk niet aan mee. Voor zo'n traject het je tenminste 2 dedicated personen nodig die snappen hoe dit bedrijf werkt en die snappen wat nodig is en die het klusje ook willen afmaken (lange termijn commitment).

Welke ontwikkelstraat zou je willen gebruiken en waarom? Wat is de toekomstvastheid van die nieuwe straat? Hoe stabiel zijn de onderliggende operatingsystemen, gaan die mee veranderen? Hoe stabiel zijn de koppelingen met de productie/magazijnstraten? Wordt daar gelijktijdig vernieuwd?

Je hebt een organisatie die afhankelijk is van de huidige software. "Diepe integratie in het produktieproces". Realiseer je je de risico's die bij migratie komen kijken? Heb je een beeld bij de doorlooptijd (begin tot einde) van het migratietraject EN van de kosten als het faalt? Je moet kunnen garanderen - en dus de backing hebben van de directie - dat produktieprocessen niet verstoord gaan worden en dat het traject ook echt afgemaakt gaat worden.

Ik zou er als volgt naar kijken: Documenteren van de applicatie: Zinloos. Documenteren van de processen die geraakt worden door de applicatie: absoluut als eerste oppakken. Niet vanuit de huidige programmatuur maar vanuit de huidige operatie. Je ziet vaak dat processen op beschikbare software zijn gemapt. Met software uit de jaren negentig hoeft dat niet verkeerd te zijn, maar zijn er vanaf de werkvloer nieuwe inzichten?

Vervolgens: Ontkoppel de "diepe integratie". Vervang onderdelen van achteren naar voren of vervang onderdelen door nieuwe slanke pijlers, maak ze flexibel met de mogelijkheid om nieuwe wensen te realiseren, maar blijf nog even compatibel. Een ontvangen mail is prima naar 2 applicaties te sturen, sterker: als de nieuwe situatie een app of webinterface beschrijft kan daarachter ook best een mail naar de oude applicatie verstuurd worden. Zorg dat er een soort van architectuurplaat komt van software en gekoppelde werkvloer, huidige en toekomstige situatie.

Je gaf al aan: 1-op-1 migratie gaat niet werken. Je zult zonder meer langere tijd met 2 applicaties moeten werken wat voor de gebruikers frustrerend kan zijn als het risico bestaat dat de migratie nooit zal worden afgerond.

Eigenlijk is Tweakers geen platform om in 1 posting alle valkuilen van zo;n traject te benoemen. Ik zal best wel wat gemist hebben of in herhalingen zijn gevallen - excuus.

Maar: Bezint eer gij begint, zorg voor langdurig draagvlak door middel van een bussinesscase, zowel op directieniveau (want dit is een duur en risicovol traject) als op gebruikersniveau (want het doet t al jaren en waarom moet het allemaal anders).

Vanuit mijzelf gezien: 't Klinkt eigenlijk best aantrekkelijk om zo'n traject weer eens te doen

[Yucon]

Oja, nog een belangrijk punt. Ouwe maatwerkapplicaties vervangen is zonder de juiste aanpak een groot drama. Zoiets past namelijk als een maatpak en de verwachting bij gebruikers is daarop gebaseerd. Terwijl die 1:1 fit juist de grote valkuil is. Een dergelijk traject gaat in de regel daarom samen met een hele duidelijke communicatie vanuit het management dat "we niet het oude pakket gaan nabouwen".

Anders verzand je namelijk in discussies als "dit moet het nieuwe pakket ook kunnen want het oude kon het ook" in plaats van dat je discussies op basis van rationeel nut hebt. Die hou je toch wel maar door er vanaf het begin zo in te duiken zal het aantal mensen dat zich direct al ingraaft wat kleiner zijn.

[ Voor 27% gewijzigd door Yucon op 29-03-2020 19:36 ]

[mulder]

Kijk ook naar implementatie van automatische build, test & release, dit is een leerzaam proces dat de vinger op de zere plekken legt en je meer zekerheid geeft bij het aanpakken van de applicatie.

Zorg dat je nieuwe functionaliteit gelijk onder architectuur brengt en testen bouwt, pas elders de boyscout rule toe.

Je bent maar met een paar man, maak het klein en kijk waar jullie nu het verschil kunnen maken en waarde kunnen leveren.

[ Voor 16% gewijzigd door mulder op 29-03-2020 22:51 ]

[P_Tingen]

De directie heeft al twee keer een externe check laten doen op de applicatie. De eerste keer ruim 2 jaar geleden en de laatste keer was vorig jaar. Daarbij werd gesteld dat maatwerk waarschijnlijk de beste optie is omdat dit het bedrijf het concurrentievoordeel heeft gegeven dat het nu heeft. De consensus lijkt hier ook wel een beetje te zijn dat men op maatwerk wil blijven. Het is duur om te ontwikkelen, maar licenties op SAP cs liegen er ook niet om. Wel werd in het onderzoek gemeld dat continuïteit op de langere termijn in gevaar kan komen omdat het moeilijker wordt om Progress-expertise te vinden. Vandaar dat vanuit de directie ook aan ons het verzoek is gekomen om daar eens over na te gaan denken. Juist omdat er nog geen haast mee is, kunnen we alle opties rustig overwegen.

De taal/database Progress zelf is het probleem niet; die wordt actief onderhouden. De progress database is rock-solid en met de 4GL programmatuur kun je bijna alles wat je wil, tot koppeling met .Net en OO-ontwikkeling aan toe. De ontwikkelomgeving is een aantal jaar geleden vernieuwd en is nu gebaseerd op Eclipse. En zelfs een mooie UI is er mee te maken.

De korte lijntjes vanuit de business met de it zijn zowel een zegen als een vloek; we kunnen hier zo ongeveer alles maken wat een klant wil en dat gebeurt dan ook, indien nodig door het pakket aan te passen. Uiteraard kan dat ook als je met een standaard pakket werkt, maar dan is het toch lastiger. Bij mijn vorige klant werkte men met Mfg/Pro, wat een standaard pakket is. Als je daar gekke dingen in wil doen, dan creëer je pas échte gedrochten. Wij kunnen - in ieder geval in theorie - de zaak netjes native in het pakket opnemen. En we zijn daar snel mee, want wijzigingen hoeven niet eerst door een change board of iets dergelijks.

In de reacties lees ik een groot aantal nuttige tips, waarvoor dank. Zoals gemeld is een 1:1 rewrite niet in scope, dat is een weg die je niet in wil gaan. Been there, done that, maar niet nog een keer. Van scratch af aan opnieuw beginnen is ook niet aantrekkelijk; we hebben een business te runnen en een nieuw pakket in één keer in gebruik nemen is vragen om problemen. Documenteren van bestaande code is - zie ik nu ook - zinloos. Het strangler pattern klinkt wel aantrekkelijk; het zou het probleem gradueel aanpakken. De vraag is dan echter nog steeds: waar naartoe?

Wellicht is het nuttig de processen in kaart te laten brengen door een extern persoon. Je moet dan alleen wel gaan bedenken wat je er mee gaat doen. Iemand invliegen, een of twee maand rond laten lopen en een fancy rapport laten maken is één ding, de informatie daaruit nuttig gebruiken is een tweede, want ook met het rapport in handen zit je nog steeds met de huidige omgeving.

Migreren naar een andere omgeving is een kwestie van lange adem. Zoals gezegd is Progress zelf het probleem niet. Mocht het bedrijf er in slagen de ondersteuning te borgen voor de langere termijn dan is er geen enkele reden er van af te stappen.

Een extra optie is om delen van het systeem te herschrijven. Er zitten complexe onderdelen in, waarbij we nu last hebben van keuzes uit het verleden. We zouden een aantal van dit soort pijnpunten er uit kunnen halen en daar een nieuw databaseschema voor maken, plus bijbehorende programmatuur.

Vooralsnog denk ik dat we sowieso kunnen starten met opschonen en versimpelen. Dat kan geen kwaad, welk scenario we ook gaan kiezen.

[Yucon]

Je hebt verschillende vormen van complexiteit. Heb je daar redelijk inzicht in? Soorten zijn bijvoorbeeld

- rare workflows: object a maakt onder bepaalde condities object b aan, en soms ook 3 instances van c maar dat zou onder andere omstandigheden ook d kunnen zijn
- enorm vertakte tabelstructuren
- zware logica. Uitgebreide calculaties zoals een custom made MRP of iets dergelijks

Die derde categorie leent zich bij uitstek om te isoleren. Van die andere twee is het zinvol om eens te bekijken of er een rationele vereenvoudiging is. Niet dat die stap bij #3 niet zinvol is, maar uit ervaring weet ik dat vereenvoudiging in zware algoritmes veel lastiger is dan het vereenvoudigen van een workflow of tabelstructuur.

Als je deze split gemaakt hebt kun je de zaak misschien wat makkelijker vergelijken. Een interessante case study kan ook Vopak zijn. Die zaten in hetzelfde schuitje als jullie en hebben dit naar grote tevredenheid met het low code platform OutSystems opgelost.

Nu claim ik niet dat dat platform perse de juiste oplossing voor jullie is. Maar de aanpak die er aan vast hing is in principe platform onafhankelijk en daar kun je best je voordeel mee doen.

https://www.emerce.nl/wir...erminal-management-system
https://www.outsystems.co...ild-large-custom-systems/

[P_Tingen]

Alledrie de soorten hebben we wel, en vast nog meer. Een die me zo te binnen schiet is van code/logica die op meerdere plaatsen voorkomt. Ik probeer dat nu via het scouting-principe aan te passen, maar dat is uiteraard een lange weg.

Daarnaast ook te grote units-of-work. Ik meldde al dat codeblokken veel te groot zijn. Daar bedoelde ik mee dat er programma's zijn die veel te groot zijn omdat alles er in is uitgeschreven. Ze doen meerdere dingen in plaats van maar één ding (de S uit SOLID). Ik pak dat aan door onderdelen eruit te halen en op te knippen in deelprocedures, maar het is vrij intensief omdat de logica die op meerdere plekken staat, uiteraard afzonderlijk van elkaar is onderhouden is en dus nét even iets anders is. Ook het oude framework is hier debet aan. Toen ADM-1 werd ontwikkeld begin jaren 90 waren de ideeën over hoe software moet werken anders dan nu. Ook zitten er waanzinnige constructies in het framework die nu niet meer hoeven omdat ze later native in Progress zijn geïmplementeerd.

Dank voor de link naar low-code. Misschien is dat inderdaad een optie. Wat onze huidige oplossing namelijk niet / matig heeft is een toegankelijkheid via iets anders dan een standaard pc. We hebben wel wat tablet-oplossingen, maar dat is ook weer op maat gemaakt. Algemene toegankelijkheid via mobiel of tablet is er niet. Dat zou een nieuw framework (wel of niet lowcode) voor ons op kunnen lossen.

[ Voor 14% gewijzigd door P_Tingen op 30-03-2020 15:37 ]

[DjoeC]

Verstandige stap om onderdelen aan te pakken maar blijf daarbij gefocussed op de processen waarvoor die code bedoeld is.

Duplicaatcode die "net even anders is" dient waarschijnlijk meerdere doelen en is dus niet makkelijk te dedupliceren. Bekijk waar je met de minste inspanning een hoog rendement kunt halen. Zorg ook dat je de "stijl" van de software handhaaft bij refactoring, niets is zo vervelend als een ontwikkelaar die met z'n eigen sausje aan de gang gaat. Alles wat je in de huidige codebase kunt verbeteren en meer inzichtelijk kunt maken helpt bij een toekomstige migratie die er ongetwijfeld aan gaat komen. Nogmaals: Blijf naar de processen kijken en probeer niet alles voor iedereen gelijk te zijn behalve bij echt generieke onderdelen.... KISS.

Hoewel de ideeen in de negentiger jaren veranderden durf ik met mijn basis in de zeventiger jaren en alles al zien komen en net zoveel al weer zien gaan: Fundamenteel is er niet veel nieuws onder de zon. Ontwikkelomgevingen hebben een kortere levensverwachting, software is een wegwerpartikel geworden. Tenminste voor de automatiseerders die - vaak ingehuurd - uurtjes willen schrijven. Iedereen kan het beter en als t fout gaat zijn ze niet meer te vinden. Realiseer je dat jouw software dienstbaar is aan het voortbestaan van het bedrijf. De bottomline van het primaire proces moet nooit uit het oog verloren worden. Een mooie applicatie maken waarna het bedrijf vastloopt lijkt me niet wenselijk.

Ik denk dat je dat door hebt en in die zin ben je te prijzen. Ik kom al meer dan veertig jaar heel andere automatiseerders tegen, sommigen zelfs met "omzetverantwoordelijkheid" (lees: Je krijgt een bonus als je meer mensen bij je opdrachtgever binnenroeit).

[gold_dust]

In mijn ervaring niet voor optie twee kiezen: ten eerste heb je de kans dat de nieuwe ontwikkelaar gillend de deur uitvlucht nadat hij de codebase heeft gezien, ten tweede zijn dit soort legacy systemen zodanig slecht geschreven en gedocumenteerd dat iemand die het systeem niet zelf geschreven heeft vaak niks meer kan betekenen. Als je ook maar iets refactored dan breekt de applicatie logica op andere plaatsen.

Een rewrite intern of door een competente(geen detacheerder) partij laten herontwikkelen is op de lange termijn de beste optie. Is die collega die bijna met pensioen gaat toevallig diegene die tientallen jaren geleden de schade heeft aangericht? Daar zou ik als management een stevig gesprek mee aangaan.

Ik heb dit soort bedrijven als ontwikkelaar ook een aantal keren meegemaakt en mijn advies is: run Forrest, run.

[P_Tingen]

gold_dust schreef op maandag 30 maart 2020 @ 20:39:
In mijn ervaring niet voor optie twee kiezen: ten eerste heb je de kans dat de nieuwe ontwikkelaar gillend de deur uitvlucht nadat hij de codebase heeft gezien, ten tweede zijn dit soort legacy systemen zodanig slecht geschreven en gedocumenteerd dat iemand die het systeem niet zelf geschreven heeft vaak niks meer kan betekenen. Als je ook maar iets refactored dan breekt de applicatie logica op andere plaatsen.

Gillend wegrennende ontwikkelaars zal wel loslopen denk ik. Er zijn genoeg ontwikkelaars die het juist leuk vinden een systeem te refactoren, dus dat valt mee. Het geheel is wel fragiel inderdaad. Een ontwikkelaar toevoegen klinkt leuk, maar ik heb zelf ook een paar maand nodig gehad om het systeem te leren kennen. En op veel onderdelen weet ik er nog weinig van.

Een rewrite intern of door een competente(geen detacheerder) partij laten herontwikkelen is op de lange termijn de beste optie. Is die collega die bijna met pensioen gaat toevallig diegene die tientallen jaren geleden de schade heeft aangericht? Daar zou ik als management een stevig gesprek mee aangaan.

Nog tien jaar werken noem ik niet "bijna met pensioen", laat hem het maar niet horen
En nee, hij is niet de oerontwikkelaar van het systeem, maar ook al was hij dat wel, dan zou ik nog geen stevig gesprek met hem voeren. Dat lost namelijk niks op en zorgt alleen voor een gedemotiveerde werknemer. Daarnaast wil ik van iedere tweaker hier wel eens programmatuur van 20 jaar geleden zien. En dan helemaal als die programmatuur 20 jaar lang gezorgd heeft voor een enorme voorsprong op veel van de concurrenten. Die code bevat de kennis van 20 jaar productie draaien. Helaas is die kennis best ingewikkeld geworden.

Ik heb dit soort bedrijven als ontwikkelaar ook een aantal keren meegemaakt en mijn advies is: run Forrest, run.

Ik vrees dat we het niet erg eens zijn vandaag Zoals gezegd zijn er ook ontwikkelaars die het geen probleem vinden om een oude applicatie weer op te kalefateren. Ondergetekende is er ook zo eentje. Nieuwbouw is leuk op zijn tijd, maar een lopende applicatie nieuw leven inblazen is minstens net zo bevredigend.

[mvrhrln]

* mvrhrln Kijkt even mee om de hoek,
Zitten met zelfde situatie. (gelukkig geen koppeling met productie als in fabricage). Wel door MGMT besloten om niet over te gaan naar een ERP(of -achtige) oplossing te gaan. Dus voorlopig alles zelf blijven bouwen. Collega en ik, willen nu (langzaam aan) de touwtjes voor ons strakker trekken. Echter huidige hoofdapp nog 5-10 jaar draaien heb ik in ieder geval een zwaar hoofd in.

gold_dust schreef op maandag 30 maart 2020 @ 20:39:
Ik heb dit soort bedrijven als ontwikkelaar ook een aantal keren meegemaakt en mijn advies is: run Forrest, run.

No offense, maar zo kom je nogal over als iemand die alleen maar de krenten uit de pap eet.
(kan me overigens je opstelling wel goed voorstellen hoor, denk ook nog altijd wel eens, run...run)

Probleem is denk ik bij veel (in huis ontwikkelaars bij niet IT bedrijf) het management aan hele andere dingen denkt dan de mooiste software, met de meest gelikte layout, gebouwd met de meest moderne en strakke ontwikkel technieken/tools etc. Die denken, als het draait en voorlopig blijft draaien is het goed.

[ Voor 48% gewijzigd door mvrhrln op 30-03-2020 21:00 ]

[P_Tingen]

DjoeC schreef op maandag 30 maart 2020 @ 15:34:
Duplicaatcode die "net even anders is" dient waarschijnlijk meerdere doelen en is dus niet makkelijk te dedupliceren.

In dit geval vaak wel. Ik ben een stuk of tien keer tegengekomen hoe een prijs moet worden opgezocht op basis van een contract. Kleine verschillen die in de loop van de tijd ontstaan zijn en die in het meest gunstige geval een klein verschil geven in edge cases. In dit specifieke voorbeeld kon ik het allemaal vervangen door 1 centraal programma dat op basis van een stuk of wat parameters de goede prijs bepaalt.

Hoewel de ideeen in de negentiger jaren veranderden durf ik met mijn basis in de zeventiger jaren en alles al zien komen en net zoveel al weer zien gaan: Fundamenteel is er niet veel nieuws onder de zon. Ontwikkelomgevingen hebben een kortere levensverwachting, software is een wegwerpartikel geworden.

Zeg dat laatste wel. Dat doet me zelf verdriet omdat ik denk dat software veel langer mee kan gaan als je het maar goed verzorgt. Ik zie zelf echter ook vaak dat er aan code geen waarde wordt gehecht. Ik loop dan iets korter mee dan jij kennelijk, maar in de ruim 25 jaar heb ik dat ook wel geleerd.

Realiseer je dat jouw software dienstbaar is aan het voortbestaan van het bedrijf. De bottomline van het primaire proces moet nooit uit het oog verloren worden. Een mooie applicatie maken waarna het bedrijf vastloopt lijkt me niet wenselijk.

Nee, zeker niet. Ik ben ook maar een voorbijganger in het leven van de applicatie. Mijn doel is om het voor het bedrijf beter te maken, zodat ze ook over 10, 20 en 30 jaar nog bestaan. Wellicht niet meer met deze code ,maar goed, de huidige code draait ook al 20+ jaar, dus waarom niet. [quote]

mvrhrln schreef op maandag 30 maart 2020 @ 20:56:
* mvrhrln Kijkt even mee om de hoek,
Zitten met zelfde situatie. (gelukkig geen koppeling met productie als in fabricage). Wel door MGMT besloten om niet over te gaan naar een ERP(of -achtige) oplossing te gaan. Dus voorlopig alles zelf blijven bouwen. Collega en ik, willen nu (langzaam aan) de touwtjes voor ons strakker trekken. Echter huidige hoofdapp nog 5-10 jaar draaien heb ik in ieder geval een zwaar hoofd in.

Toen ik begon was mijn collega al jaren het enige IT lid. Hij had zijn handen er vol aan. Toen ik kwam was er wat tijd (en noodzaak) om de processen van opleveren op orde te krijgen. Dat alleen al heeft al heel wat fouten verholpen en voorkomen. Dus mijn advies is: zorg dat je de omliggende processen op orde hebt (versiebeheer, opleveren, compileren, databasewijzigingen). Dan heb je in ieder geval goed gereedschap in handen.

[ Voor 20% gewijzigd door P_Tingen op 30-03-2020 21:05 ]

[mvrhrln]

P_Tingen schreef op maandag 30 maart 2020 @ 21:01:
[...]
Toen ik begon was mijn collega al jaren het enige IT lid. Hij had zijn handen er vol aan. Toen ik kwam was er wat tijd (en noodzaak) om de processen van opleveren op orde te krijgen. Dat alleen al heeft al heel wat fouten verholpen en voorkomen. Dus mijn advies is: zorg dat je de omliggende processen op orde hebt (versiebeheer, opleveren, compileren, databasewijzigingen). Dan heb je in ieder geval goed gereedschap in handen.

Idem hierzo, ben toendertijd x aantal jaar geleden, aangenomen om hem te ontlasten (zitten hier ook met 2 man). Een en ander is wel verbeterd maar er draait zoveel software (1 groot hoofdprogramma, en nog tig aparte programma's/services etc) dat er werk voor wel 10 man is. Alleen om alles te onderhouden en wat aan te passen hier en daar.

Paar keer geprobeerd om met MGMT alles goed te bespreken, maar iedere vernieuwing duurt maanden om van de grond te komen (is overigens iedereen mede schuld aan).

staan nu iedere week voor hetzelfde dilemma als jij nu doet. Krijg de langst zittende wel gedeeltelijk mee, maar niet genoeg om echt te "herstarten".


Wat ik nog even kwijt wou, is als je nu alles opnieuw maakt, gelikt, achile, scrum etc etc. Dan wordt er over 20jaar iemand aangenomen, die dan hetzelfde gaat posten als jij nu gedaan hebt

Ik denk dat er in principe geen ruimte meer is vandaag de dag voor zulke kleine ontwikkelteams voor zulke complexe omgevingen. Want uiteindelijk wordt iedere beetje omgeving complex, alleen al door de leeftijd en wat zicht dat meebrengt gedurende al de jaren.

[P_Tingen]

mvrhrln schreef op maandag 30 maart 2020 @ 21:11:
[...]
Wat ik nog even kwijt wou, is als je nu alles opnieuw maakt, gelikt, achile, scrum etc etc. Dan wordt er over 20jaar iemand aangenomen, die dan hetzelfde gaat posten als jij nu gedaan hebt

Ik denk dat er in principe geen ruimte meer is vandaag de dag voor zulke kleine ontwikkelteams voor zulke complexe omgevingen. Want uiteindelijk wordt iedere beetje omgeving complex, alleen al door de leeftijd en wat zicht dat meebrengt gedurende al de jaren.

Voor een groot deel denk ik dat je gelijk hebt, maar aan de andere kant: als je de zaken klein en simpel houdt, moet het lange tijd goed onderhoudbaar blijven. Dat soort dingen konden 20 jaar geleden ook, maar is toen niet gedaan omdat alles in een framework is gegoten. Dus misschien is de les wel om je essentiele kennis in kleine losstaande programma's / componenten te gieten om die vervolgens buiten je framework te houden. Dwz, wel aanroepen, maar op zo'n manier dat ook je framework over tien jaar is te vervangen. Want die zal eerder outdated raken dan je bedrijfskennis.

Maar goed, theorie en praktijk ....

[mvrhrln]

Mijn gedachten:
1. Shift-delete + restart
Gaat idd nooit werken. (zie Joel on software: https://www.joelonsoftwar...u-should-never-do-part-i/ )

2. Extra persoon erbij
Kan, maar dan niet voor de bestaande zaken, maar voor ondersteuning in de andere punten.
(het zouden dus diverse personen kunnen zijn, voor beperkte periode, evt inhuur)

3. Opstellen documentatie
Kan nooit kwaad, bij ons is de boel gedeeltelijk gedocumenteerd maar niet uniform.
Vraag is of het in kaart brengen vd bedrijfsprocessen puur alleen bij IT hoort.
(dus gedeeltelijke verantwoordelijkheid met andere afdeling(en))

4. Code-isolatie
5. Opschonen
6. Migreren naar ander platform

4,5,6 Zou je mooi kunnen combineren.
Onttrek bepaalde (losstaande functionaliteiten) uit bestaande code, ontwikkel deze in een nieuw platform.
Wel nadenken over communicatie oud & nieuw platform maar daar zijn genoeg mogelijkheden voor.
Zorg dragen dat het voor eindgebruikers zo lang mogelijk zo transparant mogelijk blijft.


Lastigst blijft om alle neuzen dezelfde kant op te krijgen denk ik, welke beslissing je ook neemt.
(en dan alle dus ook het management).

[farlane]

gold_dust schreef op maandag 30 maart 2020 @ 20:39:
In mijn ervaring niet voor optie twee kiezen: ten eerste heb je de kans dat de nieuwe ontwikkelaar gillend de deur uitvlucht nadat hij de codebase heeft gezien, ten tweede zijn dit soort legacy systemen zodanig slecht geschreven en gedocumenteerd dat iemand die het systeem niet zelf geschreven heeft vaak niks meer kan betekenen. Als je ook maar iets refactored dan breekt de applicatie logica op andere plaatsen.

Een rewrite intern of door een competente(geen detacheerder) partij laten herontwikkelen is op de lange termijn de beste optie. Is die collega die bijna met pensioen gaat toevallig diegene die tientallen jaren geleden de schade heeft aangericht? Daar zou ik als management een stevig gesprek mee aangaan.

Ik heb dit soort bedrijven als ontwikkelaar ook een aantal keren meegemaakt en mijn advies is: run Forrest, run.

Tjonge jonge, je hebt meegekregen dat die "rotzooi" al 20 jaar zorgt voor een goed lopend bedrijf? Arrogantie ten top dit ....

[TheGhostInc]

P_Tingen schreef op vrijdag 27 maart 2020 @ 13:49:
Het systeem werkt prima, maar onderhoud wordt wel 'een dingetje'. Wijzigingen die we door willen voeren duren steeds langer en zijn steeds moeilijker. We hebben het idee dat we een beetje vast beginnen te lopen in het pakket. Vandaar dat we op zoek zijn naar mogelijke oplossingen.

Ik mis een beetje de pijn, vooral vanuit de business. Waar willen ze heen in 5 tot 10 jaar? Zijn er nog zaken rondom die nog een keer opgelost moeten worden (Welk ERP of financieel pakket gebruiken ze bijvoorbeeld)

P_Tingen schreef op vrijdag 27 maart 2020 @ 13:49:
Een groot deel hiervan is terug te voeren op het in-huis onderhouden van het pakket. Dat maakt snelle aanpassingen mogelijk. Daarbij is in het verleden weinig aandacht besteed aan het opschonen van code en database ("je hebt er geen last van").

En daar heb je je probleem.
Er zijn bedrijven die elke 5 tot 10 jaar gewoon herbouwen omdat de problemen te groot worden in het oude platform en dan precies dezelfde problemen opleveren als ze de vorige keer hadden. En dan ligt het altijd aan de taal of 'het team dat de eerste opzet deed' of het gebrek aan, of in het verleden ....

Begin met de juiste cultuur neer te zetten en dan lossen de problemen zich een heel eind vanzelf op.

Want de collega die er nu zit schrijft dus geen unittests, geen documentatie en loopt veel te veel achter de business aan in plaats van de tijd te nemen 'het goed te doen'.
En in die juiste cultuur zou ik dan een tweede technologie plaatsen (met ontwikkelaar), waarvoor er genoeg ontwikkelaars zijn te vinden, en dan met een klein projectje naast de core beginnen. Bijvoorbeeld een portal voor de transporteurs. Het bedrijf doet dan ervaring op met de techniek, de ontwikkelaar krijgt niet meteen 10 jaar legacy op z'n dak en je kunt rustig aan het oude systeem opruimen en afbouwen.

Kijk ook goed hoe je al die inspanning een beetje 'sexy' kunt maken. Een super strakke Track&Trace is ook gewoon goed voor de business en een REST API aanbieden (die het gewoon omzet in een email) kan naar klanten een stuk professionaliteit uitstralen.
En als al die nieuwe onderdelen gewoon goed en degelijk zijn ontwikkeld, dan helpen die om het allemaal beter beheersbaar te maken. De nieuwe wereld neemt dan stukken van de verantwoordelijkheid over. Terwijl misschien het super specifieke PLC stuk nog 5 of 10 jaar doordraait, maar je klanten ondertussen in een los CRM zitten.

[P_Tingen]

mvrhrln schreef op maandag 30 maart 2020 @ 21:41:
Mijn gedachten:
1. Shift-delete + restart
Gaat idd nooit werken. (zie Joel on software: https://www.joelonsoftwar...u-should-never-do-part-i/ )

Haha, deze quote van Joel

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

Staat bijna letterlijk mijn tekst:

P_Tingen schreef op maandag 30 maart 2020 @ 20:53:
Daarnaast wil ik van iedere tweaker hier wel eens programmatuur van 20 jaar geleden zien. En dan helemaal als die programmatuur 20 jaar lang gezorgd heeft voor een enorme voorsprong op veel van de concurrenten. Die code bevat de kennis van 20 jaar productie draaien.

[mulder]

Dit vind ik een erg leuke podcast rond dit onderwerp: https://www.legacycode.rocks/

[P_Tingen]

mulder schreef op dinsdag 31 maart 2020 @ 07:30:
Dit vind ik een erg leuke podcast rond dit onderwerp: https://www.legacycode.rocks/

Klopt! Die volg ik inderdaad ook. Ook een leuke hierover is Maintainable

[Voutloos]

P_Tingen schreef op dinsdag 31 maart 2020 @ 07:16:
[...]

Haha, deze quote van Joel

[...]


Staat bijna letterlijk mijn tekst:

[...]

Die blog, en dan zeker die post, is zo bekend dat je het waarschijnlijk ook al een keer gelezen hebt.

Iemand die rooskleurig over de herbouwoptie praat kan je gewoon meteen negeren.

[Ryur]

P_Tingen schreef op maandag 30 maart 2020 @ 20:53:
[...]
Ik vrees dat we het niet erg eens zijn vandaag Zoals gezegd zijn er ook ontwikkelaars die het geen probleem vinden om een oude applicatie weer op te kalefateren. Ondergetekende is er ook zo eentje. Nieuwbouw is leuk op zijn tijd, maar een lopende applicatie nieuw leven inblazen is minstens net zo bevredigend.

Ik ben ook zo'n ontwikkelaar. Ik vind het helemaal niet erg om in 'oude/rommelachtige/stoffige' code te zitten werken om het te verbeteren. Dat vind ikzelf zelfs leuker dan die "Greenfield" projecten.

[gold_dust]

mulder schreef op dinsdag 31 maart 2020 @ 07:30:
Dit vind ik een erg leuke podcast rond dit onderwerp: https://www.legacycode.rocks/

Mender lol. Er is dus een naam voor deze bijzondere, zeldzame soort programmeur die het blijkbaar interessant vindt om de puinhoop van iemand anders op te ruimen. Ik kan me er weinig bij voorstellen, het gezicht van die vrouw in de link zegt ook voldoende.

Voor een oud legacy framework waar nooit aan onderhoud, documentatie of refactoring is gedaan is een rewrite inderdaad de enige oplossing. De echte vraag in dit soort gevallen is niet of een rewrite of refactoring maar hoe voorkom je in de toekomst dat zoiets opnieuw gebeurd.

[P_Tingen]

gold_dust schreef op woensdag 1 april 2020 @ 10:56:
[...]
Voor een oud legacy framework waar nooit aan onderhoud, documentatie of refactoring is gedaan is een rewrite inderdaad de enige oplossing. De echte vraag in dit soort gevallen is niet of een rewrite of refactoring maar hoe voorkom je in de toekomst dat zoiets opnieuw gebeurd.

Daarom zei ik dat het welllicht handig is om de logica los te trekken van het framework, zodat je dat relatief makkelijk kan vervangen. Het lijkt mij dat de BL niet zo snel verandert als de frameworks

[mulder]

gold_dust schreef op woensdag 1 april 2020 @ 10:56:
[...]

Mender lol. Er is dus een naam voor deze bijzondere, zeldzame soort programmeur die het blijkbaar interessant vindt om de puinhoop van iemand anders op te ruimen.

Ja ik vind het idd interessant om software die heel waardevol is voor de klant te verbeteren. Het is een grote uitdaging en leert je waarom bad practices bad practices zijn en good practices good practices. Iets nieuws bouwen kan iedereen en hoe ziet dat er over 10 jaar uit.

Ik kan me er weinig bij voorstellen, het gezicht van die vrouw in de link zegt ook voldoende.

Dit zegt vooral wat over jou.

[mvrhrln]

gold_dust schreef op woensdag 1 april 2020 @ 10:56:
[...]
De echte vraag in dit soort gevallen is niet of een rewrite of refactoring maar hoe voorkom je in de toekomst dat zoiets opnieuw gebeurd.

Probleem is dat management bij dit soort bedrijven dat soort zaken totaal niet boeit, als het maar werkt en doet wat het moet doen, de IT'ers staan toch al op de loonlijst, meestal al jaren, dus daar maken ze zicht niet zo druk om.

Plus, zoals ik zei, over 20jaar kan je je het weer afvragen, nieuwe inzichten, nieuwe technieken, nieuwe motivaties etc.

[Gomez12]

gold_dust schreef op woensdag 1 april 2020 @ 10:56:
[...]
De echte vraag in dit soort gevallen is niet of een rewrite of refactoring maar hoe voorkom je in de toekomst dat zoiets opnieuw gebeurd.

Dat voorkom je dus niet... Daarom is een rewrite ook zo fout, het enige middel is constant refactoren.

Met een rewrite ben je x tijd bezig zonder ook maar iets zinnigs op te leveren en over 5 jaar kan je weer een rewrite gaan doen, want de technieken zijn weer achterhaald.