Gepubliceerd op door

Hoe krijg je als directie duidelijkheid in de keuze van je developers?

Beste C.E.O., we moeten nu echt overstappen op Reambularbone.js! Dit zal alles op z’n kop zetten. Ik kan je niet precies vertellen hoeveel het gaat kosten, maar het is echt geweldig en het dubbele waard! Het hele team is er klaar voor. Het is zo veel beter dan het framework van vorige maand!

Je hebt als kapitein van jouw schip vol vertrouwen in de keuze van je technische stuurlui, en laat je leiden door de jaren lange ervaring van jouw developers. Een developer heeft echter andere, sterke, drijfveren die niet altijd in lijn liggen met jouw visie. Natuurlijk wil je jouw developer alle ruimte geven, maar je wilt verkeerde keuzes niet voelen in je portemonnee.

Frameworks

Een optie is om met een framework te gaan werken. Frameworks zijn stukken code die developers een flink eind op weg helpen. Ze bieden houvast en soms zelfs kant-en-klare onderdelen voor het bouwen van applicaties. Ze helpen je team op dezelfde manier te werken en maken het makkelijker om code uit te wisselen. Als er 1000 wegen naar Rome zijn, sluiten misschien 100 daarvan aan bij jouw bedrijf. Developer X wil weg 12 bewandelen en developer Y weg 25. Welke is het beste? Frameworks helpen deze opties te beperken. Dit wil niet zeggen dat er functionele mogelijkheden weggenomen worden; het vraagt in feite aan je hele team dezelfde routeplanner te gebruiken waardoor ze individueel dezelfde weg kiezen. Opeens kunnen developers elkaars code lezen, en begrijpen ze beter wat waar gebeurt. De inrichting van je applicatie zal bepaald worden door de architectuur (route) die vastgesteld is met/door het framework (routeplanner). Frameworks komen in alle smaken, en er lijkt om de week een nieuwe uit te komen. Developers vinden frameworks geweldig en ze willen ze allemaal uitproberen. En als je de developers hun gang laat gaan doen ze dat waarschijnlijk ook.

Voor de duidelijkheid

Ik ben zelf een developer, ik weet hoe het is om iedere maand een nieuwe wortel voorgehouden te krijgen. Vaak zijn het prachtige oranje wortels, maar soms zijn ze van plastic en kosten ze vooral geld en energie. Hoe zorg je er dan voor om samen toch het beste framework te kiezen voor jouw organisatie, of wil je liever zelf iets ontwikkelen? Welke vragen wil ik dat jij aan mij, de enthousiaste developer, stelt omdat ik er zelf niet gelijk aan denk? Hoe word jij mijn sparringpartner in plaats van de onzekere enabler?

Hoe lang kan ik inzetten op een framework, wat zijn de lange termijnrisico’s? Is er een lock-in?

Een framework keuze is geen software-afname. Het is niet zo dat je de komende 3 jaar gegarandeerd bent van een continue stroom van support voor een vast bedrag per jaar. Een framework gebruiken houdt in dat developers ook tijd moeten besteden aan het onderhouden en volgen van nieuws over het framework. Het kan voorkomen dat de maker van een groot framework ophoudt met de doorontwikkeling. Dat is niet direct een probleem, omdat je te allen tijde het framework kunt blijven gebruiken in de huidige vorm. Het is echter mogelijk om tegen een open einde aan te lopen. Het oplossen hiervan is dan op eigen risico.

Hoe vermijd je dit risico?

Je begint met research over de maker/aanbieder van het framework, daarnaast is het verstandig om te kijken hoe groot de development community is. Waar wordt het framework momenteel gebruikt en hoe “uniek” is de code die je schrijft voor dit framework? Vraag een developer eens een paar frameworks naast elkaar te leggen en te beoordelen op deze criteria. Bespreek vervolgens hoe heftig een overstap zou zijn van de ene naar de andere optie. Dit zou een goede indicator kunnen zijn van hoe groot het risico is en of er sprake is van een zogenaamde “vendor lock-in”. Dit is zo’n leuke developers-term, die aangeeft dat je vast zit aan een externe partij en geen ruimte hebt om over te stappen.

Wat heeft de inrichting van mijn team voor invloed op de keuze in frameworks? En hoe vertaalt zich dit naar de arbeidsmarkt?

Het ene framework biedt veel meer structuur en richting dan het andere. Een framework dat veel ruimte biedt in architectuur is vaak beter aan te sluiten op je huidige werkwijze. De keerzijde hiervan is dat je wel zelf die architectuur moet aanvullen. Dit houdt in dat je ervaren developers flink wat tijd moet geven om dit op te zetten (en in het gebruik ook onderhouden). 

Werk je veel met wisselende arbeidskrachten, zoals freelancers? Vraag je dan af of een framework met veel vrijheid in architectuur wel de juiste optie is. De keuzes die de developer maakt in het opzetten van de architectuur kunnen lastig overdraagbaar zijn als de maker daarvan niet aanwezig is.

Er zijn allesomvattende frameworks met kant-en-klare onderdelen. Die zijn makkelijker te gebruiken voor minder ervaren developers. Wanneer je het echter net iets anders wilt dan het framework toelaat, kan dit enorm veel tijd en energie kosten. 

Een handige vuistregel om te checken hoe goed een framework aansluit is om te kijken naar de de learning curve, waar genoeg over geschreven wordt door developers. Hoe meer steile stukken in de curve, hoe meer seniority dit framework vraagt van je talent pool.

Een goed framework haalt de kennis en ervaring van developers over de hele wereld in huis

Hoe afhankelijk ben ik van andere partijen?

Om hier iets van te vinden moet ik je eerst een paar andere onderwerpen uitleggen; waar bestaan deze frameworks uit en wie is de eindverantwoordelijke? Frameworks bestaan naast hun eigen code, uit kleinere onderdelen die andere developers en bedrijven delen. Stel je hebt een stukje code nodig dat de datum “9 Maart 2016” weergeeft als “09/03/2016”. Nu kun je als developer daar zelf een stukje code voor schrijven, maar je kunt dit stukje code ook opzoeken in een systeem. Met een eenvoudige handeling kan je developer dat externe stukje code koppelen aan jouw applicatie. Een bijkomstigheid hiervan is dat wanneer de originele maker van dat stukje code het aanpast of verbetert, dit ook in jouw applicatie meegenomen wordt. Je hebt altijd het nieuwste en beste stukje code. Net als de apps op je mobiel: die haal je eenmalig binnen en ze worden individueel up-to-date gehouden.

Dit is een klein voorbeeld, maar er staan complete applicaties en frameworks in dat systeem. Je voelt hem al aankomen, het is een vrij ingewikkeld spinnenweb waar alles steunt op de open source gedachte. Veel eigenaren van de kleine stukjes code geven je volledige toestemming om hun werk te hergebruiken of aan te passen, anderen willen een naamsvermelding. Een prachtig gedachtengoed, maar dit heeft ook een keerzijde. Het kan voorkomen dat iemand een stukje code weghaalt uit het systeem. Dit gebeurt gelukkig niet vaak, maar als het toch voorkomt kan dit tijdelijk flinke gevolgen hebben. Als advies wil ik daarom meegeven om op te letten hoe afhankelijk een framework is van één persoon of bedrijf, en hoe actief de bijdrages zijn. Idealiter is er veel meewerking vanuit de development community.

Hoe zit het met licenties en de voorwaarden? Kan ik alles zo maar gebruiken?

Zoals ik aangaf maken frameworks gebruik van kleine, vaak open source, onderdelen. Al die onderdelen worden net als het framework geschreven onder een softwarelicentie. Een paar bekende licenties zijn MIT, Apache of BSD. Hierin wordt vermeld hoe het gebruikt mag worden en onder welke voorwaarden. Laat de licentie goed door lezen door je advocaat of legal team voordat je vol inzet op een framework. Er zijn bijvoorbeeld frameworks die een softwarelicentie aanvullen met een clausule die concurrentie tegengaat, of zelfs het gebruik van het framework uitsluiten als je een rechtszaak hebt lopen tegen de aanbieder van het framework.

Er is een framework gekozen, maar je wilt straks ook een mobiele app. Wat nu?

Er zijn zelfs frameworks die de optie bieden om zowel op front-end (web) als op back-end (server) ingezet te worden, waarbij grote stukken code gedeeld kunnen worden. Dit kan een enorme impact hebben op de lengte van je release cycles.Wijzigingen hoeven niet op meerdere plekken gemaakt te worden. Voor de gebruiker kan dit inhouden dat pagina’s sneller laden, of dat je applicatie beter vindbaar is door zoekmachines. 

Enkele frameworks bieden zelfs de optie om te “exporteren” naar (native) mobile apps, maar dat is zelden plug-and-play. Hier zijn, net als met back-end, delen van je applicatie deelbaar en kunnen de verschillende teams in jouw organisatie binnen één codetaal samenwerken. Niet langer hoef je op zoek te gaan naar een specifieke iOS of android developer. Zoals met alles zijn er nadelen, maar probeer samen met je developer te kijken naar mogelijke uitbreidingen in de toekomst.

Een framework is en blijft één van je vele stukken gereedschap. Een schilder gaat een grote klus ook niet te lijf met enkel een blik verf.

De keuze van de developer hoeft niet slecht te zijn, maar het kan flink wat rust bieden voor zowel de developer als eindverantwoordelijke om sámen tot de definitieve keuze te komen. Smaken verschillen en wellicht kom je met de ene developer tot een andere conclusie dan met de andere. Het belangrijkste is echter dat jullie beiden het gevoel hebben een kant op te gaan die bij het bedrijf past. De developer is op de hoogte van jouw drijfveren en ook al spreken jullie niet elkaars taal, jullie willen allebei met een gevoel van zekerheid groeien.

Front-end Developer Marvin de Bruin Marvin is een allround Senior Developer met een achtergrond in interactie design en een ontembare interesse in innovatie. Hij heeft een goede 15 jaar ervaring als developer en was eerder de ‘head honcho’ bij een Amsterdams Internetbureau. Marvin laat zich omschrijven als gepassioneerd. Of als zowel koppig en ongeremd enthousiast, maar net hoe je het ziet. Naast een serieuze verslaving aan coding is Marvin nogal gefocust op eten. Beide dingen doet hij dan ook minstens dagelijks.