The SPACE of developer productivity: There's more to it than you think

Jul 3, 2023

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler | 2021 | Paper

Summary

I read the devex paper by a few of the same team recently so I went back and read the orignal SPACE paper as well. This one is a bit more famous, it was widely syndicated on publication in 2021 and the ideas behind SPACE have seeped into the general engineering consciousness over the past couple of years.

The paper sets out it’s stall early on. We’ve struggled to measure engineering productivity up to now - why is that? What we need to do differently is take a whole system view of producitivity, and that system includes the perception and feelings of the developer themselves; productivity and satisfaction are interconnected. Making software is a messy, human business, and solving complex problems requires a team, so we should look at the producivity not just of the individual, but also the team and the wider organisation. The fact that we’re working within multi-level sytems means that managing to one metric just won’t work. We need a framework that guides us to choose metrics that measure producivity along multiple dimensions and at the different levels. That framework is SPACE: satisfaction and well-being, performance, activity, communication and collaboration and efficiency and flow.

## Myths of developer productivity The paper lists a few producivity related myths up front that capture much prior work in the field. This helps to contrast using a whole system standpoint to the alternatives. I think the useful point is not that you should avoid using these datapoints, but that they need to be considered as just one part of the puzzle.

  • Productivity is all about developer activity (it’s a complex system, you can’t just focus on measuring the easy, visible stuff like commits, prs, LoC, code reviews)
  • Productivity is only about individual performance (development is a team sport)
  • One productivity measure is all that is needed (development is a complex system; mosaic theory applies)
  • Productivity measures are only useful for managers (if the measure is personal, anyone can take accountability for improving their own productivity)
  • Productivity is only about engineering systems and tools (these are important, but human factors matter too)

SPACE: a framework for understanding developer productivity

SPACE nudges us to think about productivity using a much bigger canvas, it also encourages us to think carefully about exactly what we’re measuring and why. It suggests thoughtfully choosing metrics across five different dimensions: satisfaction and well-being, performance, activity, communication and collaboration and efficiency and flow.

### Satisfaction and well-being Satisfaction is how fulfilled developers feel with their work, team, tools, or culture; well-being is how healthy and happy they are, and how their work impacts their well-being. Productivity and satisfaction are correlated, and it is possible that satisfaction could serve as a leading indicator for productivity; a decline in satisfaction and engagement could signal upcoming burnout and reduced productivity. Best measured with surveys, common metrics used include employee satisfaction (eNPS) and developer efficacy (whether developers self evaluate that they have the tools and resources they need to get the work done).

### Performance These are the outcomes that we’re focussed on, as opposed to output (or output rate) of a developer or a team. Could be rephrased as the question, did we hit our expectations? Example metrics would be system reliability, bug rates, customer satisfaction (nps), feature usage, cost.

Activity

We want to know what we did to get to outcome. These metrics are unreliable if measured in isolation, but form part of a bigger mosaic that show us where we’re spending our time. Examples include PRs raised, commits, code review rates, production releases and operational incidents.

Communication and collaboration

Making things is fundamentally a human process. Making complex things or solving hard problems takes a team. To work effectively this means we have to communicate, collaborate and have empathy for each other. Teams that do this best are transparent, know what each other are doing, are inclusive and diverse. Being an effective team means that you’re more likely to be working on the right problem, you’re more innovative, and you stand a better chance of solving hard problems. Examples include code and design review quality, onboarding time, accessibility of expertise within the organisation and the ease of access to great documentation.

Efficiency and flow

Can you get things done without any interruptions and delays? How much focus time are you getting? Are you experiencing flow regularly? How much time are you spending each stay on the most valuable thing you could be doing with your time? All of these things are associated with productivity. FolloWe also need to look at the efficiency of the processes that we work within, for example, using techniques like value stream mapping to try and identify and remove wastes. Driving down waste in line with the practices