Why the developer experience is so important

What's the deal with developer experience (DevX)? Well, these days, it's becoming a hot topic. According to Gwen Davis, DevX can be defined as “the systems, technology, process, and culture that influence the effectiveness of software development. It looks at all components of a developer’s ecosystem—from environment to workflows to tools—and asks how they are contributing to developer productivity, satisfaction, and operational impact.”

Figure 1 shows an illustration of the developer experience.

Another definition of DevX, is one from Clockwise: “it describes the overall feelings and perceptions a developer has while interacting with a technical product, 'interacting' having a two-fold meaning. Whether the developer is using your product (for instance, your product is an API or software development kit and developers are your consumers) or the developer is creating your product (e.g., your product is an app and the developer is your employee making it), you’re dealing with developer experience. Great DevX is all about optimizing the developers’ workflows, processes, work environment, and more, so that they can have a more meaningful and delightful experience.”

I totally get what both definitions are saying, and there are a few cool words in there like “effectiveness,” “satisfaction,” “optimized workflows, processes and work environment.” So, basically, a great developer experience should make devs happy and super efficient, which means your software gets delivered like a champ in your company (i.e., If you’re a manager, it will be a higher ROI.). But there's a big missing piece–breaking silos–which I will discuss later.

Now, where's all this coming from, and why should you even care? Well, stay tuned for the next section.

Developer or IT department?

These days, thanks to the whole "shift left" thing, developers are carrying a ton of weight on their shoulders. If you're not hip to the term, it basically means doing testing, quality checks, and performance stuff way early in the development game, sometimes even before typing a single line of code. This early testing jazz helps teams predict any hiccups that might mess with performance or other parts of the process. (You can dive deeper into it in this Dynatrace blog post).

But wait, there's more! Developers aren't just responsible for testing; they've got a laundry list of other tasks. They're supposed to set up CI pipelines, play around with different CD setups, make important decisions about how things are built, and be on top of all the libraries and frameworks they need (like Spring Boot or the cloud-native-focused Quarkus). Seriously, it's like they're expected to be a whole IT department wrapped up in one person.

Here's the twist in the plot: even if you magically stumble upon a developer who can handle all that crazy workload, there's a little catch. Our brains are wired to laser-focus on one thing, and for developer folks, that's usually "software development." So, they end up kind of ignoring other important stuff like Ops (or SecOps if you want to get technical with DevSecOps). It's like trying to do a Rubik's Cube blindfolded—a real head-scratcher.

For example, if you're all about the developer life, you're less likely to keep up with what's happening in the infrastructure world. That means you might miss out on some awesome best practices, like the ones discussed in this clean architecture article.

Honestly, I'm more into the idea of having different people with their own superpowers working together seamlessly. It's like a superhero team, but for tech (Figure 2).

Silos in software companies and departments

So, check this out: in the world of IT, they used to have these things called IT silos. It's kinda like how in factories, they'd have different teams handling specific tasks. This setup worked fine in IT for a long while. But now, with the whole shift to microservices and the cloud, they're finding that this isolation of specialties is causing more problems than it's solving.

And get this, even big-shot Gartner put it in black and white. They're saying that a whopping 75% of DevOps projects end up crashing and burning because of issues related to learning and changing how organizations operate. The main culprits for this DevOps train wreck are:

• DevOps losing touch with what customers actually want.
• Fumbling the ball when it comes to changing how the organization works.
• Not enough teamwork and collaboration.
• Setting unrealistically high expectations for DevOps.

It's like trying to put a square peg in a round hole.

What I think the developer experience should be

Based on my past stint in the software game, I can totally vouch for the fact that these silos are for real. Picture this: you've got squads specializing in operations (they keep the tech running smooth), infrastructure, development, security, and all that jazz. Then, you've got the business folks on the other side, juggling deadlines, feature requests, and chasing profits.

Now, let's zoom out a bit. What we see is a gap smack in the middle of these silos. And guess what? That's where I believe the whole developer experience thing comes into play. A top-notch developer experience program should act like a bridge and zap away all the friction between these silos. Let me break it down:

• The business should talk more with developers. For instance, invest in some killer coding tools (IDEs) instead of leaving devs frustrated with clunky ones.
• Devs should have a heart-to-heart with the business side to sync up better and hit those important deadlines.
• The tech infrastructure gang should swap stories with developers. Share the wisdom like the clean architecture blog post I mentioned, and start noticing what's bugging devs, causing slowdowns.
• Devs need to chat with the infrastructure team. Sometimes it feels like they don't trust each other, especially when it comes to making manual tweaks in a Kubernetes setup.
• The security and SRE (site reliability engineering) folks should join the party too. Devs need to understand why they can't just grab any random image from Docker Hub. Plus, the security squad should realize when they're slowing down deployments.

And guess what? There's more where that came from, and I'll cover those topics in future articles.

[ Get the e-book: Operating OpenShift: An SRE Approach to Managing Infrastructure ]

So, the bottom line is that a developer experience program should swoop in and patch up that hole in the middle. But I'm not saying devs need to become all-knowing wizards who do everything. Nah, they just need to get why things happen and what's available so they can make smarter calls on their own (Figure 3).

Oh, and one more thing that's pretty darn important—those different development groups should chat it up with each other. For instance, let's say you're gearing up to create a brand-new app or microservice with some fancy in-house framework. You might run into problems where your devs aren't hitting their full stride during development and absolutely despise maintaining the thing afterward.

Now, here's where the genius idea kicks in. Why not have a talk with other development squads that might have their act together? Maybe they've already cracked the code on clean architecture. Sharing architectural secrets is part of this whole silo-to-silo chit-chat. It's like getting the Avengers together to save the day, but with code and tech instead of capes and shields.

Figure 4 shows a proper developer experience program that should become the glue in between silos.

The importance of the developer experience

Totalent hit the nail on the head when they said talent is like striking gold these days. If you've got top-notch infrastructure folks, operation wizards, and developers in your crew, you want to hold onto them like treasure. And here's the magic trick: having an awesome developer experience not only keeps these champs on your team but also turbocharges their efficiency. That means faster release cycles, and you know what that means – better returns on investment.

And let's be real, surviving in the business world means making those profits. Now, over at Red Hat, we've got a bunch of nifty tools and cool plans in the works to level up your developer experience. But hey, I'll spill all the juicy details about that in my upcoming articles.

Making DevX better

DevX is all about making software development more effective and enjoyable, encompassing everything from the tools developers use to their work environment. It's like a secret sauce for boosting developer productivity and satisfaction. Nowadays, developers wear many hats, from testing to setting up pipelines. Even though they're expected to do it all, their brains naturally lean toward software development. Silos in IT and issues in DevOps are causing headaches, but a better developer experience can bridge these gaps. It's all about making teams talk, sharing best practices, and ultimately, keeping talented people happy for shorter release cycles and better returns on investment.

Imagine that in today's software world, people want developers to be like unicorns, mythical creatures who can do it all. But let's get real, that's pretty unrealistic, and it actually slows down the whole development and deployment process. In the end, that means less money in the bank and less happy developers. But here's the plot twist. A solid developer experience program can turn that frown upside down. It's all about making devs happier, more satisfied, and super efficient. I'll spill all the deets in my future articles. Stay tuned!