Why the Developer eXperience (DX) matters for business

So. You’re a small, medium sized or even large scale company. IT is an integral part of your business, whether it is a small scale application or an enterprise grade platform. Let me repeat that for you: IT is an integral part of business. You know this, because you’ve been doing IT for a long time, right? But. Are you doing it right?

Yes, you tick the SEO boxes and yes, off course you’re in the cloud (whatever the heck that is). You have backups 🤞. Nice! You even have a couple of scrum teams working together on your product. Extra nice!

So why then, should you bother with DX? Surely you meant UX, as in User eXperience? Because you focus on the client. The user who ultimately funds your whole operation?

Well, yes and yes. Yes you should bother with UX, like a lot. If your customer can’t find it’s way around your product in order to complete its customer journey, you have no sustainable business to begin with.

But the same goes very much with the stakeholders on the other end of the line. Developers adding features, QA specialists ordering lizards and the rest of your team working on maintenance, DevOps and whatnot. As I said, IT is important and business platforms grow and expand over time: Connecting to third party SaaS products. Incorporating internal APIs to legacy systems and automatic scaling to the customers’ demand. Now, if all of this is running, what’s the added value of investing in DX?

Well, your typical loyal customer journey might take less than an hour on your platform. But your development team however, hopefully spends more time on your product. Every. Single. Day.

And while they don’t fulfil typical customer journeys, they too have goals they wish to achieve and journeys to travel. Having a good DX on your products just makes those goals so much more reachable. It means the people (they’re people after all) deal with less overhead when dealing with the software. Less overhead means extra headspace to work on what matters.

If you can truly enable a team to the fullest optimum of a DX, they will not just code, they will fly!

It makes developers more agile in picking features that add value at the shortest instance. It will increase overall happiness (nobody likes chores, right?). It expands developers’ comfort zone, enabling them to work on innovating concepts and ideas.

So what do you consider part of DX?

I think we can split the whole DX into a couple of domains, which all play a role in the full picture:

Culture

This is basically a universal concept, but having a culture where people feel safe obviously contributes to overall happiness.

On top of that, having a clearly defined and communicated vision helps the development team to align on that horizon. Encouraging transparency between stakeholders helps to contribute to a healthy culture.

Processes

Having processes in place that reduce overhead and facilitate the operations. Think about a solid DTAP environment, clear way of working on the software (or in the organisation for that matter). Again, by reducing overhead you allow focus on stuff that is meaningful.

Tooling

Software is complex. Fortunately there’s plenty of help to streamline development in the form of tooling. There are frameworks to reduce development time. Lots of repetitive tasks can (and should all) be automated (linting, formatting, testing). Your tooling can be utilised to give the developers confidence in releasing and shipping code.

Landscape

Finally, the landscape or architecture should facilitate DX: a clear organisation of software, which is scalable and ideally has a clear purpose. If legacy code is part of you landscape (realistically, there will always be legacy code in your landscape), a plan or vision should provide steps to reduce specific bits of legacy code over time.

Obviously, for all of the above you can find numerous facets that contribute to (or detract from) the DX. I’m just giving some examples. Your developers know what pain points they experience on their day to day efforts, or over longer period of time. If you take the time to take inventory of these pain points, you can create a plan to overcome.

Increasing complexity

With increasing complexity of the software, the attention to the DX should scale accordingly in order to keep up the pace for individuals and groups alike and stay agile as an organisation.

There is no silver bullet for this or off the shelf solution. Much as with UX though, with some common sense and talking to stakeholders (developers!) you would find both big and small changes that will contribute to a solid DX.

This doesn’t happen overnight either. It takes time and effort and should become integral part of how you structure the IT related efforts of a business. Luckily though, the investment returns with a multiplier: a more solid codebase, happier teams, accelerated development are parts of the reward.