Article based on my talk at the Devops Conference 2022.
How to Embed Ethics in your Software Development Life Cycle?
It is not only possible to speak about devops and ethics, it is beneficial to everyone, whether you’re the CEO, manager, engineer or product manager. I will go even further and say that if your devops practice doesn’t include some sort of ethics, then it’s probably not devops.
I define ethics as the concern of doing the right thing. As we all know, things that are beneficial to us are not necessarily right, and things that are right are not always beneficial to us.
Embrace Ethical Dilemmas
My first message is that it’s really a good thing to be in situations where you’re not sure what is right or wrong. It doesn’t mean you work on dubious projects, it simply means that you work on things that are important and I’ve never seen anything important that doesn’t come with ethical questions. It also means you work on something innovative, it means you work on something for which there are no ready-made answers to your questions.
We have many ethical questions and dilemmas in IT. Here are two very common ones. The first one is the tension between giving people what they want – and devops is all about giving users what they want, delighting your customers – but also giving people what they don’t necessarily want or what they’ve not necessarily asked for. It’s not necessarily a good idea to give people what they say they want, it is sometimes better to give them something else which might be better for them in the middle or long term, or something which might benefit their ecosystem and make it sustainable.
Another classical example is continuous improvement. If you are reading this article, you probably believe that continuous improvement is a good thing. But it’s not a black and white situation. Users might value daily changes but they might also value some predictability in functionalities available to them, they might value their routines and, in some sectors such as healthcare, they might not welcome day-to-day changes at all. Typically, if your users are asking for some change, it’s then ethically reasonable to give them daily changes. But some of your users might not ask for any changes at all, and might still work on services that are critical, is it ethical to impose daily changes to them even though they are not asking for anything?
Avoiding Ethical Disasters
It’s an ongoing conversation, it requires sometimes very little changes but it has to be included in the way you design your products. Failure to do so leads to ethical damages or even disasters. It might cost you trust from your investors, from your users, from your employees. It might mean losing your position in the market and not being considered anymore as a leader. Because what is expected from a leader is not only to lead in terms of market share but also to lead in terms of knowing how to deal with ethical questions.
Both security and ethics seem to oppose short-term benefits and long-term costs. One of the benefits of devops is that it has nuanced the opposition between security and short-term benefits. It has shown that it is actually possible to develop and deploy secure solutions without having to compromise on speed of delivery. But the same hasn’t happened for ethics yet.
I will now talk about two devops principles and show you how embedding ethics only requires some tweaks. I will show you that by doing so, you can also improve your devops practice as a whole, so it can really be a win-win situation.
The first principle I would like to talk about is ownership and autonomy. One of the key practices of devops is to create small integrated teams that are autonomous. By creating these integrated teams, we make sure that everybody feels engaged in all the aspects of the product or service they are developing and deploying. And certainly, having small integrated teams can only facilitate ethical conversations.
Another practice of devops is to share what works and doesn’t work with other teams. Experience sharing is also a great practice for ethics, if everybody feels empowered to discuss ethical questions as part of their experience sharing rituals.
Deontology of an Engineer
Devops is is by nature on ethical framework. It’s all about deontology. As you all know, in the past, the definition of a trusted engineer was basically someone who would do everything perfectly: who would plan in advance architecture diagrams, infrastructure diagrams that would be perfect, then would implement them without any bug, without any flaw and then would deliver them and everything would work perfectly. This was obviously completely unrealistic. What devops brings is another deontology, another definition of what is a trusted engineer. A trusted engineer is not someone who plans and executes everything perfectly but someone who knows that nothing is perfect, that everything needs to evolve, and can quickly react to evolutions and defects.
It is about trust: why would your stakeholders, why would your users trust you? Should they trust you because you do everything perfectly or because you are pragmatic and you know how to react when things don’t work? I would say that the biggest reason why agile and devops fail is because this conversation about what is a trusted engineer didn’t take place. Ethics could even be the first thing you do to start devops or agile, making sure that everybody understands what it means to be a trusted engineer.
Definition of Done + Definition of Right
Another common practice in devops is the definition of done. It is to define together with your stakeholders what it means to get a functionality or user story done. It’s already a difficult exercise but I argue it is not enough. You should also have a definition of right so that your team can be fully autonomous in its decisions. It should not be the job of someone else to tell you what is right or not in your day-to-day decisions. It should be your responsibility. But you should not be alone facing this question, that’s why it’s important to meet with your stakeholders and members of your ecosystem to create a definition of right.
You can do it in different ways. Devops is encouraging rotations, it’s encouraging you to share the life of your users, to spend some time with operations teams, developers, maybe to sit down with someone from customer care and see what their day-to-day life is like. These rotations promote empathy and make you realise not only what works or not but also what might be right or not in your products and services.
A second way is to meet people who are already working on ethics in your organisation, and you probably have some if you work in a big organisation. Meet your corporate social responsibility team, meet your ethics and compliance ambassadors who will certainly have some information to share.
The last tip to build a definition of right is to check the statement of values or code of ethics of your organisation. On that note, I should say that, at least when looking at what’s publicly available, these statements can be pretty vague and include values like “being respectful”. I personally don’t think you can really use that to make concrete decisions in your products and services. What does it mean to respect someone? Does it mean to give them what they want as I mentioned before? Or does it sometimes mean not giving them what they want? I encourage you to have this conversation in your organisation and to think, specifically in your industry, what is the definition of right.
Don’t be a Robot
A second key devops principle is automation, which is very often misunderstood. And ethics is a great opportunity to avoid any confusion. People can be reluctant to join an agile or devops practice because they believe they would not be able to think about anything else than the next iteration. They would constantly have to catch up with the next iteration, do what the processes say and follow what is automated. They would basically have to work like robots. It is a shame because devops should be the opposite, it is about automating as much as possible tools and processes SO THAT you can focus on high value activities.
Let’s take technical depth. Devops is not about developing one user story after the other and not thinking about the consequences. It is, when you get a new requirement, to wonder if your current architecture is fit for purpose, to ask yourself if your CI/CD pipeline has the right steps so that you can guarantee the sort of service level attached to your new requirement. It is also about having monitoring tools so that you can have a sense of how healthy your practice, your architecture and your infrastructure is. It is based on your own personal judgement and these monitoring tools that you can then make important decisions, and have the courage, and the term is important, have the courage to refactor things. It is this courage to refactor that is really your added value as a human being.
Reduce your Ethical Debt
Once this is clarified, what I call ethical depth is much easier to handle. Ethical debt is like technical debt. It is not something you can plan in advance with some architecture diagrams or big statements, and then consider it done. It is an ongoing process, something you always have to keep in mind. I don’t think it is helpful to ask teams to foresee any ethical consequences of innovative products and services they are developing. Very often, we develop things not knowing exactly where we go, we see that some things work and we invest more energy in them. The more we invest energy in them, the more we might realise that something is not right. Ethics takes time, it cannot be all planned in advance. It is to have the courage to pivot when necessary.
So how to measure your ethical debt? The best way is to listen to your stakeholders and users. Listening is not easy. It is frequent for agile teams to not listen to their users but gather data: ask questions based on scripts, tick boxes and not really listen to what people say. What your users and stakeholders have in mind is not always their self-interest, they can have opinions about how their ecosystem works, about what is right or wrong. An easy way to get into that conversation is simply to ask at the end of an interview not only if the solution you provide works for them, but also if your solution is right for them, and people around them. Asking these questions will encourage you to listen and embed ethics in your regular feedback loops.
Another way to measure ethical debt are team self-assessments. Is your team convinced that what they are doing is right? It might work, it might please their stakeholders but they might not be convinced it is right. Instead of using the classical retrospective format of what worked / didn’t work in the past iteration, try using a slightly different format and ask your team what was right or wrong in the past iteration. This conversation is important because it not only can help your team align on their values, but it can also help your team better communicate what they believe in to their stakeholders . Your stakeholders, whatever the official discourse of your organisation is, won’t always base their judgement on finances and return on investment, they will also base it on how much they trust your moral compass. By following these few tips, you not only embed ethics into devops but also encourage a mindset that can only benefit devops as a practice.
The last principle from devops that I would like to borrow and use for ethics is to not start by making big reorgs. Don’t think ethical dilemmas will magically disappear with a big reorg. It’s about starting small: thinking about the small things you could embed in your day-to-day practice that could make a difference. Once some have proved beneficial, you could consider making more fundamental changes in your organisation.