Last week, Abi Noda (DX), Dr. Storey (University of Victoria), Dr. Forsgren (Microsoft Research) and Dr. Greiler (DX) published an article on development productivity, identifying three core dimensions of developer experience that have a direct effect on it.
DevEx: What Actually Drives Productivity
- Feedback loops – the speed and quality of responses to actions performed
- Cognitive load – the amount of mental processing required for a developer to perform a task
- Flow state – a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.
I find that Product Management practices largely affect these three dimensions and it is worth writing down some examples.
- Providing clear, targeted objectives – focusing the work on an area or topic, rather that doing everything, everywhere and all at once
- Collaborating on the project problem – sharing the knowledge about the “why” and not only expecting the “how”
- Taking into consideration that technical improvements are needed – understanding that some times to provide solutions faster, you need to slow down and fix things
The paper advocates that to improve development productivity the focus should be on developer experience (DevEx) and describes
… a measurement framework that combines feedback from developers with data about the engineering systems they interact with.
DevEx: What Actually Drives Productivity
Sure enough, the Product Management practices described above have an effect on both the perceptions and workflows related to DevEx. The table below contains some example metrics that are influenced by them.
| FEEDBACK LOOPS | COGNITIVE LOAD | FLOW STATE | |
| PERCEPTIONS | Satisfaction with access to answers, clarifying the system’s expected behaviour | Ease of understanding the problem space | Perceived context-switching working on different problems |
| WORKFLOWS | Time it takes to get answers on the expected behaviour of the solution | Time spent on meetings to understand the problem at hand | Number of meetings per problem |
| Number of “feature not a bug” tickets |
Software development is not done in a bubble. The more we identify the effects of external factors like Product Management practices, the better chance we have on improving it. I am sure there are many more examples and metrics to be derived and would be happy to see this list grow!
More Questions Than Answers 