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.
