BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News DX Unveils New Framework for Measuring Developer Productivity

DX Unveils New Framework for Measuring Developer Productivity

Software development intelligence platform DX has introduced a new framework named DX Core 4, designed to help engineering leaders measure and improve developer productivity. The framework aims to simplify this task by building on older established frameworks like the DORA metrics and SPACE. It has been developed in collaboration with industry experts, including Dr. Nicole Forsgren and Dr. Margaret-Anne Storey.

"The 30-second version of what DX Core 4 is is our answer to the question 'what should we measure?'" explains Laura Tacho, CTO of DX, in a podcast about the launch of the framework. "Engineering leaders are still left to answer the question for themselves, what metric should I actually pick?"

The DX Core 4 metrics

The Core 4 framework focuses on four key dimensions: speed, effectiveness, quality, and impact. The team chose these dimensions as 'oppositional metrics' that help organisations balance their measurement approaches. "Speed is great, but if you're going faster with being less effective, that's not great," Tacho notes. "Business impact is great, but if you're having a lot of business impact but your quality is going down, that's not great either."

Other frameworks such as DORA emphasise 'lead time' as a key metric of delivery speed, but Core 4 notably looks at 'diffs per engineer' instead. On the podcast, DX CEO Abi Noda explains that the need to communicate effectively with non-technical stakeholders was a key driver in this choice: "A metric like lead time, while it's really well understood within the engineering community... when you take that metric to non-technical stakeholders or your CEO or your CFO, you often get asked questions like 'why does lead time matter?'".

The concept of measuring diffs is also now used by Meta, as explained on their own podcast.

The framework also emphasises developer experience as an essential counterbalance to performance metrics. This emphasis attempts to address common concerns about the gamification of metrics and potential negative impacts on engineering culture. "If there are cultural problems created with diffs per engineer, then that will be reflected in the Developer Experience Index," Noda explains.

"If your business stops innovating, you will lose. It's just a fact of capitalism"
- Laura Tacho

For measuring business impact, the Core 4 framework introduces 'percentage of time spent on new capabilities' as a key metric. This approach offers organisations a practical way to assess their innovation output without trying to calculate this per feature.

Tacho and Noda explain that the framework's practical application has already shown promising results in large organisations. For example, pharmaceutical company Pfizer has successfully used the Core 4 to demonstrate simultaneous improvements in speed, security, and documentation quality. This case study illustrates how the framework's balanced approach can help organisations avoid traditional trade-offs between different aspects of development work.

Addressing concerns about potential gaming of metrics, Tacho shares insights from real-world implementations: "In talking with our customers, some that are operating on huge scales... they had said in their tenure doing developer productivity at LinkedIn, they have never come across a case of someone trying to game the system."

The Core 4 framework arrives at a time when engineering leaders face growing pressure to quantify the business value of their work. "We're in this post-ZIRP world. The market is really changing, expectations on engineering leaders are changing a lot," Tacho observes. "It will only help you if you can really confidently articulate why things like developer experience, platform tooling, CI/CD are good for the business."

The framework is designed to be applicable across different organisational levels while remaining practical to implement. It incorporates metrics from existing frameworks while providing more explicit guidance on which specific metrics to use. As Noda points out, "If as an industry, as a research community, and as practitioners, we recognise that just even defining productivity is really challenging... it makes it almost impossible to drive aligned efforts, conversations, investment into improving developer experience and productivity."

DX emphasises that the Core 4 framework should be implemented responsibly, particularly regarding metrics like diffs per engineer. The company recommends measuring such metrics at team and organisational levels rather than individual levels, and that always considering them as part of a balanced set of measurements rather than in isolation.

In a response on LinkedIn, psychologist and neuroscientist John Flournoy stresses the need for contextual interpretation of the DX Core 4 metrics, arguing that productivity and speed cannot be evaluated without situational awareness of company goals. Flournoy also questions whether faster is always better, examining the complexity of defining value and understanding the full scope of developer responsibilities beyond pull requests. Flournoy closes out his post by highlighting that his criticism isn't directed at the DX Core 4 methodology itself but rather at how organisations interpret the metrics revealed. He urges organisations not to apply the metrics as universal standards.

"If you have an established product that needs incremental improvements, and a lot of thought given to new features, or a little extra engineering capacity to respond to sudden changes, slower might be just right."
- John Flournoy

The balance between innovation and maintenance is also important to consider. Flournoy endorses Tacho's observation that spending 100% of time on new features could mean a lot of pain down the road. Flournoy identifies developer experience as the one metric that might transcend contextual dependencies. "Better developer experience is better, full stop, if you value people's experience of producing."

The complete framework and accompanying white paper are available at dxcore4.com, together with detailed guidance on implementing these metrics in their own environment. DX plans to release additional resources, including benchmarks and industry data, to help organisations better understand and contextualise their metrics.

About the Author

Rate this Article

Adoption
Style

BT