DEV Community

Cover image for In Defense of Developer Experience
Mike Rispoli
Mike Rispoli

Posted on


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.

Top comments (2)

juniordevforlife profile image
Jason F

The value of DX is immeasurable. If architecture/tooling is getting in the way of shipping features, something has to change. I have first hand experience with this, first as one of the dev's, now as the lead. I am fortunately in a position to make changes, and DX has certainly been a priority.

aileenr profile image
Aileen Rae

Brilliantly put. πŸ‘πŸ» Something else I see frequently ignored with DX is that engineering staff are an expensive resource. The cost of our time shouldn't be wasted fighting unmaintainable code or poorly documented integrations. It's in a company's best interest to empower developers to work efficiently.

It's a balancing act, of course - there's often a huge benefit to shipping that MVP fast, but I believe this requires strict aftercare. If there's no plan for paying down the technical debt incurred, organisations are shooting themselves in the foot.