Introduction

For the past 2 years I have been trying to raise awareness of the concept of Developer Experience (DX) both inside and outside Oracle.  Over the next few days I will release a couple of blog posts delving deeper into this subject.  This first post will concentrate on what DX is and why I feel it is important that we invest in it.

What is Developer Experience

The concept of Developer Experience has existed for many years.  As a developer, I have come into contact with Developer Experience well before I realized what it was.  I felt it the first time I used Bootstrap to style a Web page, or when I used jQuery for the first time to submit an AJAX request, or when I implemented the Braintree APIs to add Online Payments to a Web Application.  These were all tasks that I dreaded implementing for various reasons: CSS is tricky to get right cross-browser, as are AJAX requests, and building an online payment platform, well, that’s just downright impossible.  Yet these tools somehow made it … simple.  What sorcery is this?

Interestingly, it is my current stint at the UX team that finally made me realize what’s really going on here: turns out that the people behind these tools worked really, really hard to make them simple to use; they were engineered that way … on purpose!  This is of course exactly what the UX team is doing with our GUIs and the whole experience surrounding the work flows and processes, trying to make them as simple as possible to use for our users (which is really, really hard to do by the way).

Developer Experience is the activity of studying, improving and optimizing how developers get their work done.  It observes how developers work, e.g. which tools they use and how they use them, and then tries to improve those tools (or create new ones) and optimize the development process as a whole.

Developer Experience is the activity of studying, improving and optimizing how developers get their work done.

From this definition you can derive that there is a large overlap between User Experience and Developer Experience, in fact, DX can be seen as a sibling of UX where the user happens to be a developer.  As a result, many of the techniques used to study and improve UX can be applied to DX.

DX encompasses all aspects of the developer’s interaction with development tools and services.  “Tools” are what developers use to design, code, build, test, integrate, release and manage their code and applications.  “Services” are what developers use to access data and functionality of an application; these days this usually means REST APIs (and we will use them interchangeably going forward) but this really covers anything that a developer would use to interact with your application.  Developers interact with your application using APIs;  APIs are to developers what the GUIs are to “regular” users.

APIs are to developers what the GUIs are to “regular” users.

Why Developer Experience

There has of course always been a need for improving the experience for developers but I see 2 major trends in the software industry right now that are driving the need to invest more in DX:

• the rise of the Cloud
• the fall of the importance of the UI

Rise of the Cloud

This of course refers to the move of everything to the internet (“the cloud”).  This trend means that companies are relinquishing ever more control of their IT infrastructure (IaaS), Development Platform (PaaS) and software (SaaS) to a third-party and just pay for usage.  The more they move up the stack (IaaS -> PaaS -> SaaS), the less control they have.  And this creates some real challenges for our customers, e.g.:

• If I cannot access the server-farm, how do I add a server?
• If I cannot ssh into my machine, how do I install <name-your-tool>?
• If I do not have access to the DB, how do I make changes to it?
• If I cannot access the code, how do I customize the application?

The solution to this is to create APIs that provide this functionality to your cloud customers and so the move of applications to the cloud led to an explosion of easily accessible APIs.  This in turn lead to the rise of aggregators and “pure API” companies like Twilio and Braintree that almost exclusively offer APIs and leave the development of GUIs over to their consumers.  They make money by offering metered access to their APIs, just like a utility service.  Pretty much anything you can think of these days is available as an API, including every example mentioned above (yes, you can add a server to your cluster with a simple API call), other examples include emailing, payments and more recently a whole swat of AI related features like Speech Processing, Image Processing and even Deep Learning.

Developers nowadays expect that a traditional application comes with APIs that offer the exact same functionality as is accessible through the UI.  And just like users of our GUIs, developers want these APIs to be simple and easy-to-use.

Developers nowadays expect that a traditional application comes with APIs that offer the exact same functionality as is accessible through the UI.

The same trend has also made it much easier to roll out applications to a massive audience, basically everybody who has an internet connection, about 3.2 billion people, and do it much more frequently.  If you are releasing new versions of your software several times a day to all your users, you better make sure that you use tools that support this type of rapid development and deployment.  Tools that prevent developers from making (or at least repeating) mistakes like automated tests, Continues Integration and Deployment tools, etc.  Again, the role of DX is to assist in this area of development.

Fall of the importance of the UI

The relentless drive for ever simpler GUIs has now culminated into the “text-app”; Instant Message like applications like WeChat and Messenger that try to offer the same functionality as traditional applications but with almost none of the UI.  Instead they use a “conversational UI” in which you use natural language to ask something and the software (usually referred to as a “bot”) will then try to perform that task for you.  These bots rely heavily on APIs to do the things you ask them to do.

Furthermore, more and more devices appear on the market that are “UI-less”, i.e. they have no UI at all!  Probably the best known example of this is the Amazon Echo.  And this trend will only accelerate as the Internet of Things takes off; most of those “things” do not have a UI either (light bulbs, door locks, toasters, etc.).  And just like bots, these rely heavily on APIs.

Maybe somewhat counterintuitive, this trend makes UX even more important as the way users are interacting with applications is completely changing; affordances that they were familiar with are gone when there is no UI and so new ones have to be developed by UX teams.

More importantly though, it makes DX more important as, increasingly, the “users” of such devices are actually developers.  When the Amazon Echo was first released it couldn’t do anything other than play a few songs and tell some (pretty bad) jokes; it was basically a glorified Bluetooth speaker.  However, because Amazon provided APIs that allowed developers to interact with the Amazon Echo and development tools to easily implement new so-called “skills”, you can now ask Alexa for an Uber, order pizza, even start your car for you.  Crucially, Amazon didn’t have to build any of these applications; they were built by an enthusiastic following of developers.   Sales of the Amazon Echo skyrocketed, completely correlated to this rise in skills.  So basically, Amazon enlisted the help of thousands and thousands of developers, for free, to improve the sale of their products.

And that is why DX is important.

In the next installment I will delve deeper into what we can do to improve Developer Experience.