In Defense of Developer Experience

A common gripe with focusing on developer experience (dx) is that it's less important than user experience (ux). Of course what we ship to user land is the most important thing. But in my experience dx and ux tend to go hand in hand...

At our agency we build a lot of custom software. We also run on tight deadlines. More so than single product orgs I've been at, we are often held to our estimates (+/- two weeks). We ship often, and we want to ship on deadline.

In a sense we don't just have ux to content with, but also our customer's experience (cx). In my observations customers want two things:

1. They want to build valuable features.
2. They wanted to ship those features yesterday.

Customers get excited about these features, they tell their clients about them. Even if you tell them not to make promises, they will still make them. They'll tell their users, they'll see their eyes light up, they'll press you to move faster. Now how does this relate to dx?

Shipping the MVP on time is important, and often times its easy to sacrifice the things that make your developer life better long term a.k.a dx. These can be fundamental things like testing or convenience features like a heavier library that helps with type correctness.

The problem is, most clients THINK they have the perfect product. After they launch, they KNOW they don't. But they have something even more amazing, user feedback...

Now they want to fix the errors at an even faster rate. They push for more engineers, more sprints, anything to help correct their early assumptions. This is when paying no attention to dx starts to hurt.

All the small inefficiencies you put up with start to add up and now you wish you had spent time uncoupling those components, or writing tests for that complex permissions feature. If it's a Typescript project maybe you let a few any types slip in there.

Now you're trying to ship a truly valuable feature and playing whack-a-mole with bugs that pop up in unexpected places. Those few untested features that went out at the end of the project to meet a deadline are slowing down delivery today.

And this is where agencies lose clients. It's not on the MVP build. That's table stakes, you should be able to launch single projects. But the long term maintenance and evolution are where projects are won and lost, and where most of your unrealized profits are.

This is also where our customer lost users. They will put up with some pain for enough value. But often times, we miss many marks with an MVP. It is critical not just to get early user feedback, but be able to action on it.

The dx that is left at the end of a project affects this greatly. It is tied to ux because you cannot ship value to users at a reasonable velocity without it. You cannot be confident that those new features don't break existing features without it.

At Cause of a Kind we focus heavily on the dx of our projects because this is how we learn to do more with less. It's how we ship more value at a higher velocity over time. When velocity plummets and simple features struggle to ship it's ux and cx that suffers.