Ontwikkelaarsproductiviteit meten in 2026: DORA, SPACE, DevEx en de DX Core 4

Vroeg of laat krijgt elke engineering director de vraag van een CFO of bestuur: "hoe productief is het engineeringteam, en levert de bezetting iets op?" Er bestaat geen eerlijk enkel getal om terug te geven, en de neiging om er een te verzinnen is precies hoe meetprogramma's giftig worden. Maar "dat kun je niet meten" is evenmin een acceptabel antwoord - dan laat je het gesprek over aan wie bereid is de verkeerde dingen te tellen. Dit is een gids voor het meten van ontwikkelaarsproductiviteit in 2026 zoals ervaren teams het werkelijk doen: met een klein systeem van elkaar aanvullende raamwerken - DORA, SPACE, DevEx en de DX Core 4 die ze verenigt - in plaats van een ranglijst.

Diagram van engineering-productiviteitspijlers: snelheid, effectiviteit, kwaliteit en bedrijfsimpact, van leveringsmetrieken tot ontwikkelaarservaring

Kun je ontwikkelaarsproductiviteit echt meten?

In augustus 2023 publiceerde McKinsey "Yes, you can measure software developer productivity" en ontketende daarmee een van de scherpste debatten die het vakgebied heeft gekend. Kent Beck en Gergely Orosz antwoordden met een gedetailleerd tweedelig weerwoord, en hun kernbezwaar is het bezwaar dat je in elk meetinitiatief moet meenemen: McKinsey optimaliseerde voor het meten van inspanning en output in plaats van uitkomsten en impact. Zoals zij het stellen: "the earlier in the cycle you measure, the easier it is to measure. And also the more likely that you introduce unintended consequences" (Pragmatic Engineer, 2023).

Dat is geen filosofische muggenzifterij. Beck beschrijft hoe output-achtige scores bij Facebook werden "opgerold" totdat directeuren druk uitoefenden op managers en managers met individuele medewerkers onderhandelden over betere cijfers - de metriek verslond het gedrag dat ze moest observeren. Het eerlijke antwoord op "kun je het meten?" is dus: ja, op het niveau van teams en systemen, als je meerdere dingen meet die elkaar in balans houden en je er nooit een individuele ranglijst van maakt. Zodra een enkele metriek een doel wordt, neemt de wet van Goodhart het over en meet ze niets werkelijks meer.

Waarom regels code en commit-aantallen misleiden

De metrieken die het makkelijkst uit een versiebeheersysteem te trekken zijn - regels code, commit-aantallen, pull requests per ontwikkelaar - zijn juist de metrieken die het minst onthullen. Ze meten activiteit, geen waarde, en zijn triviaal te manipuleren: een ontwikkelaar die te horen krijgt dat het aantal PR's telt, splitst een wijziging op in vijf. Erger nog, ze straffen precies het werk waar je meer van wilt. 2.000 regels dode code verwijderen, een junior door een lastige bug loodsen, of een dag besteden aan het wegwerken van een deployment-knelpunt tellen allemaal als lage output terwijl ze onevenredig veel waarde creëren. Elk raamwerk gebouwd op ruwe activiteitstellingen meet beweging en noemt dat vooruitgang.

DORA, SPACE en DevEx: wat elk raamwerk meet

Drie op onderzoek gebaseerde raamwerken domineren de serieuze praktijk, en ze beantwoorden verschillende vragen in plaats van te concurreren:

DORA meet leverprestaties op systeemniveau: deployment-frequentie en doorlooptijd van wijzigingen (doorvoer) in balans met het faalpercentage van wijzigingen en de hersteltijd na een mislukte deployment (stabiliteit). Het is de scorekaart van de sector voor "hoe goed leveren we uit," onderbouwd door een van de grootste doorlopende onderzoeken in het vakgebied.
SPACE, gepubliceerd door Nicole Forsgren en collega's, is een bewuste correctie op denken in één metriek. Het omvat vijf dimensies - Satisfaction (tevredenheid en welzijn), Performance, Activity, Communication en samenwerking, en Efficiency en flow - en de kernregel is dat je over meerdere dimensies tegelijk moet meten en productiviteit nooit tot één getal mag reduceren.
DevEx, uit dezelfde onderzoekslijn (Abi Noda, Nicole Forsgren, Margaret-Anne Storey en Michaela Greiler, 2023), verschuift de blik naar de dagelijkse ervaring van de ontwikkelaar - de wrijving die bepaalt of getalenteerde mensen hun werk daadwerkelijk gedaan krijgen (InfoQ, 2023).

DORA vertelt je iets over de output van het leversysteem. SPACE herinnert je eraan ook naar de menselijke en samenwerkingsdimensies te kijken. DevEx verklaart waarom de cijfers bewegen. Samen gebruikt trianguleren ze; los gebruikt heeft elk een blinde vlek.

Wat meet DevEx eigenlijk? Feedbackloops, cognitieve belasting, flow

DevEx destilleert een grote verzameling sociotechnische factoren tot drie dimensies waar engineeringleiders direct op kunnen sturen:

Feedbackloops - de snelheid en kwaliteit van reacties op de acties van een ontwikkelaar. Trage CI, wankele tests en dagenlange review-latentie zijn allemaal lange feedbackloops die elke wijziging stilletjes belasten.
Cognitieve belasting - de mentale inspanning die nodig is om iets gedaan te krijgen. Uitdijende services, gebrekkige documentatie en verwarrende interne tooling verhogen die; een goed gebouwd intern platform met gebaande paden verlaagt haar.
Flow - het vermogen om met diepe focus te werken. Versnipperde agenda's, onduidelijke prioriteiten en constante onderbrekingen vernietigen die.

Het argument om dit serieus te nemen is economisch, niet sentimenteel: de DevEx-auteurs merken op dat "even a small reduction in wasted time, when multiplied across an engineering organization, can have a greater impact on productivity than hiring additional engineers." De markt heeft het opgemerkt - Gartner constateerde dat 78% van de onderzochte organisaties een formeel developer-experience-initiatief heeft opgezet of gepland (InfoQ, 2023).

Wat is de DX Core 4?

Het praktische probleem met DORA, SPACE en DevEx naast elkaar draaien is dat stakeholders verdrinken in metrieken en dat geen twee teams op dezelfde manier meten. De DX Core 4, eind 2024 gepubliceerd door Abi Noda, Laura Tacho, Margaret-Anne Storey en Michaela Greiler, is een poging dat op te lossen door DORA, SPACE en DevEx te bundelen in vier tegen elkaar wegende dimensies (DX, 2024):

Snelheid - hoe snel werk in productie belandt (doorvoer).
Effectiviteit - hoe goed ontwikkelaars hun werk daadwerkelijk kunnen doen, grotendeels ontleend aan DevEx.
Kwaliteit - de stabiliteit en betrouwbaarheid van wat er wordt uitgeleverd.
Impact - het deel van de engineeringinspanning dat echte bedrijfswaarde bereikt in plaats van sleurwerk.

De ontwerpgedachte is de tegenwicht-werking: je kunt snelheid niet manipuleren zonder dat effectiviteit, kwaliteit en impact de prijs blootleggen. DX meldt dat het raamwerk is uitgerold bij meer dan 300 tech-, financiële, retail- en farmaceutische bedrijven, met uitkomsten waaronder een toename van 3% tot 12% in engineering-efficiëntie en een toename van 14% in R&D-tijd besteed aan feature-ontwikkeling. Voor een gereguleerde Benelux-organisatie is dat laatste cijfer het cijfer om te verinnerlijken: de meeste productiviteitswinst komt niet van mensen harder laten werken, maar van het terugwinnen van tijd die verloren gaat aan wrijving en ongepland werk.

Maakt AI ontwikkelaars productiever?

Dit is inmiddels de eerste vraag die bestuurders stellen, en de data manen tot voorzichtigheid. Het DORA-rapport van 2025, gebaseerd op bijna 5.000 respondenten, stelde vast dat 90% van de professionals AI op het werk gebruikt en dat de meesten productiviteitswinst rapporteren - maar het typeert AI ook als "the great amplifier" die versterkt welke discipline een team al heeft (Google Cloud / DORA, 2025). De data van het jaar ervoor was botter en koppelde AI-adoptie aan een meetbare daling in leverstabiliteit (InfoQ, 2024). De les voor meten is direct: individuele claims van "AI maakte mij sneller" zijn op zichzelf waardeloos. Als gegenereerde code het aantal wijzigingen opdrijft terwijl het stilletjes de stabiliteit uitholt, vangt alleen een gebalanceerd raamwerk - snelheid getoetst aan kwaliteit, activiteit getoetst aan uitkomst - die uitruil op voordat die de productie bereikt.

Hoe je begint zonder je team te ontregelen

Drie principes scheiden een nuttig programma van een schadelijk. Ten eerste: meet altijd over tegen elkaar wegende dimensies; een enkel kopgetal is een prikkel om te manipuleren, geen meting. Ten tweede: verbeter tegen je eigen historie, niet tegen een externe benchmark - het doel is je eigen ontwikkeling, geen plek op de ranglijst tegenover bedrijven met andere randvoorwaarden. Ten derde: combineer systeemmetrieken met door ontwikkelaars gerapporteerde ervaring: de grootste kloof in de meeste organisaties zit tussen wat leiders aannemen dat de wrijving is en wat engineers elke dag daadwerkelijk tegenkomen, en een kwartaal-DevEx-enquête dicht die sneller dan welk dashboard ook. Houd de resultaten op team- en systeemniveau, rangschik nooit individuen, en behandel de cijfers als het begin van een gesprek in plaats van een oordeel. Zo gemeten stopt ontwikkelaarsproductiviteit een stok te zijn en wordt het wat het hoort te zijn: een kaart van waar de wrijving zit, zodat je die kunt weghalen.