Legacy, last of lust? Dit moet elke ISV weten om relevant te zijn en blijven

Wat is legacy eigenlijk? Het antwoord dat je krijgt is afhankelijk van aan wie je de vraag stelt. Zo zeggen veel ontwikkelaars dat hetgeen ze opleveren na een dag al achterhaalde code is, omdat ze er langer dan 24 uur niet naar hebben gekeken. Op zich een mooie zienswijze: want hoe goed je ook je best doet, een dag later zou je het al beter kunnen doen en heb je dus (in de zienswijze van een gedreven developer) te maken met legacy.

Alleen is dat niet helemaal wat we bedoelen, voor ons, eveneens liefhebbers van IT, is legacy het volgende:

Niet kijken naar je code gedurende langere tijd

Je hebt code of iets anders softwarematigs opgeleverd en vervolgens ga je ervan uit dat het blijft draaien. In de praktijk betekent dit vaak dat je er niet meer naar kijkt tot het een probleem oplevert. Als de code of het programma vervolgens goed geschreven is en/of het is een kleine applicatie, dan is het op zich prima dat je er pas na twee jaar weer iets mee gaat doen. Dit is bijvoorbeeld het geval bij een inlogapplicatie.

Máár, als het geheel dan na twee jaar niet meer werkt, en de ontwikkelaar is inmiddels niet meer werkzaam bij je bedrijf en/of hij maakte gebruik van een techniek die niet meer bestaat, of het is niet zo goed beschreven allemaal: dan heb je wél een probleem. Dan heb je legacy die je tot last is.

Een ander voorbeeld: het ontbreken van duidelijke afspraken

Bedrijven hebben softwareontwikkelaars in dienst die vanuit hun rol als professional over het algemeen vooroplopen in het gebruik van nieuwe technieken. In de praktijk gebeurt het weleens dat verschillende ontwikkelaars in verschillende talen werken en daarbij verschillende frameworks gebruiken. Daardoor zijn er allerlei verschillende methodieken en platforms binnen die afdeling gebruikelijk geworden. Niet gebaseerd op heldere afspraken, maar vooral op persoonlijke voorkeur en de beschikbare kennis en kunde van de specifieke developer.

Wanneer je, laten we zeggen opnieuw na twee jaar, gaat kijken naar wat er gebeurd is binnen je IT-landschap dan kan dit zomaar een verontrustend beeld opleveren. Want wie werkt er nog binnen je organisatie? Heb je in beeld wie wat heeft gebruikt? In de praktijk zie je vaak dat er uiteindelijk zóveel verschillende technieken zijn gebruikt dat niemand meer precies weet hoe je bepaalde applicaties moet ondersteunen. Als niet meer helder is in welke taal, welke platforms et cetera zaken opgemaakt zijn en als het bovendien verouderd is, dan heb je te maken met zogenaamde nalatenschap. Wederom geen prettige weliswaar: het gebrek aan standaarden en patronen heeft legacy gecreëerd.

Legacy kan prima zijn

Legacy ontstaat vanzelf. De geweldige nieuwe en hippe oplossing van vandaag zal de legacy van morgen zijn. Per slot van rekening is legacy software, succésvolle software, anders was het wel een stille dood gestorven. Door aandacht te geven aan goede standaardisatie, én doordocumentatie en software verbetering een continu proces te laten zijn, voorkom je dat legacy een last voor de organisatie wordt. En wanneer er geen aandacht is besteed aan standaardisatie. Als een dergelijke nalatenschap binnen een organisatie goed beschreven is en de technieken ervan zijn bekend, ook bij de huidige ontwikkelaars, dan hoeft legacy geen last te zijn.

Onze tips

Ga vanaf dag één voor futureproof ontwikkeling, kies voor duidelijke naamgeving, ontwikkel standaarden en maak je terminologie zo herkenbaar mogelijk. Je zou, zoals je als bedrijf een huisstijlgids hebt voor je branding, waaronder je communicatie-, woordgebruik, schrijfstijl en marketinguitingen, dit ook in moeten richten voor je softwareontwikkeling, het beheer en álles wat daar verder mee samenhangt.

Onderschat onderhoud niet

Vaak zijn softwareontwikkelaars gedreven om nieuwe dingen te doen, maar soms vergeten ze om te onderhouden. Als je met een groep bent gaat dat niet goed. Je moet rekening houden met verloop. En als er geen algemene awareness is in die groep, dat beseft dat het gebrek aan beheer en/of duidelijke vastlegging, een probleem is of gaat worden, dan ontstaat er een probleem in late of nabije toekomst. Dit gebrek aan bewustzijn komt overigens niet voort uit kwade wil, maar het is veelal een gebrek aan ervaring en inzicht. Het gaat ook over het nemen van verantwoordelijkheid. En over zien wat er gebeurt: zo is het belang van een ontwikkelaar wezenlijk anders dan dat van de stakeholder bijvoorbeeld. Maar, hoe je het ook wendt op keert, het is uiteindelijk ook in het belang van de stakeholder van het bedrijf en van de eigenaar zelf dat de legacy goed beheerd wordt. Er moet een balans zijn tussen je richten op het schrijven van nieuwe code en het up-to-date blijven met nieuwe technieken enerzijds en het beheren van code (en andere processen en softwarematige zaken) anderzijds.

Risico op achterlopen

Maar de scheidslijn is dun. Als je te veel vasthoudt aan je eigen strategieën, loop je het risico dat je achterloopt. Wanneer dit achterstand te groot wordt, dan kun je op gegeven momenten niet anders dan je code opnieuw schrijven in plaats van deze aan te passen. Kortom, benoem bestaande applicaties en beheer deze volgens de levenscyclusmanagement-methode. Dit houdt in dat je voorkomt dat een afdeling een applicatie neerzet en er vervolgens niet meer naar omkijkt. Door samen te werken in dezelfde ontwikkelstraat en op dezelfde manier te bouwen, zorg je ervoor dat iemand anders het op dezelfde manier kan doorzetten als er een (ervaren) collega wegvalt. Zorg ook zeker dat er voldoende tijd is voor research en development. Zodat je je legacy borgt. Want ook dát hoort 100% bij futureproof software ontwikkelen.

Meer weten? Je bereikt ons rechtstreeks via 076 572 02 00 of via info@bergler.nl. Liever zelf aan de slag? Bekijk dan onze TechRadar, die je op zaken wijst die voor elk team van belang zijn. Het zijn stuk voor stuk onderwerpen om je verder in te verdiepen en alerts voor technieken die uitgefaseerd worden.