Developer Experience: How to Create an Awesome DevEx in the Enterprise
In the not too distant past, I was helping an organisation use their newly built developer platform. I experienced what a developer should never experience: “The Wall of Confusion”.
Imagine a “wall” standing in front of me and blinding me from seeing the effect of my changes, forcing me to rely on someone on the other side of the wall (an ops person) to debug for me.
The developers were hitting this wall of confusion multiple times every day. Coordination was needed between the development team and the ops team to juggle constantly shifting priorities. Standups were tense. Building a simple system took months.
The result? A poor developer experience—one marked by friction, frustration and burnout.
So, how can we avoid the wall of confusion and boost developer experience? Let’s take a look at what developer experience is and how it can accelerate cloud adoption in the enterprise.
The Danger of a Low-Effective Environment
To understand what’s at the root of a poor developer experience, let’s go back to the example above.
As you can see in the diagram, I—as a developer—was flying blind. To make any progress, I had to raise a ticket and describe what was happening to an ops person. I had to wait hours or days until they debugged for me.
As we’ve already seen, this leads to a poor developer experience. And this in turn creates a low effective environment.
A low effective environment creates high friction during development. In these environments, we fall into the trap of working longer hours to feel like we’ve achieved something. Each day is filled with frustration which can, in turn, lead to helplessness and burnout.
For obvious reasons, there is a major incentive for developers and businesses alike to avoid such an environment.
It’s more important than ever to understand what makes a good developer experience or “DevEx”.
What Is Developer Experience or “DevEx”?
Developer Experience (DevEx) is about creating an environment in which a developer can do their best work (Governor, 2022). It’s a combination of socio-technical factors that helps to bring joy to work.
A good DevEx is as simple as giving developers the tools to do their job, and at the other complex end of the scale—having dedicated teams to make developer communities effective.
DevEx is about emotions. It’s how we, as developers, feel about the process, systems and tools we use. Do they cause frustration or joy? Do we dread starting working in the morning, and having to organise five meetings to see a simple change through, or do we know that we can fix something very quickly and delight our users?
Do we have visibility into our production systems to have the confidence that the change worked? Or do we deal with the anxiety of not knowing that it's working?
Or do we throw it over the wall and let someone else worry about it?
The work we do shouldn’t cause negative feelings.
Why Does DevEx Matter?
Reason #1: Improve Your Overall DevOps Performance and Demonstrate Business Value
Organisations that invest in creating environments where developers can do their best work and score better across the DORA metrics. These are the four measures that DevOps teams use to track their performance and to determine whether they are “low performers” or “elite performers”.
These organisations understand that it's important to sharpen the tools that developers work with, and not just focus on feature delivery.
Smith, D. et al. (2021) State of DevOps 2021. Google Cloud.
Reason #2: Boost Productivity to Stand Out in a Competitive Market
Developers are expensive to hire, retain and keep happy. “The Great Resignation” is pushing developer salaries to all-time highs.
All businesses are in the midst of becoming software businesses if they weren’t already.
Yet in large enterprises, highly paid developers spend a lot of time away from their core creative work. This is a problem at scale, and hints at why as technology focused organisations grow, developer productivity suffers.
Organisations that invest in developer productivity perform better in their respective markets compared to their peers.
Srivasta, S. et al. (2020) How software developers can drive business growth | McKinsey, www.mckinsey.com.
The developer experience matters from the moment a new developer joins your organisation. A good developer experience creates an environment where a new hire finds it easy to become productive in your organisation.
Developer productivity underpins the success of your organisation. As more organisations rely on technology and developers to build that technology. A good DevEx becomes a differentiator.
The Ultimate Guide to Cloud-Native: Breaking Out of On-Prem Prison
Cloud-native is the biggest enabler in a generation.
We explore how cloud-native can help you to break free of the constraints of on-prem prison…
4 Good Examples of Great Developer Experiences
Heroku Experience
The Heroku experience is held up as a great example of a developer experience. A simple set of tools and a command-line interface abstracts away all infrastructure and delivery concerns and allows the developer to focus on their core task of building the application and delivering it to users fast.
Heroku’s audience is external developers who use its services. However, the likes of Netflix, Spotify and Monzo take the same approach to their internal developer communities.
Monzo
At QCon London 2022, Suhail Patel, Staff Engineer at Monzo talked about building a CLI tool to help developers deploy services and test APIs in their complex microservice environment. He describes how the developer enablement team solves problems for Monzo’s own development teams.
Spotify
Spotify open-sourced Backstage, a software catalogue and a developer platform, which grew out of necessity at Spotify. It attempts to get the right information to developers so that they can focus on building and testing their software.
Netflix
In a 2018 talk Mike McGarr describes the evolution of Netflix’s evolution from build tools to developer experience tools. Starting with Gradle for Java, he describes the emergence of a developer experience tool from Gradle build tooling.
DevEx Is Contextual and Emergent
Developers exist in an environment that is unique to your organisation, therefore the developer experience has to be optimised for developers to succeed in your particular organisational context. What worked for other organisations might not work in yours.
What works for Netflix, Spotify or Monzo cannot simply be copied into your own organisation.
Because DevEx is contextual, a good developer experience emerges from the continuous improvement of what exists. The continuous improvement of the developer experience needs conscious care and attention. It can’t be left as a side hustle for feature development teams.
High performing organisations create dedicated developer enablement teams whose sole task is to make other developers in their organisation happy and productive. The focus on reducing the cognitive load for other developers.
What Can Enterprises Do to Create Awesome Developer Experiences?
Create Fast Feedback loops
Everything we do as developers exists within feedback loops. We create something, see how it behaves and then modify it. This happens many times a day.
As developers build software, they interact with tools and systems provided by your organisation. It’s not always the familiar environment of their own personal laptops.
Each interaction has a feedback loop. Quick feedback loops create a highly effective environment for developers. Slow feedback loops reduce developer effectiveness. Manual interactions are slower. For example, raising a ticket to ask another human to do something that could have been automated.
Automated, triggered interactions are faster and help a developer to stay in the creative zone.
Siloed ways of working create slow feedback loops. If a developer needs to talk to other teams regularly, many times a day for routine tasks, a frustrating developer experience is created.
Use Team Topologies to Understand Interactions and to Reduce Cognitive Load
Team Topologies emphasises organising teams for fast flow, and how teams are organised has an impact on the developer experience.
A good developer experience should enable fast flow all the way to the end user, in a production environment, and not to a “DevOps” team who takes over after the change has been applied to a development environment.
Understanding the interaction between teams is crucial for a good developer experience. Building your own internal shared responsibility model helps. An example of a shared responsibility model we’ve used is below:
A shared responsibility model makes it clear what each team is responsible for. Improving the developer experience is made easier as the teams building tooling on the bottom layer can focus on enabling product teams in the top layer by providing services, instead of doing it for them.
Team Topologies (Skelton and Pais, 2019) stresses the importance of reducing cognitive load for teams. Having clear responsibilities helps reduce cognitive load, and over time we can be aware of when cognitive load increases.
Create an Internal Open Source Model
An internal OSS model allows developers within the organisation to see how things work and continuously improve the tools developers use. A small improvement can improve the experience of hundreds of developers at scale.
Create a Developer Experience Capability
At scale, the developer experience should be a first class citizen. Just as enterprises use engineering to build products for their customers, the internal developer community should be recognised as customers as well
High performing organisations invest in the developer experience. Without dedicated developer experience teams, large enterprises struggle to become high performers.
How Do We Know if We Have an Awesome Developer Experience?
If a good developer experiences contextual, and unique to each organisation, how do we know that it is good?
Jessica Kerr describes a good DevEx by how smooth it is.
Smoothness can be hard to see, because it's the absence of pain. Here are some aims:
When there's an error, I can see what caused it quickly.
I can find out where each piece of data came from.
When it's time to make a decision, all the information I need is right there.
As the system changes in ways that I care about, I learn what happened, without a lot of irrelevant news.
When there's something important to remember, a computer remembers it for me.
To change the system, I can express my intention concisely, and a computer implements it thoroughly.
A research initiative between Microsoft and Github, called the Developer Velocity Lab, last year introduced the SPACE framework to measure developer productivity.
The SPACE framework introduces five dimensions to look at the complex socio-technical factors that underpin the developer experience.
The five dimensions are:
S - Satisfaction and well-being; how healthy and happy they are, and how their work impacts it.
P - Performance; the outcome of a system or process and looks at factors like reliability, service health, absence of bugs, customer adoption and retention.
A - Activity; the count of actions or outputs completed in the course of performing work like, how many PRs were merged? How many bugs were fixed?
C - Communication and collaboration capture how people and teams communicate and work together, as software development is a collaborative and creative task that relies on extensive and effective communication, coordination, and collaboration
E - Efficiency and flow; looks at how well developer scan make progress on their work
By measuring across these five dimensions in the enterprise, it becomes possible to see where the developer experience is not so great, and measure how awesome it is.
In Summary
Ultimately the developer experience is about how developers feel about the processes, systems and services they use. Does our day to day work cause frustration or joy?
Do we start work by dreading having to organise meetings, instead of being creative?
Developers are expensive to hire, retain and keep happy.
Yet in large enterprises, highly paid developers spend a lot of time away from their core creative work.
If the developer experience creates too many negative emotions such as frustration, helplessness, uncertainty and uselessness, the developer leaves work feeling unsatisfied and disengaged. This leads to burnout and stress.
A good developer experience aims to reduce negative emotions and creates an environment of psychological safety where developers can be their best selves.
