Coss Solutions

Dat lijkt zo´n beetje de indruk te zijn die hedendaagse ontwikkelaars hebben van de vakmensen uit de 80er en 90er jaren. Althans, dat zeggen (of in ieder geval denken) deze mensen vaak….al klikkend, ervend of kopiërend en plakkend in Visual Studio met hun werkgeheugen van 1 Gb of meer…..

Elke keer als ik een uitspraak hoor die neigt in die richting bekruipt me een gevoel waardoor mijn nekharen recht overeind gaan staan. Hoe komt men tot dit soort waanideëen ? Tja, een blik op een stuk bronkode uit de 80er jaren, daar wordt menigeen niet bepaald vrolijk van. Cryptische veldnamen, onleesbare (voor leken) pseudocode en klaarblijkelijk talloze invloeden van buitenaf die werden afgevangen door de programmeur die verantwoordelijk was voor het stuk code.

Iemand die de luxe gewend is van moderne ontwikkelomgevingen doorziet niet snel wat er nu gebeurt in die code uit het welhaast prehistorische tijdperk van de grote, logge, starre, peperdure maar uiterst bedrijfszekere mainframe computers ….met soms maar liefst 64Kb (!) werkgeheugen.

Ik kan me niet aan de indruk onttrekken dat men dat vaak gewoon niet wil zien. Natuurlijk, er zijn systemen in elkaar gestoken op een manier die het uiteindelijke resultaat volstrekt on-onderhoudbaar maakte. Spaghetti alom….

Failliet

Ik draai nu al een jaar of twintig mee in de wereld van software ontwikkeling. En heb tot nu toe slechts één systeem onder ogen gehad dat voldeed aan de criteria die een systeem het stempel kunnen meegeven van AFBLIJVEN, NIETS AAN DOEN, KAARTENHUIS. Slechts één…En zelfs dat systeem werd nog jaren onderhouden en uitgebouwd. Kostte meer tijd, meer testwerk, meer geld en meer ergernis…Meer ergernis want geen enkele ontwikkelaar roert graag in de code van een andere ontwikkelaar. En zeker niet als die code als spaghetti wordt beschouwd. Maar toch…

Dat systeem is inmiddels overleden…Dat wel. Maar alle ontwikkelaars die er aan gewerkt hebben begrepen op een zeker moment hoe het in elkaar stak. En wisten om de spaghetti heen te programmeren, zodanig dat het systeem deed wat er van verwacht werd. Overigens, het systeem overleed toen de laatste gebruiker van het systeem failliet ging….Niet als gevolg van dat systeem, integendeel, het bewuste systeem heeft de curator de informatie verschaft die de daadwerkelijke oorzaak van dat faillissement blootlegde.

Y2K

Maar even terug naar al die andere systemen. Die systemen waarvan ik (of u) misschien niet vind dat ze een schoonheidsprijs verdienen in technisch opzicht. Ze werken fantastisch (anders waren ze er allang niet meer). Die systemen moeten naar een nieuwe omgeving worden gemigreerd…..Want dat mainframe wordt toch wel wat kostbaar in onderhoud….En degenen die dat mainframe goed kennen gaan binnenkort met pensioen…..Of gaan gewoon een volgende stap zetten in hun loopbaan…In beide gevallen een probleem.

Legt u het systeem, en uw vraag het systeem over te tillen naar een ander platform, voor aan een jonge ontwikkelaar dan zal hij in de eerste plaats niet gelukkig worden. Want dat is namelijk helemaal geen leuk werk vindt hij/zij, graven in die oude code…..Verder kan hij de klus wellicht niet eens aan omdat hij het systeem niet kent, en in zijn hart het systeem niet eens WIL kennen. Jonge ontwikkelaars voelen zich gebombardeerd tot archeoloog als zij voor een dergelijke taak worden gesteld.

Toch moet hij het gaan doen. En waar geen wil is, is de weg vol bobbels en kuilen….

Ter illustratie, ik ben betrokken geweest bij verschillende Y2K (Year 2k, ofwel jaar 2000) projecten. Een van deze projecten ging ongeveer als volgt :

Er moest een systeem Y2K bestendig worden gemaakt. Niemand van de oorspronkelijk groep ontwikkelaars kon of wilde de klus oppakken. Toen is er een plan van aanpak opgesteld dat het mogelijk maakte deze slag uit te laten voeren door een derde partij zonder dat de betrokken ontwikkelaars de applicatie hoefden te leren kennen.

Ik zal u de technische details besparen, maar ik heb gezien dat er 5 junior ontwikkelaars, 1 senior ontwikkelaar (gelukkig!) , 1 duur blauw pak van een bepaalde adviserende organisatie, en drie mensen van de opdrachtgever in kwestie zichzelf gedurende 5 (vijf !) werkdagen hebben gebogen over een simpel batch programma (MF Cobol) dat een bestandje las, één veldje in ieder record van dat bestand aftestte en afhankelijk van die test een ander veldje bijwerkte in datzelfde record waarna het betreffende record naar een nieuw bestand werd geschreven. In het record bevonden zich niet eens datumvelden……

Een project dat vele miljoenen guldens heeft gekost……Omdat niemand wist hoe het systeem werkte (Of wilde niemand dat weten ? Of durfde niemand de verantwoordelijkheid te dragen ?).

Uiteindelijk is het jaar tweeduizend probleem in dat systeem opgelost. Want dat was een reëel probleem. Alleen hoop ik voor de toenmalige opdrachtgever dat het systeem voor 2020 is vervangen. Zo niet dan sta ik als eerste op de stoep om die miljoenen zelf te gaan scoren…..In 2020 crasht er nog veel meer dan in het jaar 2000 gebeurd zou zijn zonder Y2K renovatie…..

Vakmanschap

Terug naar de kern van het onderwerp. Legacy systemen (legacy=erfgoed), zoals oude COBOL applicaties soms worden aangeduid, zijn niet ondoorzichtig. Het zijn geen bakken vol spaghetti, en het zijn geen systemen ontworpen en gebouwd door de eerder genoemde mongolen en randdebielen. Het zijn stuk voor stuk voorbeelden van scherp programmeren in een beperkte omgeving. Beperkt qua hardware, programmeertaal en besturingssysteem.

En eenieder die over de juiste ervaring beschikt, de juiste kennis heeft en niet te beroerd is zijn handjes te laten wapperen kan deze applicaties doorgronden. Niet in detail, dat hoeft helemaal niet, maar voldoende om een dergelijk systeem te huisvesten in een nieuwe moderne omgeving.

En daar hoef je niet eens Albert Einstein voor te heten.

Danny Maijer
COSS Solutions