Every executive wants a single number for developer productivity: lines of code, story points, commits, something to put on a dashboard and manage. The researchers who literally wrote the paper on this, including Nicole Forsgren of DORA fame, have a blunt answer: there is no such number, and chasing one does harm. Their SPACE framework is the antidote.
Key Takeaways
- The SPACE framework (Forsgren et al., 2021) argues productivity can't be captured by one metric (SPACE paper).
- It spans five dimensions: Satisfaction, Performance, Activity, Communication, Efficiency/flow (SPACE).
- Any single metric gets gamed and misses most of what matters, per Goodhart's Law.
- Measure a balanced few across dimensions, and pair them with judgment.
Why One Metric Fails
SPACE came out of research by Nicole Forsgren, Margaret-Anne Storey, and colleagues at Microsoft Research, GitHub, and the University of Victoria, published in ACM Queue in 2021 (The SPACE of Developer Productivity). Their central finding reframes the whole question: developer productivity is multidimensional, and any attempt to reduce it to a single number both misses most of what matters and invites gaming. Count lines of code and you get bloated code. Count commits and you get tiny meaningless commits. Count story points and you get inflated estimates. Each single metric, made a target, stops measuring anything real.
The Five Dimensions
SPACE says to look across five dimensions at once (SPACE framework). Satisfaction and well-being: are developers happy and healthy? Burned-out people aren't productive, and satisfaction predicts retention. Performance: outcomes, like reliability and quality, rather than raw output. Activity: counts of actions (commits, PRs), useful but the most easily gamed and least meaningful alone. Communication and collaboration: how well information and work flow across the team. Efficiency and flow: the ability to do work with minimal interruptions and delays.
The framework's discipline is to pick a small number of metrics across several of these dimensions, never just one, and never all from the easy-to-count "Activity" bucket.
| Tempting single metric | What SPACE adds |
|---|---|
| Lines of code / commits | Only "Activity", the weakest dimension |
| The four it ignores | Satisfaction, Performance, Collaboration, Flow |
| One gameable number | A balanced, harder-to-game picture |
A Concrete Version
A VP rolls out a dashboard ranking engineers by commits and lines of code. Within a month the metrics look busy and the org is worse: people split work into trivial commits, avoid the hard-to-measure but important work, and the best engineer, who deletes more code than she adds and mentors others, looks unproductive. A SPACE-minded approach would instead watch a few signals together, delivery outcomes, developer satisfaction, collaboration health, and flow, and see the real picture: the "low-commit" engineer is the one holding the team together.
The Honest Counterpoint
SPACE is not an argument against measuring, and "you can't measure productivity with one number" sometimes gets misread as "don't measure at all," which is worse. Measurement matters, and the DORA metrics are a great, specific example of useful signals. SPACE's point is narrower and practical: use several metrics across dimensions, treat them as insight rather than individual scorecards, and keep human judgment in the loop. The failure mode is the single-number dashboard; measurement itself is fine.
What This Means for Teams
SPACE is a caution against the seductive productivity dashboard, and it connects directly to Goodhart's Law and the reasons story points and velocity mislead. It also explains why we don't evaluate the engineers we place by a single proxy: real signal comes from looking at multiple dimensions of how someone works, which is what our vetting is built to do. Numbers inform the picture across several angles; no one number is the picture. See available engineers.
Frequently Asked Questions
What is the SPACE framework?
A model from 2021 research (Forsgren, Storey, et al.) for measuring developer productivity across five dimensions: Satisfaction, Performance, Activity, Communication, and Efficiency/flow. Its core claim is that no single metric captures productivity.
Why can't you measure developer productivity with one metric?
Because productivity is multidimensional, and any single number both misses most of what matters and gets gamed. Counting lines of code bloats code; counting commits produces trivial commits.
What should I measure instead?
A small, balanced set of metrics across several SPACE dimensions, never just "Activity" counts, treated as insight rather than individual scorecards, and paired with human judgment.
Is SPACE saying not to measure productivity?
No. It says measure across multiple dimensions rather than with one number. Measurement is valuable; the DORA metrics are a good example. The failure is the single-metric dashboard.
The Bottom Line
There is no single number for developer productivity, and chasing one produces gamed metrics and worse decisions. The SPACE framework's answer is to measure across five dimensions, satisfaction, performance, activity, communication, and flow, with a balanced few signals rather than one. Treat them as insight, keep judgment in the loop, and you get a real picture instead of a gameable score.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
