The SPACE framework provides a comprehensive model for defining developer productivity drivers. This article explores how the practice of Developer Productivity Engineering (DPE) aligns with these drivers. It concludes that SPACE and DPE need each other. SPACE defines the “what” for improving developer productivity and DPE defines the “how”.
The SPACE framework is a research-based approach to understanding what drives developer productivity and provides a starting point for understanding how to improve it. It was developed by a group of researchers from GitHub, Microsoft, and the University of Victoria (Canada), and it encourages engineering leaders to have a holistic approach to productivity.
Developer Productivity Engineering (DPE) is a software development practice that focuses on increasing developer productivity and joy. DPE solves productivity problems and drives team-based outcomes with engineered solutions that provide observability and actionable insights. This contrasts with the traditional approach which relies exclusively on management best practice and metrics based on individual developer output.
Developer Experience, Productivity, and the Coding War Games
In the mid-80s, engineers and researchers Timothy Lister and Tom DeMarco kicked off a project they would later dub ‘The Coding War Games.’ The goal of this project was to identify the “good” and “bad” traits of software developers, with respect to their overall productivity. Over 600 developers across 92 companies participated in the study.
The researchers came up with a software task of intermediate complexity and asked two developers to work separately on the task and to record the time it took them to complete it. The engineers were not peer developers but rather“competing” against one another. The results of this study are well-documented and led to a book on software team productivity, called ‘Peopleware,’ which focuses on the human elements of developer productivity.
The data is compelling. Organizational productivity—based on the mean working time of each per-company pair of developers and compared across all 92 companies—varied as much as 11.1x from top to bottom. In other words, the most productive companies outperformed the worst ones by more than an order of magnitude. Perhaps even more interesting—within each company, pairs of developers differed only marginally in their productivity, by 21% on average.
The team also polled the participants on various data points about their overall work environment. The following chart details the poll results:
(Source: “Why Measure Performance” : https://www.gwern.net/docs/cs/algorithm/2001-demarco-peopleware-whymeasureperformance.pdf)
These environmental factors tell an important story. Note that top performers are given considerably more physical space to work in as well as more opportunities to focus on their work. Additionally, they have a higher likelihood of being able to silence their phones and report being interrupted less frequently.
This data clearly shows that the quality of the developer experience within an organization is directly related to the overall performance of that organization and that seemingly small improvements can lead to exponential leaps in productivity. Creating a conducive environment to perform work is a great predictor of productivity success.
The SPACE Framework Comprehensively Depicts Productivity
The popular SPACE framework provides a gauge for team productivity that correlates to the organizational traits of the high-performing companies discovered during the Coding War Games. As a normalizing model, performance data can be gathered in any number of ways, and categorized into any of the five SPACE metrics: Satisfaction, Performance, Activity, Collaboration, and Efficiency.
SPACE maintains that there is no single metric by which to measure productivity, so we must instead balance multiple metrics that define different areas of developer experience. To quote the original authors from their seminal work, ‘The SPACE of Developer Productivity’: “[…] only by examining a constellation of metrics in tension can we understand and influence developer productivity.”
Despite the growing awareness of SPACE and the research behind it, a study from April of 2022 called “How Developers and Managers Define and Trade Productivity for Quality” demonstrates that there are widespread differences in the interpretation of productivity and the application of SPACE to improve productivity. In this study, developers (referred to as ‘Individual Contributors’ or ‘ICs’) and managers were asked very similar questions. Developers were asked, “When thinking about work, how do you define productivity?” Managers were asked, “When thinking about your team, how do you define productivity?”
The responses were categorized using the SPACE Framework as they related to Satisfaction, Performance, etc. The resulting data demonstrated two major areas for improvement. First, there wasn’t equal weight given to all five dimensions, with a specific deficiency in “Satisfaction,” and second, developers and managers were thinking about productivity in distinctly different ways.
(Source: “How Developers and Managers Define and Trade Productivity for Quality” : https://arxiv.org/pdf/2111.04302.pdf)
This data demonstrates that Developers think more in terms of SPACE’s activity metric—which includes work outcomes like design and viable code production, builds and other SDLC actions, and technical issues addressed. Managers, by contrast, are focused on performance metrics such as story points and release deadlines. Satisfaction was almost entirely left out of the picture by both groups.
Practices that address all five of the SPACE framework’s metrics, or “dimensions of productivity”, will have the most overall impact on improving performance. DPE-enabling technologies discussed below can be used to collect highly aligned metrics which can then be used in turn to drive improvements in the five SPACE metric scores.
Developer Productivity Engineering Balances SPACE Metrics
The emerging practice of DPE—which focuses on engineered solutions to increase developer happiness—is defined by three pillars, each of which can directly improve productivity outcomes for all five SPACE dimensions.
DPE’s pillars are defined as follows:
Faster Feedback Cycles
Build and test acceleration technologies (both locally and on CI) address the pain of unnecessary developer idle time as well as disruptions to the individual’s creative flow due to context switching while waiting for builds and tests to complete. This results in happier, more productive developers and faster feedback cycles
Efficient Failure Troubleshooting
Troubleshooting broken builds is slow and frustrating for developers, with hours spent on support and reproducing problems. When deep data is available for every build, developers can quickly find the root cause and fix their own problems without re-running broken builds to reproduce problems or requiring the help of the build team.
Reliable Builds & Tests
Eliminating flaky tests and other avoidable failures using observation and analysis leads to trustworthy and reliable toolchains.
In the following matrix, these DPE pillars (see column headers) are cross-referenced with the SPACE dimensions (see row headers). We can clearly see how the new behaviors that result from introducing a DPE practice positively impact SPACE metrics across the entire framework.
SPACE/DPE Synergy Matrix
| Fast Feedback Cycles | Faster Failure Troubleshooting | Reliable Builds & Tests | |
|
S Satisfaction |
Shorter feedback cycles locally and in CI and reduced context switching lead to a more satisfying developer experience. | Less time spent gathering troubleshooting data and trying to determine problem root causes minimizes developer toil and frustration. | Better ways to identify, prioritize, and fix flaky tests and other avoidable failures minimize the frustration of indeterminate or unobservable signals. |
|
P Performance |
Fast feedback cycles and less time spent waiting on toolchain feedback leads to improved software time to delivery. | Decreased MTTR of failures and performance problems ensures your software gets out the door as fast as possible. | A more reliable toolchain that ensures developers encounter fewer problems drives improved team velocity. |
|
A Activity |
Faster build and test cycles locally and in CI lead to more frequent builds and test activity and added bandwidth for higher-value activity. | Faster troubleshooting of issues returns time to the developer which can be spent coding, learning, and innovating. | Proactive elimination of avoidable build failures and flaky tests creates more time for high-impact activities instead of toil. |
|
C Communication and collaboration |
Faster cycles allow developers to introduce smaller change sets, leading to simpler merge requests. This streamlines collaboration and results in fewer merge conflicts. | Troubleshooting data that can be shared easily with teammates through a common interface promotes a shared understanding of the problem. | Increased confidence in the build toolchain and test sets reduces friction in shared design, review, and integration between teams. |
|
E Efficiency and flow |
Faster feedback cycles prevent context switching to another task thereby allowing a more continuous state of creative flow. | Self-service tooling that provides shared access to contextual data for problem resolution maximizes efficiency and flow. | Proactive remediation of systemic build and test problems drives a preventative cultural approach to efficiency and flow challenges. |
SPACE and DPE Go Hand in Hand
The practice of DPE can drive success in every business hoping to increase developer productivity. And using the SPACE metrics as a guidepost to the success of DPE is a winning strategy. To learn more about DPE and how to implement it in your business, check out our Learning Center and the DPE Handbook.