Wij ict'ers zijn een nijver volkje dat graag met de laatste trends meegaat. Onze honger naar nieuwe tools, nieuwe technieken of nieuwe oplossingen is nauwelijks te stillen. Altijd zijn wij op zoek naar mogelijkheden om het nog beter, schaalbaarder of flexibeler op te zetten. Die instelling is natuurlijk lovenswaardig, maar heeft ook een keerzijde.
Vanuit onze dienstverlening kom ik de laatste tijd steeds vaker in aanraking met legacy-code. Aan de code is vaak te herleiden uit welk jaar het afkomstig is. Vergelijk het met jaarringen van de doorgezaagde boomstam of de aardlagen waaruit de verschillende tijdperken van onze aarde te herleiden is. Een wandeling door een systeem lijkt vaak op zo’n reis terug door de tijd. 'Kijk, deze module komt uit jaar x, toen was dit framework net uit en erg populair.' Of 'hier heeft iemand volgens de standaards van vorig jaar zitten werken in een module die vijf jaar geleden opgeleverd is'. Leuk natuurlijk dat voortschrijdende inzicht en het toepassen van nieuwe producten en tools. Het resultaat is echter een systeem dat nauwelijks meer te onderhouden is, dat steeds moeilijker in productie te nemen is en zeer waarschijnlijk erg instabiel is.
Prima uitgangspunt
Hoe komt het toch dat wij ict'ers altijd denken dat alleen het nieuwste goed genoeg is. Volgens mij komt het voort uit een overtuiging om het nog beter te doen. Wat is er immers belangrijker dan het streven naar het nog beter helpen van de opdrachtgever. Een prima uitgangspunt natuurlijk en het is zeker een goed streven om bij te willen blijven in je vak en de ontwikkelingen op de voet te volgen.
Maar zou het ook niet verstandig zijn om ook eens te oogsten in plaats van telkens alleen maar te zaaien? Zou het niet verstandig zijn om alles uit een gekozen standaard te halen en pas als er onoverkomelijke problemen zijn de overstap te maken naar nieuwe aanpak. Aanvaard bij een overstap dan ook de consequenties om die nieuwe aanpak in het gehele systeem door te voeren en maak die stap pas als daar rechtvaardiging en goedkeuring vanuit de business voor is.
Gebruik van middelen
Probeer, voordat je gaat werken aan een systeem, je in te leven in de aanpak en gedachten van de oorspronkelijke ontwikkelaars ervan. Alleen als je de filosofie van de architect door hebt kun je de bestaande code echt begrijpen en uitbreiden. Kijk eens door de gebruikte programmeertaal of tools heen en zie het vakmanschap waarmee het systeem op gezet is. Ga daar niet zomaar met je eigen ideeën op in hakken, maar probeer zoveel mogelijk die oorspronkelijke gedachte door te zetten. Begrijp dat een goede software engineer boven de gebruikte technologie staat. Het mooie van ons vak zit in het gebruik van de middelen en niet in welke middelen er gebruikt zijn.
goede stellingname, mijn complimenten
Als je vers van school af komt, en daar met windows7 en de nieuwste microsoft SDK gewerkt hebt, kan het in schok zijn dat je in een omgeving terecht komt die werkt op windows XP en visual studio 2005. Echter, de schoolverlaters zien het alleen als een achteruitgang, en zijn (nog) niet in staat de achtergrond hiervan te doorgronden.
En ook die traditionele 3270 terminal (al dan niet geëmuleerd) haalt het qua gebruikersvriendelijkheid en gelikte schermen bij lange na niet bij een windows7 aero implementatie
Maar bedenk dan ook eens:
– de ICT problemen zoals ze regelmatig in dit blad verschijnen: hoeveel hiervan zijn er gerelateerd aan een mainframe en/of SNA netwerk?
– zou je met een gerust hart in een vliegtuig stappen als de boordcomputers hierin net zo stabiel waren als het besturingssysteem van je eigen PC?
– waar zou je het meeste vertrouwen in hebben: een medisch apparaat, werkend op windows XP, die al een aantal jaren stabiel is, of eenzelfde apparaat welke op de laatste windows7 draait en nog iedere maand gepatched moet worden om stabieler te worden
Kortom, nieuw is niet altijd beter !
Daarnaast kun je niet altijd alles “even” vervangen door nieuwere technologieën. Wanneer deze nieuwe technologie leidt tot zwaardere eisen aan je hardware kun je niet altijd “even” extra geheugen of diskruimte bij prikken. Misschien wel in dat ene servertje bij die ene klant, maar wat nu als er duizenden van jouw apparaten wereldwijd geïnstalleerd zijn? Dan wordt het ineens een hele kostbare operatie.
En in een real-time apparaat “even” een ander netwerk toepassen, of een ander moederbord, kan ook voor zeer onverwachte verrassingen zorgen.
Soms is oud zo slecht nog niet
(geldt, geheel terzijde, ook voor de leeftijd van ICT-ers 🙂 )
Het omgekeerde is echter ook waar : blijf niet te lang met oude standaarden en oude technieken werken.
Legacy is juist het resultaat van te lang aan oude standaarden vast te houden en een gebrek aan innovatie.
Het is dus niet zo dat blijven werken met oude standaarden en oude technieken beter is, dan innovatief te zijn.
Ik zou als tip meegeven: zorg dat er een lange termijn visie is en innoveer als het nodig is.
Dit voorkomt dat diensten legacy worden en het voorkomt ook dat er een wildgroei aan vernieuwingen plaats vinden, die de beheersbaarheid verslechteren.
@Guido
niet helemaal met je eens, maar e.e.a. is sterk afhankelijk van de omgeving waar je in werkt.
Dit hangt o.a. af van de (verwachte) levensduur van het product waarvoor de software bedoeld is (geldt vooral in de embedded sector)
Stel je voor dat je iedere 3 à 5 jaar nieuwe technieken zou willen toepassen op de software die een vliegtuig bestuurd. Dit zou betekenen dat je iedere 3-5 jaar alle vliegtuigen tijdelijk uit de bedrijfsvoering moet halen om te upgraden en te testen. De kosten wegen hier niet snel op tegen de baten
Een ander voorbeeld is de medische sector. In sommige landen wordt verwacht dat je het apparaat nog 10 jaar kunt onderhouden nadat je gestopt bent met productie. Optie 1 is vervangen door nieuwe apparaten. Kan, maar bedenk wel dat we hier praten over apparaten 6 of 7 cijfers voor de komma, waarvan er duizenden in het veld staan. Aardige kostenpost dus.
Optie 2 is het toch maar blijven ondersteunen en aanpassen indien nodig (bijv. vanwege nieuwe wettelijke eisen) op oude omgevingen, zoals VaX VMS of windows NT
Dat neemt niet weg dat deze sectoren innovatief zijn overigens. De nieuwste vliegtuigen zullen echt wel overgestapt zijn op andere platforms, en ook de medische sector is ondertussen al lang van windows NT af.
Moest ik even denken aan een systeem waarop ik onderhoud aan moest plegen. An sich zat het goed in elkaar maar qua code (plain C) was het zo ongeveer beste voorbeeld wat je aan jonge ICT studenten voor kon schotelen hoe het niet moest. En ook waarom men is gaan innoveren omdat soort misstanden te voorkomen.
Punt was wel dat de klant uiteindelijk na jarenlange dienst wel met de ouwe zooi door moest blijven gaan (er was nog maar 1 persoon van het eerste uur beschikbaar voor onderhoud) want een nieuwe variant van het systeem kwam simpelweg op nieuw bouw en dat zou iets van 2 jaar werk en qua schatting van een half miljoen kosten.
Dus soms kun je ervoor kiezen om door te blijven gaan met oude programma’s maar dat is alleen maar verstandig als er nog toekomst in zit.
@Guido, niet helemaal mee eens. Legacy code onstaat niet door het vasthouden aan (oude) standaarden, legacy code onstaat door af te wijken van de gebruikte standaard en een nieuwe toe te voegen (de jaarringen uit het artikel van Dick), waarmee je al het voorgaande bombardeert tot ‘legacy’.