Waarom bijna iedereen developer productivity verkeerd meet

Ik was een keer bij een klant, een middelgrote organisatie, eigen cloud, eigen platform team. De CTO wilde graag weten hoe productief zijn developers waren. Dus had hij een dashboard laten bouwen. Het toonde commits, PR doorlooptijden, story points per sprint. Een mooie groene grafiek.

Ik zei: "Wat meet je hier precies?"

Hij wees trots naar de lijn die omhoog ging. "Productiviteit. We stijgen."

Na wat doorvragen bleek: developers waren story points gaan opblazen. Ze wisten dat management keek. Wie een 3-punter een 5 gaf, kreeg geen vragen. Drie weken later had iedereen een hogere velocity, maar de echte doorlooptijd van features was niet veranderd. De groene lijn was volledig losgezongen van de werkelijkheid.

Dit is geen incident. Het is de standaard.

De meetindustrie is groot, maar meet verkeerd

De afgelopen tien jaar zijn er drie grote frameworks opgestaan om developer productivity te meten: DORA, SPACE en DevEx. Ik gebruik ze alle drie, maar ik zie ook waar ze stuk gaan.

DORA (Deployment Frequency, Lead Time, Change Fail Rate, MTTR) is de beste van het stel omdat het systeem meet, niet de persoon. Maar DORA is een lagging indicator. Je ziet pas achteraf dat het fout ging. Je weet niet waarom.

SPACE (Satisfaction, Performance, Activity, Communication, Efficiency) is de reactie op die beperking. Het voegt de menselijke dimensie toe. Maar zoals de onderzoekers zelf toegeven: de 'Activity'-dimensie wordt het meest gebruikt en het meest misbruikt. En precies die dimensie trigger je met management dashboards.

DevEx (Feedback Loops, Cognitive Load, Flow State) is wat mij betreft de meest volwassen benadering. Het meet de causale inputs, niet wat er gebeurde, maar wat productiviteit mogelijk maakt. Snelle feedback, lage cognitieve load, ononderbroken focus. Dat is waar het om draait.

Maar hier is het probleem: geen van deze frameworks behoedt je voor Goodhart's Law. Zodra je er een KPI van maakt, gaat het systeem Het Spel spelen.

De AI-paradox: sneller voelen, langzamer zijn

Toen GitHub Copilot in 2022 uitkwam, claimde Microsoft dat developers 55% sneller waren. Dat klopt, voor een geïsoleerde taak in een lege repository, een HTTP-server in JavaScript. De perfecte labomstandigheid.

In juli 2025 publiceerde METR een studie die het tegendeel bewees: ervaren open-source developers die AI gebruikten waren 19% langzamer. En het bizarre? Ze voelden zich 20-24% sneller.

Dit is geen technisch probleem. Het is een perceptieprobleem. AI versnelt het typen, maar voegt nieuwe cognitieve overhead toe, prompts schrijven, context beheren, gegenereerde code reviewen die niet helemaal deugt. Het flow-gevoel dat developers ervaren is de afwezigheid van typwerk, maar de totale doorlooptijd neemt toe in complexe, realistische scenario's.

Voor mij betekent dit: stop met productiviteit meten op basis van 'developer happiness'. Tevredenheid is geen proxy voor output.

Wat ik nu anders doe

Ik adviseer organisaties om drie dingen te doen:

1. Meet het systeem, niet de persoon. DORA-metrics op teamniveau, anoniem geaggregeerd. Weg met individuele dashboards.

2. Focus op DevEx, niet op activity. Investeer in wat productiviteit mogelijk maakt: snellere builds, betere documentatie, code-review binnen 24 uur, meeting-vrije blokken. De DORA-metrics volgen vanzelf.

3. Test AI-tools in jouw eigen context. De Microsoft-studie is irrelevant voor jouw codebase. Doe een METR-achtige pilot: geef een team AI, een team niet, en meet het echte verschil in jouw repo's, met jouw developers, over jouw tickets.

De grootste fout die ik zie is dat CTO's miljoenen investeren in AI-tooling op basis van surveys en 'hours saved'-claims. Ze meten het verkeerde, op de verkeerde manier, en ze weten het niet eens. Goodhart leeft, en hij eet jouw dashboard.

Praktisch: hoe begin ik morgen?

• Stop met story points koppelen aan performance reviews.
• Verwijder individuele commit-counts uit ieder dashboard.
• Vervang 'developer productivity' door 'team experience' in je vocabulaire.
• Begin één ding te meten dat er echt toe doet: de gemiddelde tijd van ideatie tot productie voor een feature.

De rest is ruis.

---

Tabellen uit het originele artikel

Tabel 1

Table 1: Comparative Analysis of Modern Productivity Frameworks
Attribute	DORA	SPACE	DevEx (Developer Experience)
Primary Goal	Measure system-level DevOps performance (throughput & stability).	Provide a holistic, multi-dimensional model of productivity.	Measure the causal inputs to productivity by focusing on the developer’s human experience.
Core Metrics	4 Keys: • Change Lead Time • Deployment Frequency • Change Fail % • Time to Restore (MTTR) ^14	5 Dimensions: • Satisfaction • Performance • Activity • Communication • Efficiency ^21	3 Pillars: • Feedback Loops • Cognitive Load • Flow State ^26
Unit of Analysis	Team / System	Individual / Team / System	Individual’s Interaction with System
Primary Data Type	System Telemetry (Quantitative)	Hybrid (Quantitative System Data + Qualitative Surveys)	Perception Surveys (Qualitative) + System Telemetry (Quantitative) ^27
Key Limitation	A lagging indicator. Lacks context and the human element.^16	High-level and complex; can be difficult to operationalize.	Relies heavily on subjective developer perception data (which can be unreliable).

Tabel 2

Table 2: Methodological Deep-Dive: GitHub vs. METR Productivity Studies
Attribute	GitHub Copilot “55% Faster” Study (2022)	METR “19% Slower” Study (2025)
Participant Profile	95 Professional Developers ^33	16 Experienced Open-Source Developers ^36
Task Type	Self-Contained, Greenfield Task ^33	Real-World Issues (Bugs, Features, Refactors) ^36
Codebase	New / Empty (Implementing an HTTP Server) ^33	Large, Mature, Familiar Repositories (avg. 22k+ stars) ^36
Primary Metric	Task Completion Time	Issue Completion Time
Key Quantitative Finding	**55% **Faster with AI ^33	**19% **Slower with AI ^35
Key Qualitative Finding	Developers felt more in flow and productive ^33	Developers felt 20-24% faster, despite being slower ^38

Tabel 3

Table 3: Compliance Checklist for “High-Risk” AI Employment Systems (EU AI Act Framework)
Requirement (Art. 8-17)	Action Item for AI Developer Analytics
Risk Management System	Conduct a Fundamental Rights Impact Assessment (Art. 27) before deployment to identify risks of discrimination, surveillance, and chilling effects on collaboration.
Data and Data Governance	Audit all historical training data for biases (e.g., gender, race, age, neurodiversity, non-traditional backgrounds).^62 Ensure data is “relevant… and complete.”
Technical Documentation & Record-Keeping	Maintain full “black box” records. Deployers must be able to log all inputs, outputs, and intermediate logic for any AI-assisted performance decision to prove compliance.
Transparency & Provision of Information	Disclose to developers exactly what is being measured, how the AI is processing it, and what it is used for (Art. 13). Ban “hidden” monitoring.
Human Oversight	Mandate that all performance-related decisions are made by a human manager, using AI data as only one input. Disable any “automated scoring” or ranking features.^62
Accuracy, Robustness, Cybersecurity	Validate the actual (not perceived) accuracy of the tool. If the tool is 19% wrong (per METR), it fails the “accuracy” test and must not be used for high-stakes decisions.

Video: Developer Productivity Framework

Developer Productivity Framework

Video: Developer Productivity Framework

Developer Productivity Framework