Developer Experience and Developer Platforms - Part 1

Mar 11

What is DevEx and how it relates to Business Value?

Introduction

In this blog post, we would like to talk about Developer Experience (DevX or DX) and how it relates to Business Value. The definition of Business Value is a subject of many different studies and discussions, and we have written a blog post about it, but let’s say that it is whatever outcomes and impacts organizations agree are important to them. It is the ultimate answer to the question of WHY we are delivering a software product or service.

Many terms, over time, take on a life of their own becoming marketing buzzwords. It’s important to go back to the origins to reaffirm what the term meant when it was first used compared with what it stands for today. Let’s start with a bit of history and definition of the term “DevEx”.

The Developer Experience (DevX) term seems to have been first used in 2011 by Jeremiah Lee Cohick in the article “Effective Developer Experience (DX)” in UX Magazine. No surprise there - since the term clearly derives from “User Experience (UX).

Jeremiah defined companies that provide “platforms” for developers to create their apps, such as Apple or Google, and defined a good Developer Experience (DevEx or DX) as attention by the platform companies to the experience third-party developers had when developing applications running on these platforms, and argued that better Developer Experience for these developers leads to better User Experience for end users.

Ten years later, it seems that the term has taken off and acquired broader meaning to encompass the experience the developer has while performing their job through interaction with many different factors, such as tooling, processes, APIs and all kinds of other things that impact the process of creating a software product. It has especially been taken up by the companies building developer tools, which is understandable, because for them the user base is primarily developers, and in that sense for them, DX has become synonymous with UX.

You are not building tools for developers. Should you worry about DevEx?

What if you are not a technology company building products for developers to use, but an organization that employs software engineers to deliver software either for your internal users or for your customers? Should you worry about DX? Our answer is YES you should. Even if you take a purely economic view, good Developer Experience is directly tied to better/faster creation of business value for the organization.

In the process of delivering software to production or end-user any work that’s done which is not directly contributing to the creation of software is toil. Google defined “toil” as tedious, repetitive tasks associated with running a production environment. The same can be said for the process of delivery of software. Tasks that are not directly contributing to delivery of software, tasks that are tedious, repetitive can be defined as “toil” in the context of software delivery.

Why is toil bad? One obvious reason is that it increases time to market therefore increasing the time it takes to realize business value from the software product or system being built. Another, less obvious but no less important reason is that building software is a creative process, and nothing zaps creativity faster than bad developer experience. Fatigue sets in. People feel like they don’t have agency like their time and skill are not respected, and so their creativity diminishes, they are less invested in the “thing” they are creating. Anecdotal evidence suggests that teams with bad DX experience higher turnover rates. End result? Slower time to market, subpar quality, slower realization of business value.

In the enterprise environment, toil is one of the main factors that lead to bad DX. This “toil” can manifest itself in different ways and result from many different factors:

Manual tasks related to tooling
Manual tasks or wait times related to manual, not-automated testing
Unproductive wait times due to security and compliance reasons when someone has to wait for approval from someone else to proceed to the next step
Churn and errors due to hard-to-discover and badly documented APIs that are provided by various systems
Wait times and errors due to Development and test environments that can’t be spun up instantly and taken down automatically when not used, and that consistently work without needing to spend time fixing them.

Reducing toil while maintaining regulatory compliance and security posture - these days it shouldn’t be mutually exclusive. Every manual step should be looked at as an opportunity for automation. Reduction of toil leads to improved developer experience, which leads to improved velocity and higher quality and therefore to value. Not to mention it makes for happier and more empowered developers, reduces attrition, and again leads to higher team productivity.

Tools to the rescue?

As we have said in a number of our other blog posts - as you would have guessed we strongly believe in this - you can’t just “tool your way out of this problem”.

Tooling is important, but not enough. There seems to be two extremes when it comes to environments developers find themselves in when it comes to tooling. One, often found in the enterprise, is very restrictive, where a lot of manual tasks still exist, change is slow, and often the developer’s perspective is not taken into account when tooling is selected and implemented. The result, predictably, is that tooling is not used, and experience is not improving.

The other extreme is too much choice, where developers spend considerable unproductive time making sense of the ever-changing landscape of tools and technologies.

Two simultaneous approaches should be used to address and improve developer experience, and they are intertwined. One doesn’t make sense without another.

First is a classical DevOps (or Lean) approach where every step in the process should be examined and all manual steps, or all the steps that don’t contribute to the creation of software automated as much as possible.

Another is an approach that harkens back to the original definition of DX given by Jeremiah Lee, but extended to the enterprise. A developer is a user of all the tools, processes, and technologies that exist in the organization to create and deliver software.

Platform as a product for developers

The term “Platform” has a very rich history and even more ambiguity as “Developer Experience”. We will delve deeper into its history in the next installment of the blog. For the purpose of this discussion, we will just use the definition of the platform given in 2018 by Evan Bottcher from Thoughtworks in the article on Martin Fowler’s blog site.

“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination”.

When the platform is truly treated like a product with a focus on the end user - the developer's real success is possible which leads to both improved developer experience, reduction of toil, and better generation of business value.