The SPACE paper, referencing an earlier Microsoft paper, argues for the importance of considering perceived productivity. This is represented in the SPACE framework with its “satisfaction and well-being” category.
Developer Experience is a leading indicator of productivity and could be goal on its own.
This reminds me of the SQDCM (Safety Quality Delivery Cost Morale) framework common in the Lean community. Morale aka Employee Experience aka Developer Experience is generally a leading indicator of other goals (i.e., quality, productivity, retention, etc.). If people hate their work, productivity will eventually drop.
Beyond being a leading indicator, and depending on your value system, you may also consider a better Developer Experience to be a goal for its own sake.
Developer Experience is not equivalent to Productivity because what feels productive isn’t always productive… and vice versa.
My issue is when “Developer Experience” is seen as equivalent to productivity because there are many things that feel productive that aren’t productive.
- Being responsiveness to requests feels productive but leads to multi-tasking and lack of focus.
- Removing all interruptions feels productive but can lead to false progress if necessary feedback is late.
- Allowing for individual preferences feels productive but can lead to excessive handshaking overhead if you need to collaborate across teams.
- Keeping everyone busy feels productive but generally leads to too much work-in-process, longer lead times, and lower throughput.
- Producing a lot of output feels productive but isn’t if what’s being produced is low value or wrong.
Conversely, what doesn’t feel productive (at least initially) might actually be more productive (e.g., pairing, small batch development, test driven development, etc.).
