Principles of DX Development

Written by Jarkko Moilanen, PhD. Platform of Trust Developer eXperience Lead

While developing the Platform of Trust Developer eXperience, I’ve come to situations in which I or someone from the team wonders would some idea be inline with the goals we have with Developer eXperience (DX). Platform of Trust offers easy APIs driven access to standardised data flows, reduces vendor-locks and minimizes the need for costly integration projects. In a nutshell the platform is about connecting data providers (left) and application developers (right). The faster they produce new content (apps and data products), the faster our platform spins (more transactions) and the more valuable applications are offered for consumers. 

We don’t have a 2 year plan or fixed goal (numbers or such) that has to be reached for example by 2021. But since we don’t have such a plan, people are wondering and sometimes reluctant to surface their ideas. People should have tools to evaluate ideas so that micro management is not needed. 

To fix this we have created Developer eXperience Strategy which consists of guidelines or principles. The principles offer high level guidance just giving the direction where to go. There are no speed or target elements, just the direction. It kind of resembles the API Design Guide, which we converted a month ago to Platform Design Guide. That Design Guide is not dictating all the details. It contains some details occasionally, but mostly it defines boundaries and patterns. DX principles helps in the evaluation of ideas and also aligns the thinking across the teams. 

Some companies include DX principles in the API Strategy, but we think DX is so important that it deserves to be addressed as such. If you look at the 5 principles as a whole (just the topics) you’ll notice that 3 first principles are about the developer and their daily life. This is due to developer-centric thinking which is at the core of the principles discussed thoroughly in 100 Days Developer eXperience series written by me.

1. Developer in the center

It all begins from the customer. In Developer eXperience the primary customer is any developer. This includes both internal and external developers. As a platform provider you  must understand the needs and workflows of the developers as well as their culture. We need to know who the customers are, how they use our services, what kind of frameworks and tools they use, are they hobby developers, professional developers or something else? The principle can be squeezed into “We do not proceed product-first, we value customer-first approach more”. If they succeed, we succeed. 

In practical level this requires crafting and updating  the developer personas. With help of personas you squeeze the fluffy general DX into compact perfectly fitting targeted developer experience. If the persona is blunt and clinical, your team is less likely to feel empathy towards it. And we all know that building great developer experience requires empathy. 

Our personas at Platform of Trust are now semi-fake since we’ve just started to get developers involved on the platform. We have been discussing and following their operations and needs as well as backgrounds but it has not been systematic. That is what we aim to improve. Then we can iterate the personas again and again and improve the guidance developer personas gives for the Product Owners to steer development in the right direction and focus on things that matter. 

In our DX team, all agreed that we don’t do anything with technically right but clinical developer personas. We wanted them to be alive! We even considered to order standing cardboard figures of the personas! Aim is that in our discussions we refer to developer persona by name. Ultimate test is that if an outsider would follow our discussion, they would soon ask “who is this Dan you keep on referring to?”. In other words aim is to make Dan so alive that he’s a member of the team.

2. Enable flow state to increase happiness and productivity

Developer Flow state is not something you normally think or act on actively everyday. It’s a concept you have to understand thoroughly to be able to create optimal Developer eXperience for your product. Thus your DX team must learn it and keep it in mind in daily activities. 

Cziksentmihalyi defines flow as “A state in which people are so involved in an activity that nothing else seems to matter; the experience is so enjoyable that people will continue to do it even at great cost, for the sheer sake of doing it.”

In the flow developer moves beyond self-conscious state and that is one step towards experience of dreaming. In self-conscious state we use mental energy in status management and worry about our performance and how we are being perceived, which takes away more of our cognitive resources from the task at hand. We worry about rules, expectations, competition and spend a lot of time in a sense of uncertainty about one another. We need to become independent of our social environment and do away with our need for external validation and tendency towards social comparisons.

Flow state is the superman experience when inspiration takes over and where your preparation and relaxing express themselves almost magically. You come up with the best ideas, you achieve results almost effortlessly, and you often surprise yourself by your own performance. You go from your conscious mind where processing information is very slow and energy is draining, to your subconscious mind where processing of information is very fast and very energy efficient.

If at this point your API becomes unavailable, the API documentation gives wrong advices you are close to become the destroyer of flow state.

Since the benefits of flow state (productivity and pleasure) are so high, developers are hunting the flow state all the time. That is when they are most productive and challenges get solved. Your task as a platform or API provider is to help developers to be more productive and happy. Some say their DX should not hinder developer flow state, but we want to look at it differently. Our DX must enable their flow states and make it easier to get into flow state after a break easily.

3. Support workflows

The flow is connected to your customer paths and workflows and that is the second reason why you need to understand it. You should not try to get developers to adapt to your paths. Instead you try to adapt to their workflow as seamlessly as possible.

As a platform we need to provide end-to-end support. Our DX must be fluent from data integration to UX of apps consuming the standardised data. We must understand how our customers use our platform in their daily work, what role it has, how we take away the pain. Identify the pain points and figure out the reliefs is our main aim in service level.

Your platform or API is not the center of the developer’s universe. You are one of the items in the outer rings of the universe. Thus you need to consider how your product works together with the tools they are accustomed to use. An example is API testing for which developers quite often use Postman. You can make a developer's life a lot easier and your product more attractive if you provide a Postman collection which they can use to explore your API.  

You try to adapt to their workflow as seamlessly as possible by providing the right kind of API endpoints, libraries with “perfect” functions which feel familiar to the developer. If all goes well, the developer just uses the tools and APIs without friction. This is hardly ever the reality though.

4. Self-service tools

Our platform is developed with API-first principle. Our customer service is build with self-service first. We must enable stability and availability 24/7. We don’t know when some developer around the globe is willing to try out our platform. When a developer finds your product, they do not first want to talk to salespeople or send emails to you to get access. They want to jump into using it - now! You can understand that the only way to satisfy their needs is to provide self-service tools and access. 

We don’t know when a developer is having issues with our platform. Thus self-service is expected by our customers and our selected strategy. We provide excellent tooling to learn, work and debug solutions built on top of our services. 

Developers are open source lovers because they can modify the solutions to fit their needs. Open source driven self-service  tools are one of the fundamental elements which can make our customers happier and get things done when they need it. Tooling refers to command-line tools, API client test packages (mentioned above), excellent documentation, public real time platform status information and code libraries.

All the above and more are packaged into Developer Portal. That is the one-stop-shop for all developers. 

5. Be in the front-line at global level

Getting where we want to be, the top, requires experimentations and culture of fast failure. We can’t be in the frontline if we do not take calculated risks and experiments. Our benchmark are the global leaders of API and platform economy. We will fail often, but that has to be accepted. 

Since all ideas are evaluated against the above mentioned principles, we need to have principle to follow in trying out things. We do and let our subcontractors to do small one month long  experiments.. 

The principle is that we build prototype first and then evaluate the added value it will bring. If it does not bring  any significant value to the developer eXperience we will just drop the gloves at this point. We might have lost some resources now, but we have learned as well. 

Creating great developer experience is about learning and that is done with experimenting with practical things rather than with theoretical models. You should not think DX as a 110 meter hurdle. Building great developer experience is a marathon. It requires endurance and patience.