Developer Experience: Past, Present & Future

If it feels like everyone is talking about Developer Experience these days, that’s because everyone is talking about Developer Experience these days 😆

Engineering orgs are standing up teams focused on DevEx. Products are trying to bottle it up and sell it. Conferences are hosting sessions on it. Scientists are studying it. Developer tools are crafting their value propositions around it. Career paths are coalescing around it.

Is all this attention to DevEx warranted?

Abso-fuckin-lutely. With countless industries investing heavily in software - and nearly every company now employing software developers - it’s essential to focus on the experience of those driving that development forward.

But listen: The world doesn’t need another “What is DevEx and why is it important?” blog post. These days, every big developer tool platform seems to have an article with that approximate title. So, we thought we’d go a little deeper and instead write about the origins of DevEx, the current state of affairs, and some thoughts on where DevEx might (and should) be headed.

Where have we been? A brief history of DevEx

DevEx was conceptually defined in 2012 by scientists Fabian Fagerholm and Jürgen Münch. In their scholarly article “Developer experience: Concept and definition", they describe developer experience as reflecting “how developers think and feel about their activities within their working environments.”

Prior to this, mentions of DevEx are scant in popular and social media. In this social media post from 2010, Developer Experience is mentioned explicitly, and a clear analogy is made between it and User Experience.

Not six months later, Jeremiah Lee Cohick wrote about DevEx in March of 2011 in the UX Magazine article “Effective Developer Experience (DX)”. Cohick wrote that when Apple released the iOS SDK, it moved the iPhone beyond being a mere product, making it a platform. He went on to argue:

When a product transitions into being a platform, it takes on a new type of user: the third-party developer. When developers build their own products on a platform, they are in effect users of that platform. But they are a special type of user, one that behaves as an intermediary between end users and the platform product.

An end user’s experience with a platform product, such as the iPhone, includes the experience of using third-party apps. Every app is a use case that should reflect the user experience of the principal product. Platform product owners must be concerned with assisting developers in accomplishing this if end users are to have a good user experience overall. Attention to these details is called developer experience (DX), and enabling app developers to be successful through better DX will create a more successful UX for the platform product.

Outside of these couple mentions, though, search engines don’t point to much industry talk around DevEx prior to the publication of Fagerholm and Münch’s concept-defining piece.

Over the next several years, however, we do start to see “developer experience” pop up in the titles of scientific articles and conference proceedings. Some of these defined and examined DevEx as an analogy to User Experience, considering the experience of developing with certain tools or within particular development contexts:

• “Design framework enhancing developer experience in collaborative coding environment”
• “Are software developers just users of development tools? Assessing developer experience of a graphical user interface designer”
• “Investigating factors that influence developers' experience in mobile software ecosystems”

Others examined the human factors of DevEx:

• “Flow, intrinsic motivation, and developer experience in software engineering”
• “Consequences of unhappiness while developing software”
• “Unhappy Developers: Bad for Themselves, Bad for Process, and Bad for Software Product”

A strong sign that a concept is gaining traction is when researchers begin conducting literature reviews around it. Just this past October (2024), Razzaq et al. published a literature review focused on DevEx research. Their review covered research from January 2005 to July 2020, aiming to pinpoint practices and methods that impact developer experience and productivity—both positively and negatively. Remarkably, they identified 218 relevant papers focused solely on the productivity aspect of DevEx.

With these papers, we hadn’t yet seen the DevEx explosion, though. The DevEx concept seems to have really taken hold at the industry level in 2022 when – ten years after Fagerholm and Münch’s seminal 2012 paper – Michaela Greiler and Margaret-Anne Storey collaborated with entrepreneur Abi Noda to conduct qualitative, exploratory research on DevEx (Noda launched a product called “DX” in January of 2021). They drew from Fagerholm and Münch’s 2012 work to define DevEx as:

a broader concept that captures how developers feel about, think about and value their work.

They noted that while Fagerholm and Münch provided “an initial framework for thinking about the different dimensions of developer experience”, it hadn’t explored which of those dimensions impacted DevEx, why some seem to be particularly important, or how teams could overcome obstacles to good DevEx. Their qualitative work aimed to fill that gap, and it led to the development of the DX Framework, which they labeled “an actionable conceptual framework for understanding and improving developer experience” and a “go-to reference for organizations that want to enable more productive and effective work environments for their developers.”

Where are we now? Contemporary conversation around DevEx

Since the introduction of the DX Framework, there has been a proliferation of both industry and academic activity around the concept.

DevEx Science

There are now multiple labs that are either explicitly branded as DevEx research labs – those like Nicole Forsgren’s Developer Experience Lab at Microsoft – or that do research on DevEx topics. For example, Margaret-Anne Storey leads CHISEL at the University of Victoria - Canada, and Cat Hicks heads up the Pluralsight Developer Success Lab.

The Marketization of DevEx

In industry, software engineers, product owners, and startup founders have identified opportunities and business value in tackling DevEx. We’ve seen a rise in DevEx platforms like Spotify’s Backstage or Atlassian Compass. These platforms aim to bring all the tools developers need to build, run, and ship software together in one place, with the overall goal of increasing DevEx through standardization and the removal of infrastructure and tooling overhead. In other words, by removing friction.

We’re also increasingly seeing what I’ll call DevEx as a Product, with the creation of products devoted to helping engineering teams ascertain, evaluate and improve the DevEx within their teams and organizations. DX is the original and predates contemporary academic research, but multiple software engineering metrics platforms have built out DevEx products within their existing suite of products (Jellyfish, Flow, and Swarmia, to name just a few). These tools use surveys to ask the software developers themselves about the quality of their experience developing software at that company or on that team.

In addition to companies selling DevEx as a Product, many existing big developer tool companies are publishing content on DevEx, providing their own definitions, and pitching parts of their product offerings as DevEx enhancers. For example:

The Viralization of DevEx

When a new corporate concept gains traction and we see a surge of media around it – like podcasts, webinars, articles, blog posts, and conferences – this means there’s a broad interest, curiosity, or at least a perceived need to understand the concept, and this is typically born from a collective, baseline validation of the concept. The concept's popularity suggests a commercial opportunity, prompting creators, consultants, and companies to develop resources, tools, and training around it.

And we’re certainly seeing this with DevEx at the moment. If we look solely at conferences, just this year, we saw Harness host a Developer Experience Summit. Sentry hosted a Developer Experience event. GitButler launched The Merge, a conference devoted to Developer Experience. And Gradle hosted the DPE Summit, which their marketing materials claim is “The only event dedicated to Developer Productivity Engineering (DPE) and Developer Experience.”

Where are we going? Future Directions for DevEx

Looking ahead, we think the future of DevEx will be shaped by emerging technologies, evolving team needs, and the growing importance of seamless workflows, all increasingly guided by empirical research that illuminates what truly empowers developers to do their best work.

Specifically, we hope to see more of the following.

Group Difference Reporting in Empirical Research

There are a handful of influential DevEx research papers that either don’t report on participant demographics, or that include samples that are much too homogenous to be able to confidently propose frameworks applicable to all software developers. Consider the unique demographic and firmographic profiles of the following developers:

Each of these will likely face different challenges through that unique combination of their demographic and firmographic details. We need more research that explores and reports on these individual differences so that we can understand the experience(s) of developing software for all software engineers, regardless of gender, age, race, education, etc. Only through this expanded understanding can we begin to think about targeted interventions for improving DevEx.

DevEx Professionals Translating Empirical Research

Finding, reading, thinking about how to apply, and then actually applying findings from empirical research is time-consuming and cognitively demanding. That, and it requires a certain level of research literacy that understandably, many software engineers don’t have. Despite the barrier to entry, I wish I saw more software folks – from the IC-level to high-level leaders – engaging with empirical research. Perhaps what’s needed here are intermediary folks with backgrounds in academia, software industry, and pedagogy (the methods and practice of teaching) . These are unicorn people, of course, but they’re out there. If more research labs employed folks with this skillset – or, if Developer Experience teams included a role requiring these skills – they could translate scholarly research into practical applications, and then help make sure those practical applications (i.e., interventions) are fed back into research for the iterative construction of knowledge and evidence-based practices.

Developer Tools That Make DevEx Insights Accessible

When a company claims their tool will enhance DevEx, that tool should come with built-in, empirically-grounded features that allow customers to clearly assess its impact. Customers shouldn’t have to undertake the heavy lift of designing and implementing pre- and post-measurements themselves. Instead, tools should offer reliable, valid insights rooted in the latest DevEx research and developed in collaboration with experts in research methodology and measurement design.

Wrapping Up

DevEx has come a long way since Fagerholm and Münch formally defined the concept back in 2012. At Depot, we strive to make the experience of developing software great for those who do it, and we hope we continue to see this area grow.