"Yes, you can measure engineering productivity — but only if you start from a clear goal, use a framework like SPACE to pick balanced metrics, and never reach for activity counts like lines of code"
Evidence from the Archive
Microsoft Research / DORA
Nicole Forsgren still receives monthly emails from leaders asking how to report lines of code as a productivity metric — the SPACE framework exists because of exactly this
Forsgren's research showed quality and speed co-vary: elite DORA performers ship smaller changes more often AND have lower change failure rates
Forsgren is the person who turned developer productivity from vibes into peer-reviewed science. Her core argument is that the real problem isn't whether measurement is possible but that most teams never define what they're trying to improve in the first place. She estimates 80% of the leaders she works with come back after months of effort with no shared definition of what 'developer experience' even means to them.
Her prescription is a hierarchy: DORA (four metrics) as the prescriptive 'quick check,' then SPACE as a framework for picking balanced metrics. The discipline SPACE forces is tension — pick at least three dimensions at a time so you don't over-optimize one thing and break another. She is emphatic about the single most common mistake: picking activity metrics like lines of code or commits as if they were productivity itself.
In Nicole's own words: "People have a hard time wrapping that around their heads because they kept picking things like number of lines of code, never pick number of lines of code... Number of pull requests, number of commits. And I was like, these are all activity metrics." (Explaining why she built SPACE — to stop leaders from defaulting to activity counts.)