Developer Experience: meer dan een set tools

Voor developers is dit niet anders. De ervaring als developer, de Developer Experience 
(ook wel genaamd DevX of DX), is een bepalende factor in hoe leuk je je werk als 
developer vindt, de kwaliteit van je code en je productiviteit als team en/of organisatie. 
Sommigen gaan nog verder en correleren een goede DX direct met de snelheid waarmee 
projecten worden opgeleverd. Maar wat is een Developer Experience en hoe kan je deze 
verbeteren?

Meer dan een set tools

Het lastige aan de term DX is dat het veelomvattend is. Eigenlijk alles wat met de 
ervaring van de developer te maken heeft valt er onder. Je kan de DX op allerlei manieren 
verbeteren (en ook verslechteren). Tools zijn maar een klein deel van de ervaring. Goede 
documentatie die constant bijgewerkt wordt of een cultuur waarin je veilig terug kan 
vallen op een groep kundige collega’s zijn minstens zo belangrijk.

Tools kunnen het leven van een developer absoluut makkelijker maken. Te veel tools 
kunnen dan weer het tegenovergestelde resultaat hebben. Building blocks – die je veel 
tegenkomt in moderne organisaties - zijn een fantastisch middel om snel aan de slag te 
kunnen gaan en je als developer te kunnen focussen op het bouwen van mooie dingen. 
Diezelfde building blocks kunnen ook al het plezier uit je werk halen als ze niet goed in 
elkaar zitten, slecht gedocumenteerd zijn of totaal niet aansluiten op het project waar je 
aan werkt. Een slechte implementatie van een geschikte technologie kan meer kwaad 
dan goed doen.

Ook je voortbrengingsmethodiek heeft een grote impact op de DX. Een developer die 
maanden moet wachten op feedback op die ene feature waar hij/zij aan gewerkt heeft, 
zal daar niet blij mee zijn. Korte iteraties en korte feedbackloops zijn dus ook van 
invloed. Een goede DX is niet alleen belangrijk voor bestaande collega’s, maar ook zeker 
voor nieuwe collega’s. Het maakt onboarding een stuk makkelijker.

Het startpunt

We zijn het er op dit punt hopelijk over eens dat de DX iets is waar je als organisatie 
actief in wil investeren. Maar wat is dan het startpunt?

Als je een sterke DX wil leveren start je bij – je kan het je bijna niet voorstellen – de 
developer. Waar besteed een developer of een team tijd aan en waar wil de developer 
het liefst tijd aan besteden? Met welke tools, processen en investeringen kunnen we als 
organisatie de developer helpen zich te concentreren op het creëren van hoogwaardige 
software in plaats van te worstelen met technische obstakels?

Het antwoord op deze vraag kan (en zal) per team en developer verschillen. Door als 
team in kaart te brengen waar je DX verbeterd kan worden, kan je een gedragen 
verbeterplan maken.

Standaardiseer als team, niet als bedrijf

Het antwoord op wat een goede DX is en wie deze bepaalt, is waar het botst met de 
drang naar standaardisatie die je in veel organisaties tegenkomt.

Wat je als team en als organisatie niet wilt is dat er een te grote diversiteit in technologie 
en processen ontstaat. Om een paar voorbeelden te geven, het is niet goed voor je DX 
als documentatie op tig verschillende manieren is opgezet of zelfs op totaal 
verschillende plekken staat. Hetzelfde geldt voor het (automatisch) testen van software. 
Doe dit op een eenduidige manier zodat het toegankelijk is voor nieuwe collega’s en je 
het niet onnodig complex maakt voor je bestaande collega’s. De meeste developers en 
teams begrijpen dit heel goed, juist omdat zij degenen zijn die er last van hebben als er 
te veel diversiteit is.

Om me heen zie ik geregeld organisaties die sterk management-gedreven zijn. Van 
hogerhand wordt bepaald welke tools en technologieën ingezet worden en daarin is de 
noodzaak voor standaardisatie een veelgehoord argument. De angst van veel managers 
is een wildgroei aan broodjes speciaal, waarbij iedere klant op een unieke manier 
gecaterd wordt. Ik ben het (vaak) niet eens met die angst. Sterker nog, het druist direct in 
tegen het zelf-organiserende vermogen van Agile teams en het schaadt daarmee 
mogelijk de DX.

Ik betoog daarom dat standaardisatie (zeker in Agile organisaties) vanuit teams 
geïnitieerd moet worden. Doe je dit niet en ga je voor de teams bepalen welke 
standaarden ze moeten gebruiken? Grote kans dat het niet aansluit op je developers en 
het een negatieve impact heeft op je DX.

Wanneer doe je het goed (genoeg)?

Het antwoord is even simpel als flauw: nooit. Je ontkomt er niet aan dat de constante 
stroom aan technologische veranderingen je snel zullen inhalen als je de aandacht voor 
DX laat verslappen. De opkomst van generative AI en de trits aan assistants die 
developers in hun werk kunnen assisteren zijn hier een goed voorbeeld van.

De verbetering van de DX zou daarom altijd op de agenda moeten staan. Het is nooit af. 
Door teams aan te moedigen en de ruimte te geven zelf te bepalen hoe hun DX verbeterd 
kan worden, is de kans van slagen een stuk groter. En daar profiteert uiteindelijk 
iedereen van.