In case of Business to Consumer (B2C) products most often have graphical user interface (GUI) and focus is on user experience (UX). Application and service users (consumers) want to have easy to use practical value adding products - something that makes their lives easier or brings other values. In case of developers, we have Business to Developers (B2D), often no GUI, but command-line interface and focus is on developer experience (DX).
Below is how the above is described by Fabian Fagerholm and Jürgen Münch in Developer Experience: Concept and Definition
So what is DX?
If you ask someone in API economy what is developer experience, responses most likely are something like “most important thing is the documentation” or “how easy it is to onboard the API”. Those are right answers, but at the same time rather limited and simplified answers. We easily tend to think that developer experience is external only and in worst case technical only.
The only accurate description of DX can be found from the above mentioned article from 2012:
DEx (term used by Fagerholm and Münch) consists of experiences relating to all kinds of artifacts and activities that a developer may encounter as part of their involvement in software development. These could roughly be divided into experiences regarding i) development infrastructure (e.g. development and management tools, programming languages, libraries, platforms, frameworks, processes, and methods, ii) feelings about work (e.g.respect, attachment belonging), and iii) the value of one’s own contribution (e.g. alignment of one’s own goals with those of the project, plans, intentions, and commitment). (Source: Fabian Fagerholm and Jürgen Münch)
UX -> DX
Lets discuss the UX briefly before diving into developer experience. UX is more familiar to all than developer exeperience. UX is more than design. It’s about making application work as the user would expect it to behave.
Most of us have written some blogs, articles or other pieces of texts. For blogging Medium.com platform has been popular due to excellent UX and which has been praised as one of the easiest platforms to write blogs. Lets put aside the fact that Medium’s popularity sunk after they changed the business model extremely pushy and focus on the UX part. In Medium, what ever they do, it’s all about how to make writing easier, how to lower the barrier and make writing process fluent. But UX covers more than just the using phase of the application.
Customer in the focus
The essense of UX is to put user in the middle and think consider development from the users point of view, what they need and how they want the product to work and what they want to achieve with it. Take for example a powerdrill. That was created because people wanted to make holes into something. But then the first versions of powerdrils had cords and user was able to put holes only where the cord reached or where you could find a an outlet. But people wanted to make holes in places where outlets were not available. Obvious solution was to invent battery powered powerdrils. Again, the user’s needs are in the focus; not the company or even the product.
Lazy yet capable bastards
Developers are people too - at least most of them. How can you help developers to achieve their goals? They want to “drill holes” too. The big question in developer experience is how we make our fellow developers more awesome. It’s about how you want the product (API) to feel. It’s way more than just how the API is designed.
What is the feeling the developer has when they use your API to build some of the most loved apps in the world? That is the core of developer experience. Why developer experience matters? The common reason is that the developers are busy. Since they don’t have time and if they are faced with bad developer experience, they will find an alternative or do something else.
But that is true for UX as well. If average user finds your app hard to use, they will seek for alternative or just do something else. But with developers, it’s a different ball game. Unlike the average app consumer, developers have a lot more options:
- They can use some open source solution and use it as is or
- customise it,
- they can built it them selves and that is most likely what most developers think first: “I could build that my self”.
Less support costs
Your onboarding process is part of the developer experience and it’s not benificial to have a great onboarding just for the sake of the developers, but also for your company since your support function will go down if onboarding is in good shape. This also when the term self-service comes in to discussion. The developer is able to onboard easily and it’s based on self-service - the result is scaling becomes cheaper, faster and easier.
Internal developer experience
What if you are not developing an API product for sale, but for internal use, does DX matter? Hell yeah! If you have internal APIs which suck and are hard to onboard, your other developers will build the tools again and again since they don’t want to use your badly designed and built product or tool. That results to waste of time and resources. Another aspect regarding the internal tools and great DX is that if the product is built with great DX right from the start (even though for internal use) it will be easier to publish it later. Remember that Amazon develops all the internal tools and APIs for AWS first and then they use same tools internally. Great products with excellent DX will reduce the need to rebuild same tools again and thus make your development faster. If your internal tools have great DX, it will encourage more people to build more tools for others to use - including you. By creating easy to use products for others results to better tools for you to work with in the future.
Hold on, so we have internal and external developer experience…I’ll write about that some day.
Some more to read from 100 Days DX
- #100 - The biggest open resource on Developer eXperience so far
- #99 - Hackers - the top 1% of engineers
- #98 - Invalid Open API spec files ruins the developer experience
- #97 - Lightweight API evaluation framework
- #96 - Embracing open source community driven tools development
- #95 - Exploring the multilevel nature of API Design Guides
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!