DevOps Lessons: Optimise for Developer Experience (DX)
Introduction
You’re not doing DevOps if you’re not focused on the customer experience.
Cameron Haight.
The purpose of DevOps culture is to improve the communication between developers and sysadmins:
- It teaches sysadmins to automate their processes and let developers execute those tasks.
- It allows developers to deploy and debug their services in any environment. It gives them the power to deploy fast, get feedback and learn with each cycle.
This is great because it makes us work together to achieve the same Goal. As devops, we should pursue the empowerment of our developers. Every feature that we release should help developers handle their services stability or make faster release cycles. For this, I would say developers are our clients.
In any organization, they worry about customer satisfaction and customer experience. These are values that we should adopt as devops. We could create lots of automation, but if developers do not have access to it or find it too difficult to use, all our efforts are useless.
They are the ones that need to maintain their services, so it is crucial to know what do they need. We should meet developers needs with products that bring value and are easy to use.
How can we improve developers flow?
User experience is the study of users and their particular contexts in order to design tools so that users can perform tasks that let them complete goals.
Richard Fulcher
In this section, I will describe some good practices in User Experience design. This can help devops understand developers needs.
User Research
Before starting a project, we should know the demands of our users. Understanding their context is needed to draw our requirements. The goal is to answer three main questions:
- What do developers need?
- What do developers want?
- Can we write a tool/automation that they can use?
Note: You need to ask specific sub-questions for the context of your company and Platform. Use these questions as your main guidelines. It is also recommended to write down your hypotheses and test them. Use surveys or face-to-face meetings for this.
Identify Personas
In order to understand our users’ needs, it is recommended to create fictional characters that represent them. This is known as creating Personas. Here we should define a person typical behaviour, attitude, skills, and context.
I am going to show an example of two Personas that could be potential “customers” for a DevOps team.
Meet Tom Rivers. He is a 30-year-old guy that works as a Frontend engineer. He is a very smart guy with 8 years of experience. He knows Javascript and Angular by heart. Challenges that he faces:
- Everything that happens after coding and testing is magic. Solution: We should allow him to see all the process that his code follows until it goes to production. We can automate all the processes needed on a pipeline and give Tom the power to trigger, fix and change it.
- He tries to avoid using command-line tools: he uses a UI tool to commit/push to git and does code refactors using an IDE. Solution: if we give command line tools to Tom, he is going to hate it, so he will not use them at all. I would recommend here to give them a UI. You can find UIs for most services in your platform (RabbitMQ, Kafka,…). If a specific service used by Tom does not have a UI, you can write a simple Frontend application that meets his needs.
- Tom cares about the final users using the features he releases. Solution: we need to allow him to report metrics and errors. He should be allowed to check it and even create alerts for specific cases.
Meet Ellen Miller. She is 33 years old and works as a Backend Engineer. She is also a very smart woman with 6 years of experience that writes code using NodeJS. About what she cares:
- Ellen does not want her services to go down, be slow or return 500 errors. Solution: we should make metrics (CPU, memory, latency,…) available to her. She should also be able to report other metrics, create alerting, and report errors and crashes.
- She likes command-line tools but she uses a MacOS. She does not know much about Linux internals, Docker or Kubernetes. Solution: The DevOps team should create workshops and give her resources so she can understand the platform.
- She wants her services to keep some status that does not get erased if her application restarts. Solution: she should have the possibility to deploy applications with state (databases,…). Also creating snapshots and metrics for them.
- When there is an error on a pipeline, Ellen never checks it because she always finds many barriers to fix it. It is easier to just ask DevOps to fix it. Solution: we should find these barriers and bring them down. Keep in mind that developers sending errors to DevOps is bad for both sides: it interrupts DevOps and their current work and blocks developers on their current task until the error is fixed.
Note: I tried to keep these examples short. It is recommended to identify 3 or 5 Personas. We could create other Personas like Robert Cohen, a product owner that wants to validate hypotheses about his users. A/B testing could help him with this.
After this exercise, we should prioritize these points according to their complexity and how important are the problems for developers. We can create projects to improve, combine, automate or simplify processes.
Create your User Journey
For any given task […] think about it like a dialogue. Think about, well if the user does X the system is going to do Y, and then the user is going to come back and do Z.
Richard Fulcher
For this, it’s good to grab paper and a pencil and draw the interactions between your user and the application:
- What is painful for the user? Can it be improved?
- Does this flow make sense for Tom and/or Ellen?
- Write hypotheses about possible workflows and ask developers which one makes sense for them (think of it like a cheap A/B testing).
So, as an example, we could describe the User Journey for Ellen Miller trying to debug a service: she picks a bug from her board. She needs to ask the only Senior DevOps in the company for permission to access production. After waiting between 30 min to 1 day, she gets access and can see the logs in production. She finds the error log and proceeds to fix it.
We can see that getting access to Production is a big blocker in this User Journey. We could think of automating this process on a repository and create a pipeline for it. So developers can create an MR to give themselves access and other 2 people in her team can approve the MR. Once it goes to master, it will run the pipeline that gives her access.
Feedback and Continuous improvement
Writing a whole new and complex tool is expensive. To ensure Tom and Ellen will use it, we need to validate it early on: build only what they need, get feedback and iterate as fast as we can.
Recommendations for getting feedback:
- Usability Review: Note the places where people are likely to get stuck and the things that confuse them.
- Usability Testing: Get other people to use it while you watch to see where they get stuck and confused.
- Usability Issues: organize meetings with the developers to describe the problems that you found that are likely to cause users grief and help them decide which ones are most important to fix and how.
Note: If we just ask people “do you like it?” they will probably say “Yeah, we love it” even if sometimes they feel confused about some features. This is because you are using a leading question that leads the person to the answer you are looking for.
If you are trying to get feedback by asking questions, try to start with “How” or “What”. Examples: What errors have you seen? How happy are you with the tool? How fast do you find the tool? How much effort do they need to execute a certain action? What do they think it is missing?
Still, keep in mind that people may say one thing and do another, so it is always better to observe their behaviour.
Example
As an example of good and bad tooling, I would like to compare two command line tools: Google’s kubectl and HashiCorp’s vault.
I love kubectl because it is intuitive and simple. Almost every command follows the same structure “kubectl [verb] [resource] [name]”, so you can get a deployment “kubectl get deployment message-app” or edit a ConfigMap “kubectl edit configmap my-config”.
On the other hand, vault is a command line tool that I, personally, hate. I always end up looking for a Cheat Sheet. It is zero intuitive. With this tool, you list secrets using “vault secrets list” but then you need to read it using “vault read secret/my-secret”. It is very confusing, even when it shows an error message, it is normally more confusing than helpful.
Conclusion
You could be thinking ”Well this idea is nice but it is pretty naive, what about the work I need to do on the platform like scaling nodes. Developers do not know about most of these issues and will not ask me to do it”. And for this I say: do not forget that developers are customers and, like most customers, they do not exactly know what they want.
As a devops, I see myself as a facilitator. It is amazing to actually bring up new ideas to developers: Chaos Monkey, add a dependencies analysis step to their CI, Canary deployments,...
Also, if you think there are some specific sets of features that are not being built for any specific Persona, then you are missing a Persona. Think: Who will use the feature you are developing? What is its goal and who is responsible for meeting this goal?
Finally, I would like to mention that DevOps can also write UI tools. I consider myself as a Backend Developer that is doing DevOps. I like Linux, APIs, and databases, but I think that learning Frontend is another step in my career as a developer.
Imagine your developers are looking for a centralized website to see and control your platform. A good devops would say “Let me learn how to create that and I will show you a prototype” instead of “Well that is not possible because devops do not write Frontend code blah blah blah”.
Hear what developers want, find out what they need, bring them an early solution and iterate on it till it meets its purpose.
Sources
- Fostering UX on a DevOps culture by Matias Gianni
- Let UX Drive DevOps by MicroFocus
- Don’t Make Me Code podcast by David Dollar and Stephen Boak
- Udacity’s Product Design course
- 10 Types of User Feedback You Need to Build a Better Product by Craig Morrison
- Never Split the Difference by Chris Voss
- The Rainbow Spreadsheet: A Collaborative Lean UX Research Tool by Tomer Sharon
