The (not-so) hidden costs of poor DX

Every engineering organisation wants to have a great developer experience (DevEx or DevX or DX). But as the eng team grows, the codebase becomes more complex, and business needs take priority. DX falls by the wayside. And eventually gets so bad that developer productivity nose dives.

We already have some idea of what bad DX looks like:

• Making a small change takes days, weeks, or, worst case, it never happens.

• Code you didn't touch, magically, breaks.

• Flaky tests start to creep in and cause long CI times.

• New devs onboarding face issues that you've never seen before. Aka "it works on my machine" phenomenon.

• Documentation is non-existent or wildly inaccurate.

Does any of this sound familiar? I've definitely felt this pain, and when a company hits all of the above, it starts to feel like a dumpster fire.

What's crazy is that we devs suffer through these challenges. We put our heads down and we work. Grumbling along the way. But still working. Over time, all the struggles take a toll. And if there's no improvement, we leave to find greener pastures.

The Cost of Poor DX

Often, DX takes a back burner to business priorities. Some might argue that it makes sense. DX isn't the main driver of revenue. But this view is shortsighted.

It's clear poor DX impacts the developer. You and I have both felt that pain. Bad DX results in unproductive, miserable developers. These devs ultimately impact the team and the organisation.

At a team level, devs struggling with poor DX face challenges around documentation, code review processes, slow build times, and issues with onboarding new members. These issues compound over time, impacting code quality and increasing technical debt.

At an org level, DX has an outsized impact on innovation, retention, and profitability. Innovation, although buzz-wordy, is a major selling point for how companies differentiate themselves from competitors.

We should think of DX as an investment. The sooner we start working on it, the larger the benefits we'll have later down the road. And vice versa, the longer we put off working on DX, the harder it is to improve it in the future.

Which brings us to the question, how do we craft great DX?

Crafting Great DX

DX is a complex process that happens over time. One where we need to constantly know where we are and where we want to go. In other words, we need to measure our current DX and define what great DX looks like for our org. Let's start with the latter.

Defining Great DX

This sentence is a perfect summary of what DX is:

Let's put this more concretely. Remember all those pain points? They can be categorised into two areas:

Flow state and Friction.

Where friction can be broken down into feedback loops and cognitive load. Great DX positively impacts these areas. Meaning any system, technology, process, or culture change that improves developer flow state and/or reduces day-to-day friction is considered great DX.

Measuring DX

Now that we know what great DX looks like, the next step is to understand the current state of DX at our org. We need a way to measure whether the changes we implement are moving us in the right direction.

With flow and friction in mind, we can build a set of metrics to track across the developer, team, and organisation areas. Here are some examples:

These metrics can be gathered either objectively through tooling, or subjectively through DX surveys. Metrics should be used as signals and not targets. To make measuring DX less overwhelming, focus on a few metrics at a time.

You'll also notice that improving a single metric might improve many other metrics. For example, reducing the frequency of flaky tests will decrease CI/CD build times, increase velocity, and developer satisfaction. These metrics are a great place to start.

Examples of DX Improvements

Let's get back to the question: how do we create great DX? We could start with these ideas:

• Carving out more time for uninterrupted work, aka fewer meetings, means more time to be in flow.

• Codifying clear boundaries of code ownership, here’s an Opensauced article that shares the benefits of a CODEOWNERs file.

• Creating a CLI tool that abstracts away a repeated manual actions. Creates faster feedback loops and reduces cognitive load.

• Using predictive test selection to run only the tests likely to fail on a code change, instead of running the entire test suite.

Some of the hardest DX improvements will be around changing culture and processes. For instance, creating a space for devs to share knowledge. And actually having engagement in that space can be difficult depending on the company culture. It's also much harder to quantify a culture change over something more tangible like tooling.

The Road Ahead

These examples give a general idea of some DX improvements. However, each organisation DX journey is unique. Over the next many newsletters, I'll be deep diving into the DX journey that open source projects have taken. I want to find the great or not so great examples of DX and see what we can apply to our own organisations. Up next is a glimpse into the world of development containers. If you would like to share a project you love or hate, just hit reply. I read all the responses!

Thanks for joining me on this DX journey!

Further DX Reading

If you’re keen to learn more about DX, these papers are a good read. A lot of their ideas informed this newsletter.

• The SPACE of Developer Productivity

• DevEx in Action

• Developer Productivity for Humans, Part 6: Measuring Flow, Focus, and Friction for Developers