WTF is Developer Experience and Why Does it Matter?

As an old Java developer, one of the tools that made the biggest difference to me in terms of my day-to-day productivity was something called JRebel. Introduced in 2007, JRebel was an IDE plugin that largely eliminated the build and redeploy phases of the Java EE development cycle through a process the vendor, ZeroTurnaround, called "hotpatching" or "dynamic app reloading”.

This might appear odd. A typical deploy for me at the time took around 15 seconds which seems trivial, but those small breaks had a compounding effect: “I’ll just quickly check email/glance at my phone/check the weather report whilst waiting for that deploy”, I’d think. Then, suddenly, I’d lost my train of thought altogether.

As software engineers, our core job is to deliver value to the business. Time spent fighting the system or the tools takes away from the creative process of building the product. Developer Experience (DevEx or DX), sometimes also called engineering enablement or engineering productivity, is about creating an environment in which a developer can do their best work. The term can be confusing, partly because it encompasses both the work that platform teams do to bolster the productivity of the other development teams in an organisation and also the tools built for developers—whether those are built by in-house teams or purchased from vendors.

Kurt Kemple from Forthright has gone as far as suggesting that Developer Experience is the new Developer Relations, providing the definition that DevEx is “An event or occurrence within an ecosystem that leaves an impression on a developer”. I personally find this definition too broad to be useful, but the blog post is interesting and well worth a read.

Ultimately, however, the goal of DevEx is to make building “the right thing right” the easiest thing to do.

DX vs UX

Just as there are parallels between Developer Experience and Developer Relations, there are also parallels between Developer Experience and User Experience. Great DevEx, like great UX, should ideally get out of the way, leaving the developer in flow state. As Albert Cavalcante wrote:

“Developer Experience is the equivalent of User Experience when the primary user of the product is a developer. DX cares about the developer experience of using a product, its libs, SDKs, documentation, frameworks, open-source solutions, general tools, APIs, etc.

DX and UX share some principles, but with differences in good practice; this is because developers have different needs in their daily context compared to an average user.

In short, DX is important for the same reasons that UX is important. Developers who find good DX are happier, promote more, and use their product longer”.

In their 2013 dissertation Fabian Fagerholm and Jürgen Münch drew the same parallel between DevEx and UX, and also suggested broader connections:

“New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers’ feelings, perceptions, motivations, and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems, and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance”.

Fagerholm and Münch see DevEx as a complex sociotechnical system that needs to consider everything a developer interacts with to plan and produce software from the very first line of code all the way through to its release into production. This will include documentation, SDKs, version control, observability—everything that has an impact on productivity. As with all aspects of being Cloud Native, organisational culture also has a significant bearing on an organisation's ability to provide a good DevEx for their developers, and therefore a successful DevEx initiative needs to match the organisation’s engineering culture—hence the somewhat contrasting approaches to DevEx taken by the Financial Times, Mozno, and Spotify.

Why is DevEx important now?

There are four major factors in play that tell us why DevEx is gaining such prominence now:

• Developer job market
• Evolution of software development
• Changes in developer responsibility
• Consistency of approach

The first has to do with hiring and retention. With demand still so high, developers are expensive, hard to hire and difficult to keep. Why would a developer put up with a poor developer experience when they can likely find a job that better aligns with their needs and preferences?

The second is that the nature of how software is built has also changed out of all recognition. For one thing Microservice-style architecture has, for better or worse, become the default choice, meaning that the majority of developers are building distributed systems with all the inherent additional complexity that implies. But in addition, the systems we build are increasingly made by assembling pre-made components rather than writing everything from scratch—an idea rather wonderfully expressed in this XKCD cartoon from Randall Munroe.

This shift undoubtedly allows us to build systems faster, but much of the responsibility for selecting, assembling and running these development toolchains has been left to the individual engineers. RedMonk’s Stephen O'Grady refers to this as the Developer Experience Gap, and it is self-evidently not sustainable beyond a certain point:

“Most toolchains, from where the first lines of code are written through test, build, integration and deployment all the way out to production, are made up of a patchwork quilt of products and services from different suppliers.

What the market is telling developers and their employers alike, effectively, is that the market can provide a system that will shepherd code from its earliest juvenile days in version control through to its adult stage in production. It is telling them that the system can be robust, automated and increasingly intelligent. And it is also telling them that they have to build and maintain it themselves.”

The third change driving DevEx adoption is the tendency to shift everything left, putting more and more responsibility on the individual developer and away from specialists like DBAs, security people, testers and ops people. This evolution in turn requires us to provide tooling that matches what developers, rather than specialists, need.

To pick just one of these, Rachel Stephens’ piece for RedMonk covers the role of DX in helping developers build more secure applications:

“If we are asking developers to be increasingly responsible for building secure apps, we have to make it as frictionless as possible for them to do so. We need platforms and software with baked in security defaults. We need to embed principles of least privilege. We need guardrails not gates. We need a focus on usability and speed. We need reduced configuration areas exposed to developers. We need automation. We need developer experience.”

“By standardising on a small set of technology choices, and continuously improving these tools and abstractions, we enable engineers to focus on the business problem at hand — rather than on the underlying infrastructure”