Imagine that you have to accomplish the daring task of bath an elephant, but all the necessary items for the task are in a cabin 5 kilometers away. You have to hop inside a vehicle, separate the necessary items and take them to the location of the task. If, for any reason, you forget an item, you have to go back, duplicating your initial time. Once you finally give the elephant its bath (not at all an easy task, given the animal’s size), you have to take back all the items you used. Those tos and fros and possible mishaps increase the complexity of the task which is quite hard in itself. Basically, you take a whole day to complete your tasks and even the smallest mistake could cost you a lot of time.

Well, sure enough your experience as an elephant-washer is not such a good one. Until one day, somebody decides to build a cabin near the elephant and move all the necessary items for the bath there. From then on, your life changes! Now, everything is close and the task flows easily, your cognitive load is reduced drastically and you can focus more on the task itself, that is, on the bath. Due to that, you develop new elephant bathing techniques, getting better and better at it. The general cost reduced for you as well, because a vehicle to come and go with the items is no longer necessary. With the extra time, you start to have more control over the items that you use for the bath, and now you buy them in large quantities, optimizing costs. What used to take an entire day, was troublesome and expensive, now takes you less than half a day and is smoother and more specialized.

If you replace the elephant with a complex system, and the bath for the task of developing and maintaining the system, you will be faced with the importance of a good Developer Experience: that is, how a good external organization, processes, tools and the whole environment influence –whether positively or negatively– the technical creation of your product and, consequently, your results. Let us analyze the details of all this.

The Developer Experience is a layer of analysis that aims at providing the best environment, conditions and tools for developers to have a fluid and natural experience without great efforts in the process of creation, maintenance, depuration and integration of softwares, to reach better results in less time. The DevEx (sometimes simply DX) includes everything that has an impact on the practical flow of development, and how that can help or get in the way of the company or integrator goals for a given product. The DX can appear in different contexts, the most common are:

The internal context of the company. Basically, what the developers that are employees or provide services are experiencing every day at work, and how that experience affects the process of the product and, consequently, the goals and results.

The external context of the company. It is the case of companies that offer products to other developers such as: tools, integrations, open source packages, and other services in general. Here, the DX refers to how the developer interacts with the product as a consumer. That DX also affects the goals and results once more integrators use your product easily and become success factors for your business.

It is important to consider that a good Developer Experience is built by all the agents in your development flow and can represent a slow and gradual change of thought and culture within a company. There is no exact answer on how to have a good DX because each product is unique and each context is unique. Anyway, there are some specific points you can try to define the start points.

Processes: make sure that the phases, processes and priorities of your development area are well set, make sense and are make it clear to all team members.

Documentation: make sure that the demands made by the developers are well documented and whether the documentation can be easily accessed. That issue is especially important when you are offering integration products for the community, open source softwares, public APIs and similar products: it is necessary for the users of your products and integrations to have optimal documentation at hand.

Communication: make sure that the communication is easy and fluid within the development teams and also with other teams. For Outer Source, check if it is easy to report a problem, clear doubts or approach the product. At the team level: make sure your goals are clearly set, communicated and reflected on your organizational process.

Culture: make sure that the team and company culture provide your team with the level of comfort and tranquility necessary for them to do a good job. Check if there are no hostilities, unnecessary competition, social frictions, unnecessary uncertainties, etc.

Autonomy: make sure each agent has the most autonomy as possible over their work. For example: developers must have access to adequate tools, codebases, privileged accesses, good hardware to work, among others. Moreover, managing tools and infrastructure cannot be a problem at a technical level. Provide autonomy.

Listen to your team: Frequently meet up with your team to check how you are doing. Verify the pain points and find opportunities in the topics discussed.

A good DX turns into benefits for the whole company, for example:

1. Good environment and foreseeable routine: A better routine for developers generates a lighter cognitive load and a psychologically healthy environment, which in turn leads to a better performance. You can discover more about it in this post: How psychological safety affects employee productivity

2.Time management: In a friendly and appropriate environment, the tasks and demands will flow in a faster pace. Frictions such as slow or confusing environment, small and constant discoveries that get in the way of tasks, uncertain environments, lack of constant documentation, faulty and slow communication contribute to a slower and frailer flow, transforming easy tasks into complex and tiresome demands, which leads to losing time. A good DX helps to reduce this problem drastically.

3. Cost optimization: A good DX also helps to optimize costs, each developer will make the most out of their work hours, and that will impact on all the other roles in the team, less infrastructure optimization, rework, and uncertain planning time. A bad DX generally leads to: more hours spent on refining or developing faulty solutions, more meetings, wasting resources, inadequate infrastructure, frequent bugs, etc. All this turns into costs.

4. More innovation: A good experience reduces the cognitive load of trivial problems at lower levels, allowing the developer to also explore better ways to perform tasks, generating better performance and, at times, innovation. A bad developer experience makes the cognitive load be dedicated to maintaining what already exists without breaking anything while changes are applied to the software.

5. Multiplication: All the items above make the product more foreseeable and comprehensible, leading to a faster and more clear exchange of information among developers or teams and, of course contributing to the multiplication of the knowledge surrounding the product.

All these items lead to a healthier product that will entail a healthier culture and a lighter and more assertive work environment.

• Change Failure Rate (CFR): How many critical incidents affected your deploys? Roll backs, critical bugs, infrastructure problems, release problems, etc. Start observing this number for a few months, define an acceptable value and work on your DX to always keep it low.

• Change Scope Rate (CSR): How many times do task plans or definitions change halfway through? That generally leads to rework, losing time, and a bad DX. Ideally, this number should be less than a quarter of the total number of initiatives.

• Time to Start (TS): Once a new demand is conceptually defined, how much time does it take to go from planning to start the development process? This metric can be combined with the CFR for interesting insights, for example: if your TS is low (fast) but the CFR is high, it can indicate a weakness in definitions, your team could be receiving insufficient context about demands, etc.

• Mean Time To Recovery (MTTR): How long does the delay take to recover? Keep in mind that now is not the time to fix the problem but to remove the symptom from the productive flow. Ideally, a failure should be isolated in a couple of hours or less.

Reaching goals in an assertive and fast way is an important and sometimes decisive factor in the development and maintenance of innovative products. One of the pillars to make the developer experience while dealing with the internal culture, tools, analysis and communication a clear and fluid one. That will bring benefits at all levels: from technical, management, to the user, leading to a good product reputation, cost optimization and a good work environment.

In what refers to the initial question that gives this post its title, we can say: the Developer Experience is related to the way in which all the aspects around the development process of a product affect the results, and in how to optimize those aspects to achieve good results. And that is, in itself, a great reason to get involved with your company’s DX: to get good results.