What is DevEx and why it's important?

What makes one software development gig better than others? Or working on a given project a more enjoyable experience than a similarly specced one from a different team? You don’t have to be an IT fella to have an idea of what “user experience” means. But, how about its younger cousin, “Developer Experience” AKA DevEx? It is inching towards the limelight as more and more companies recognize its importance so let's check what it means.

Background

The quest to amplify developer productivity has been a longstanding puzzle in the ever-evolving landscape of software development. Traditional metrics have often fallen short, just think about any KPIs that you have seen for development in your career. So the question remained, what we should measure to enhance the productivity of software developers genuinely? The potential answer to this comes in the form of a groundbreaking paradigm shift known as Developer Experience, a novel approach that is gaining widespread recognition and adoption.

Recent studies, including a survey by Gartner Inc. in 2022, highlight a significant shift in organisational strategies, with a staggering 78% of companies either planning or already implementing formal DevEx initiatives. This signals a departure from conventional approaches and a recognition that the key to unlocking developer productivity is understanding and enhancing their day-to-day experiences. But for what? For example, a 2020 McKinsey study found that companies with better work environments for their developers achieved revenue growth four to five times greater than that of their competitors. It simply benefits everyone around.

What is DevEx?

Simply put, developer experience is the way we, as devs, feel about, think about, and value our work. A common misconception to shoot down is that DevEx is not only about tools. Multiple research proves that factors associated with project management or company culture, such as having clear goals for projects, realistic deadlines and feeling psychologically safe on a team, substantially impact developers’ performance. Points of friction can adversely affect the developer experience at all organizational levels. Foundational issues such as excessive build times and difficult infrastructure often crosscut an organization, requiring attention from leaders or dedicated teams.

DevEx Triangle

ACM: Digital Library: Communications of the ACM

https://dl.acm.org/doi/fullHtml/10.1145/3610285

In the framework presented in research titled What Actually Drives Productivity authors suggest tackling developer experience to its three core values: feedback loops, cognitive load, and flow state. Simplifying everything that makes the vibe of being a developer into 3 keywords doesn't come cheap, but taken together they encapsulate the full range of friction types we tend to encounter. Let's check those dimensions up close one by one:

Feedback loops

Usually, when speaking about optimising software development this slogan comes up quite often. Most often brought-up actions are improving the frequency of deployments, shorter lead times, demo or handoff meetings and many more. Shortening feedback loops while improving the quality of feedback provided is equally important to improving DevEx.

But hey man, that's really flaky and cloudy. What can I do as a developer?

Something that has to be said: Feedback could be coming from people, but also from the tools. Let's look at the average day of a typical dev. We rely on a multitude of tools, processes and environments to get our job done:

During coding, we can use linters and style checkers to make sure we'll be aware if our code is good enough to send PR.
When done writing, we build. Compilation times are crucial to enable short and rapid development. Everyone hates waiting for a project to compile.
It seems to be working, but if running tests locally will be a lengthy and irritating process we risk learning about issues much later in the pipeline.
We're submitting a PR - Will your peers know about code review pending by themselves or do you have to ping them? How long do you plan to wait?
After merging if the system goes down will you be notified? Or we'll be waiting for a customer to come in with complaints?

Fast feedback loops allow developers to complete their work quickly with minimal friction. On the other end of a stick, slow ones, are nothing but a constant stream of interruptions, usually of high importance. This ruins both efficiency, as well as experience. In this take, we care more about the latter, as improving the comfort of work will lead us straight to improvement in team throughput.

Cognitive load

Cognitive load can be straightforwardly interpreted as the amount of knowledge and thinking required for a developer to perform a given task. The complexity of the task obviously drives part of that - adding a button requires much less thinking than in-depth planning of a pipeline. There is a very simple connotation here:

The bigger the cognitive load the slower the tasks move thru.

We can't make complex problems simple by waving a magic agile wand over them, but we can investigate what makes them complex and how we can address that. "Luckily" for us, in the grand scheme of things, the same problem appears consistently across various development projects:

poorly documented code or systems,
the amount of context or task-switching
messy development process
complex procedures
dynamic prioritisation

Flow state

The famous "getting into the zone" phrase. Or groove. Or as the paper authors suggest - in the flow state. Flow state represents that magical zone where developers are fully immersed, experiencing energised focus and enjoyment in their work. The feeling of time passing goes away and you're able to hyper-focus on the given task. From a product perspective, we want to optimise that so developers spend as much time in the flow state as they can.

With great flow, comes great productivity

To achieve that good starters could be:

Flexible working hours, let people work when they actually can/want
Clear deadlines, make sure there is no rush in the daily duties
Amount of interruption, work on internal culture so people don't bother each other for no reason
No meeting hours, set some silent hours in calendars for a deep work
Stimulating and engaging tasks according to competence level

DevEx Measurements

It's practically impossible to reliably track and improve development experience without introducing any metrics or KPIs. But as with many UX-originating topics, it's hard to put a direct metric on experience. As a part of the development team, you most likely will have a good initial feel for which parts of the development process do not really work for you so which metrics to choose will be totally up to you and your case. Let's talk through some more common metrics that could help us peek at the current state of DevEx:

How hardcore or formal you should be doing that depends on the scale of the project and company we're talking about. For small dev teams trying to tidy up their own garden, talking about those once in a while during retrospectives should be more than fine to keep the improvements coming. If you aim higher, you can introduce them to your Jira/Azure environment to be tracked automatically. For that I could recommend taking a peek at Atlassian Compass or DX, at least to get some inspiration on how professionals approach the topic.

In conclusion, DevEx is not just a buzzword. It's an attempt to get a greater understanding and eventually control of the factors that make IT projects speed through the roadmaps. As the software development landscape continues to evolve, measuring and enhancing developer experience will be a strategic advantage for organisations of all sizes.