Wij IT-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.
Hoe komt het toch dat wij IT-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.
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.
