Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.
Leer uit onze fouten, zodat jij ze niet hoeft te maken
Als developer sta je iedere dag op de eerste rij om digitale producten te ontwikkelen en onderhouden. Bij dat pionierswerk komen heel wat moeilijke beslissingen kijken, maar Axxes-consultant Hannes Lowette zorgt ervoor dat jij minder fouten maakt door te vertellen wat hij de voorbije jaren leerde.
Hannes Lowette, Head of Learning & Development bij Axxes, is al meer dan 15 jaar als developer actief en heeft vele watertjes doorzwommen. ‘Continu nieuwe frameworks, tools of programmeertalen leren kennen is leuk, maar kan ook voor de nodige frustraties zorgen als zaken niet werken zoals ze zouden moeten. Je wordt developer omdat je het tempo aangenaam vindt en je jezelf continu wil heruitvinden, maar botst vroeg op laat tegen muren’, zei Hannes op de Build Stuff-conferentie. Om te vermijden dat andere developers dezelfde fouten zouden maken, deelde Hannes op het podium in Litouwen zijn tips en tricks.
Kijk naar de technical fit
Sommige projecten waar Hannes op werkte liepen mis omdat men de verkeerde technologie koos om een bepaald probleem op te lossen. Zo was er ooit een project waarbij een systeem text files parste, maar niet alle data uit die tekstbestanden meteen gebruikt werd. Om die overige gegevens te bewaren koos men RavenDB, maar al snel bleek dat die oplossing zeer duur was en er veel tijd kroop in het onderhouden van het operating system en de database engine. Een kleine wijziging in het file format kon ervoor zorgen dat alles stuk ging. RavenDB had te veel features voor het specifieke probleem dat het team wilde oplossen. Azure Blob storage of Amazon S3 was in dit geval handiger geweest om die data te bewaren.
Om dit te vermijden, is het belangrijk dat je jezelf steeds deze vragen stelt:
Helpt mijn oplossing ons met dit probleem?
Wat zijn de verschillen met de alternatieven?
Is er een betere oplossing?
Is dit de eenvoudigste oplossing?
Hoe zit het met het kostenplaatje?
Wat is de onderhouds- en licentie kost?
Let op de red flags
Zelfs als er een technical fit is, kan het fout lopen. Dat ondervonden Hannes en zijn collega’s in 2014 bij een project waarbij de code helemaal met elkaar verweven was. Zowel de presentatie logica, business logica als de data access zaten allemaal in hetzelfde bestand. Door fout gebruik van bepaalde features, liep de applicatie trager dan zou moeten. Om die spaghetti wat te ontwarren deed het team beroep op Agatha, een framework dat vanuit technisch oogpunt ideaal was voor deze klus.
Toch ging er iets fout: Davy Brion, de man die Agatha creëerde en onderhield, verdween van de aarde. Meer zelfs: als het team in de documentatie was gedoken, hadden ze gezien dat dat al een jaar geleden was gebeurd. Zo was de oplossing al snel achterhaald, en vormde het een zwakke schakel in het project.
Het team had in dit geval kunnen kiezen voor MediatR, een open source alternatief dat dezelfde features heeft en door een actieve community onderhouden wordt. Om dat soort problemen te vermijden is het belangrijk dat je focust op vragen als:
- Wie onderhoudt de library? Is dit hun fulltime job?
- Werken die mensen er nog actief aan?
- Is de source code openbaar beschikbaar?
- Welk licentiemodel gebruikt men?
- Zijn ze net overgenomen door een ander bedrijf? Wat zijn de plannen?
Is iedereen in het team mee?
Een paar jaar geleden werkte Hannes samen met een paar collega’s aan een project dat al lang liep, en waarbij alle data in SQL Server bewaard werd. In een audit log moest bijgehouden worden wat er gebeurd was met de data die op de dashboards te zien was - een taak die je met EventStore zou kunnen uitvoeren.
Hoewel de technical fit er was en er geen grote risico’s waren, liep het alsnog mis. Het merendeel van het team was namelijk te onervaren als het op EventStore aankwam, waardoor ze te afhankelijk waren van de mensen die de kennis wel hadden. Als je een schaalbare oplossing voor een probleem zoekt is het belangrijk om op de skills van je team te letten door jezelf deze vragen te stellen:
Hebben we de kennis?
Als dat niet het geval is, is ze ergens beschikbaar?
Kunnen we het team opleiden?
Kan iedereen ermee werken?
Welke documentatie is er nodig
Door voor de gepaaste opleidingen te zorgen, af en toe samen code te schrijven en alles goed te documenteren kom je al een heel eind.
Leer hoe iets werkt
Technologie kan magisch lijken, maar het is belangrijk dat developers die magie wegnemen en weten waar ze aan of mee werken. Dat ondervond Hannes toen een collega hem aansprak over hoe “traag” Entity Framework was. Het probleem bleek niet bij Entity Framework te liggen - dat deed exact wat het moest doen - maar bij de manier waarop de collega het framework gebruikte. Er miste bijvoorbeeld een index, er werden teveel velden opgehaald, en debug gedrag werd aanzien voor productie performance. De collega wist simpelweg niet hoe Entity Framework concreet werkte en hoe hij het optimaal had kunnen inzetten. Als het magie lijkt, is het vaak gedoemd om te mislukken omdat je het waarschijnlijk op de verkeerde manier toepast. Daarom is het voor developers belangrijk om steeds onder de motorkap van frameworks of tools te kijken en volgende zaken na te gaan:
- Hoe werkt dit?
- Hoe is het gebouwd?
- Welke tools of concepten werden toegepast?
- Zouden we het in theorie zelf kunnen maken? Maak bijvoorbeeld een prototype of kijk in de source code als het open source software is.
- Kennen we de effecten van hoe we het toepassen?
Houd kuis in je tech stack
Vroeg of laat zal je als developer aan de slag gaan op een project met een zeer oude codebase. Collega’s komen en gaan, maar de codebase blijft bestaan. Net zoals je aan de ringen van een boom kan zien hoe oud hij is, kan je in zo’n geval vaak nagaan wanneer je voorgangers iets implementeren aan de hand van de gebruikte technologie: database engines, frameworks, libraries en praktijken. Zo krijg je een applicatie waarbinnen heel veel technische zaken gebruikt worden.
De applicatie blijft ongetwijfeld draaien, maar het onboarden van nieuwe collega’s duurt maanden. De oplossing? Trim your stack! Wanneer je nieuwe technologie toevoegt, moet je nagaan welke oude zaken je wil verwijderen. Er kruipt vaak tijd in het vervangen van oude stukken software of code, maar als je die tijd niet kan verantwoorden is het misschien geen slimme beslissing om de nieuwe technologie toe te voegen. Vraag jezelf steeds af:
Wat lossen we op door deze nieuwe technologie toe te voegen?
Hebben we het echt nodig?
Welk oud, gelijkwaardig alternatief hebben we?
Kan dat vervangen worden door het nieuwe?
Hoeveel moeite zou dat kosten?
Wat is de prijs om ze allebei te behouden, zowel op vlak van onderhoud als onboarding?
Doseer innovatieve oplossingen
Het tegenovergestelde van zo’n legacy project is een greenfield project waarbij je volledig vanaf nul kan beginnen. Hannes en zijn collega’s hebben ook dit scenario al geregeld meegemaakt. Een fijne situatie, ware het niet dat ze al een paar keer in een val trapten doordat ze te veel hippe frameworks en tools in één keer wilden introduceren.
Dan kan het fout lopen, want het team moet veel tijd steken in het aanleveren van de nieuwe tools en zal waarschijnlijk vaker moeten debuggen. Zelfs de meest eenvoudige business applicaties kunnen op zo’n moment grote vertragingen oplopen. De les van Hannes? Budgetteer extra tijd als je met nieuwe technologie werkt, en introduceer maar 1 innovatie per keer. Leg ook steeds de risico’s en meerwaarde uit aan je opdrachtgever.
Laat je architectuur steeds je problemen volgen, en niet andersom. Als je een klein team bent en aan een eenvoudige applicatie werkt, hoeft je architectuur dan ook niet nodeloos complex te zijn. Begin met de eenvoudigste oplossing voor je probleem en publiceer je applicatie. Daarna zal je al snel zien hoe gebruikers ermee interageren, zodat je nieuwe noden en problemen kan ontdekken. Dat itereren is belangrijk.
Het is verleidelijk om te kijken naar grote spelers als Netflix en net als hen bijvoorbeeld voor microservices te kiezen, maar doorgaans maak je als developer geen applicaties van dat kaliber. Microservices lossen een probleem op dat je tegenkomt wanneer je aan een bepaalde schaal zit, maar voor een eenvoudige applicatie is dat vaak niet het geval. Dit zijn gevallen waarin microservices wel nuttig zijn:
Wanneer je stukken onafhankelijk van elkaar wilt kunnen schalen, zodat je kosten en de snelheid in balans kunnen blijven.
Wanneer je verschillende features wilt uitrollen voor verschillende klanten.
Wanneer je meerdere technology stacks hebt die elk afzonderlijke delen van je applicatie bouwen.
Wanneer je conflicterende dependencies hebt.
De essentie
Na meer dan vijftien jaar in het vak, heeft Hannes heel wat lessen opgestoken door fouten te maken. Wil je die vermijden? Volg dan zijn raad: kijk eerst naar de technical fit van de oplossing voor het probleem dat je wil oplossen. Breng red flags in kaart en kijk of iedereen in je team mee kan. Neem de magie weg en leer hoe technologie werkt. Trim je stack en gooi overbodige zaken weg. En bovenal: zorg ervoor dat je architectuur je problemen volgt, en niet veroorzaakt.
Elke maand onze Insights in jouw mailbox? Schrijf je nu in!
Hannes Lowette
Head of Learning & DevelopmentHannes is a developer, a coach and a father of 3.
In .NET development, he has always had a passion for performance, databases, distributed systems and large scale applications. But most of all, he likes playing devil’s advocate in technical discussions by drawing the ‘it depends’ card.
As a coach, he is enthousiastic about knowledge sharing, personal growth and building careers. All this while keeping in mind that the pace needs to be sustainable.
In his free time, when he’s not building LEGO® castles with his kids, he likes to spend time building guitars, playing chess or poker, tasting whisky and doing all round geeky stuff.
You can occasionally find him on an afterparty stage at PubConf or with Dylan Beattie & the Linebreakers.
