gien-verschatse-slow-down-to-speed-up-your-decision-making

[00:00:04] Ah, there I am. All right. Hello everyone. Hello my friends. I won't be doing the talk in French um because that would be unbeneficial for all of us.
[00:00:19] Um, I might talk a little but uh not that great. I wanted to start with a show of hands. Whoever heard this, we used technology X once and it went horribly wrong, that is why we can't use it in this project. Who has heard that or something similar?
[00:00:39] All right, a few.
[00:00:42] What about this one? My previous project used technology X and it went great. Let's do the exact same thing. A few, a few more hands. Yeah, that's what I often um get when I go to uh companies.
[00:00:59] The truth is we're not that great at making decisions. So picking a technology is making a decision, and what we actually do is just not think about the circumstances of this company, we just try to do something that already has been done before. So, sorry, not sorry. Um, but today I am here to hopefully uh teach you a bit about decision-making and how to do it a bit better in your company or for yourself personally. The talk is called slow down to speed up your decision-making and by the end of the talk you will understand why you have to slow down in order to speed up. So, hello. My name is Gene. I'm from uh Belgium, the Dutch part. Um, I'm a consultant at Artlin and before that I was a software developer for 13 years. I also co-authored a book called collaborative software design with Kenny and who are uh supporting me there in the fourth row today.
[00:02:06] And so, as a consultant, I get brought into companies often when things aren't that great anymore. And they tell us, we want to move to microservices and we want you to help us design the microservices. And then I, you know, start gathering information and looking around and trying to figure out what exactly are the problems that they're trying to solve. And often it's because they have a, you know, some some monolith that has gotten too big and they don't really understand the boundaries anymore.
[00:02:42] So they want to get uh rid of it and start over.
[00:02:47] And then I have to say, I'm sorry, but that is not going to solve your problem. Because your problem isn't that your monolith doesn't have, you know, great boundaries anymore. It's for example that you don't know how to um divide your teams or how you
[00:03:09] actually what is important to the business, you're not talking to the business part of this. You don't understand how this company makes money and so you don't really understand what a good software system actually should look like. So just saying we're gonna move to microservices is not going to solve your problem.
[00:03:30] And the reason for that is often because we're not taught how to think about these type of decisions. And it's a decision that you have to make. And when I was working as a program programmer myself and now as a software consultant, I often see that people don't, you know, fully understand how to how to tackle this. So they just do something that kind of feels okay and move forward. And I was very, very frustrated by that. Especially when I had to sit in meetings and we kept talking and talking and nothing happened and everyone had opinions, but there was like no way forward. It was a pretty mess. Um, that is called a participation uh theater where everyone really participates in making the decision, but no decision is actually made. So I went back to the beginning. And I actually wanted to figure out, okay, what is a decision? I think most of us will be able to give us a definition. But I started looking at other industry and I ran into a friend of mine that studied economics and he said actually in there there's something called decision-making theory. And we get taught about what a decision is. And now that we're in the software, he said, I'm also very frustrated because people don't really know all of this. So I started digging into it.
[00:04:59] And I now call it a topic that has gotten severely out of hand. I used to say a little out of hand. But I'm now giving talks about it so I think it's gotten a bit worse than that. Because I do want to help improve companies make decisions. I don't claim to be an expert in making decisions, uh far from it. But I have learned some things along the way that really helped me and I'm going to share them today with you and I hope that they um help you too.
[00:05:27] So I'm going to start with a boring definition. What a decision is. So it is a choice between two or more alternatives that involves an irrevocable allocation of resources. And there are like two very interesting things about this. It says a choice between two or more alternatives and an irrevocable allocation of resources.
[00:05:51] So it is an alternative, it's something that actually leads you to a different future.
[00:05:58] Because let's imagine that we have to pick a technology to uh, you know, enable logging in your system and both do the exact same thing, then there's really no decision to be made. So they need to take you to a different uh future.
[00:06:19] And the thing is what people often don't realize is that we need more than one option in order to be able to compare them. So we need those two or more alternatives. And especially when it comes to designing, even when we're doing creating domain models for example, to put into a code. The first thing that we can come up with, that's the thing that we use. And we're not really deciding because we only had one option there.
[00:06:49] Not deciding is by the way also an option. Uh the problem is that time will decide for you most of the time.
[00:06:57] And the second is the irrevocable allocation of resources. Now that's a very economical way to express um, you know, money, time and people basically. I don't like the word resources, but if you look into economics, it's everywhere. And I kind of like this concept in my definition because this what this means is that, well, if you're wrong, there's a cost. You dedicated time, people invested their time into it and it costs some money. But the fun thing about this is that I now have the liberty to change my mind and all I have to do is pay the cost. And move forward.
[00:07:46] If you want to make a decision, what needs to be there exactly? So I started looking a bit, this a model not the model uh of a decision. But for me, um, if you want to make a decision, you need a decision maker. You need a frame, I'll talk a bit more about that one later. We need alternatives, you need the two or more options definitely, we also need information often and we have uh preference. And then there's some sort of process, some sort of logic that actually tells us which course of action that we should take.
[00:08:23] And so, who is the decision maker? Has anyone ever been in uh a meeting where they're like couldn't figure out which option to go for and everyone always changed their mind?
[00:08:38] Again.
[00:08:41] If you think back, was there a person responsible to make this decision?
[00:08:50] Yes, no.
[00:08:54] Often there is, we have team leads and things like that. But a decision maker for me is someone who has the authority, the commitment and the permission to make the decision. And the authority basically means that, well, probably somewhere in their job title, they will be allowed to make this uh decision.
[00:09:13] If you're team lead or if you're tech lead, you can make uh technology decisions. If you're an architect, you can make design decisions, things like that, so you have that authority from within the company. The commitment is personal. Is this person willing to make the decision?
[00:09:32] That is not always true. So they need to be committed. And the last one is permission. Does this person, from the other people who are affected by the decision, actually have the permission to make that decision?
[00:09:48] I worked in a team and it was I think probably around 10 years ago and we had a team manager. And that person was not very well liked, they had very strong opinions, but they hadn't programmed for 15 years. And they kept making decisions on our behalf. So this person did not have our permission to actually make these type of decisions.
[00:10:17] So that's why define a decision maker like that. And very much when decisions aren't just being made, it's foiled or you're sort of like keep getting back to them, to them, it's because, you know, one of those three things is missing from the decision. I remember that I had a friend and they came to me with a problem. And I was very enthusiastic about it. I was like, oh, here's what you can do, you can do A, you can do B, you can C. And I think you should go for B for this, this, this and this reason. I sort of explained my entire decision-making process. And they got very angry at me for doing that. Uh because I was definitely committed to make the decision on her behalf. But I did not have the permission and I definitely did not have the authority to do that. So even in your personal relationships, if anyone ever gets mad at you, it's probably because of this and I've seen this happen quite a few times as well.
[00:11:21] The second one is the frame. And that's basically how the decision maker views the problem. How do we how do we look at this, how are we going to make this decision?
[00:11:37] Now, the hardest part of any decision is actually how you're going to frame this problem. How are we going to look at this and it's also the part where we spend the least amount of time. So the question of first has taught this morning was very valid, what is the problem we're actually trying to solve? And very often that question gets sort of ridden over or ignored, or the problem gets framed in a way where there's already a solution in it. So we should spend some time there.
[00:12:09] We should slow down and look at what exactly is the problem, do we understand it, do we have enough perspectives on it?
[00:12:21] And the first I'm gonna, my my water is behind uh the scene.
[00:12:28] Okay.
[00:12:31] So, the first problem you have to, the first question you have to ask yourself is, is this a problem? Or do we have a polarity?
[00:12:42] Because not everything in life is a problem that needs to be solved.
[00:12:48] So what is a polarity? It is basically an ongoing issue or challenge that has no clear solution in terms of picking one over the other. It's a choice between two or more alternatives from my definition, that's not there. Like if we want to, if you're going to say which restaurant are we going to uh choose tonight? Then you'll have a few options and you will pick one and you will move forward and that is a problem that you can solve.
[00:13:16] But for example, if we're talking about we have to do we want to do collaborative modeling in our company, but we also have to, you know, code so that it can go to production, that is actually a polarity.
[00:13:30] Because it's and people keep asking me like, how much collaborative modeling should we do, when can we start coding as if it's a problem to solve? And I'm like, no, it's it's not one over the other, it's something that you need to do both and you need to go back and forth uh between. So polarity is not something that you can solve, it needs to be managed.
[00:13:53] Thus have the local complexity versus global complexity in software system. It's not something that you can solve. It's something that you need to manage and make sure that both are in a fairly good uh balance there.
[00:14:06] How much power, how much decision power the team has and how much you can decide on your own is also a polarity, something that you need to manage. There will be new situations that come up and that you need to discuss. And sometimes you notice that actually deciding um this type of uh technology as an individual isn't really working, we need to move that to team and then we need to move some things to individual. So all of that, they're polarities. There's a fun map uh for that, I'm gonna look a bit closer that actually helps you do this in a team context. that you managed. That's how the local complexity versus global complexity in software system. It's not something that you can solve, it's something that you need to manage. and make sure that both are in a fairly good balance there. How much power, how much decision power the team has and how much you can decide on your own. is also a polarity, something that you need to manage. There will be new situations that come up and that you need to discuss and sometimes you notice that actually deploying, um, this type of technology as an individual isn't really working. We need to move that to team and then we need to move some things to individual. So all of that are polarities. There's a fun uh map uh for that, I'm going to look a bit closer, that actually helps you do this in a team context. So, um, you have the left and the the right, right, of the polarity, whichever one um you're trying to manage, so we have collaborative modeling is good. For example, and then we fill in the positive effects of everything on the left and the positive effects of everything on the right. And the reason that I start with the positive is because it's very easy to say negative things. Wherever we go, I'm the same thing, the same way, I think it's sort of how our brains get trained, we're there to see problems, we're very good at critiquing them and see the negative consequences of something. And the positive is a lot harder, so that's where I started, I started with the hardest part. And then I fill in the negative effects and the negative uh of of the left and the negative effect of the right. And as you can see, there's an infinity symbol in it. Which means that if we do something for too long, like if we do collaborative modeling uh for too long, or if we put too much on a team level when we're trying to make decisions, we'll actually really start experiencing those negative effects. And what we then need to do is actually move back to the other side. If we start coding or we move some things to individual decisions so that we then can enjoy the positive effect. And what we want to do is experience those those negative effects, you know, as the least often as possible. And there are some signals and observations that you could do with your team. That you can say, okay, what we're starting to notice this, that actually means it's time to move to the different pole of the polarity, it's time to start coding or it's time to go back to collaborative modeling. And then there are some actions that you can take. You saying that, oh, we'll schedule a 30 minute session to do some collaborative modeling there when we notice that coding isn't actually working, we're experiencing too much negative effects. So I fill this in with the team so that everyone is um on the same page and then we see how we can uh manage those. Okay. I could tell a lot more about polarity and polarity management, um, but decisions is about uh problems. So the question I have is what can you do with the problem?
[00:17:05] You can solve it or you can make it irrelevant.
[00:17:10] It means you don't have to solve the problem anymore because it doesn't matter. Making something irrelevant is very difficult, it's not that easy.
[00:17:21] One of the sort of stories in the decision making circles is about an elevator in an apartment building that they got a lot of complaints that the elevator was just too slow. And so they got a bunch of engineers into one room to solve this problem. And they were looking at ways that they could speed up the elevator.
[00:17:45] And then someone else came in and looked at, oh, what they actually are doing, are trying to speed up the elevator. And they said, well, actually, what if people don't notice anymore that the elevator is slow? So what they did is they hung up mirrors next to the elevator because when we can look at ourselves, we perceive time a bit differently. And so people simply stopped noticing that the elevator was slow, it was still slow. So the problem was made irrelevant, it wasn't solved at all. And as you can see by the photos, I have seen this uh in the wild when I went to uh hotels, some tackle it with uh a good sense of humor. Hey, we know the elevator is slow, uh slow. And others sort of like, do really sort of make the elevator a bit of a party, um, so you wouldn't notice um how slow it was. When I look at software, I think the closest we have in attempts to make a problem irrelevant, especially when it comes to big balls of mud and um, you know, well, uh ill-designed monoliths is the Phoenix project. We're not trying to get better boundaries, we're not trying to get better modularity, we're not moving to microservices, we're just starting over. They don't end well most of the time because well, you're also creating a mess inside that new codebase and you sort of never quite catch up. Um, so I don't recommend it, but if you think about software and software development, this is the closest I can see to making a problem irrelevant there.
[00:19:26] Okay. So then, if you want to make a decision, you have to ask yourself which type of problem do I exactly have? And I have for you a few models that will help you reason and explain problems to your colleagues and to higher management. I really like this one, it talks about the role of fact and judgment in a problem or a problem that you're trying to solve. When the role of fact is very high and there's basically no judgment needed, we talk about simplistic problems. This means there's only one answer that is actually determined by fact. For example, what is F sharp, what is low cone, is the fact the conference. I don't know if you know F sharp, it's a programming language which I was very fond of. When I discovered it.
[00:20:19] Then the second one is deterministic, fact still has a role in it. But there's one answer, but it's determined by some sort of formula. If we look at calculating the velocity or when we're scrum, there's some sort of formula and then we get an answer of that. So that's a deterministic problem. We also have random. Where we have different answers and all are possible, but all are identifiable. And when you're picking a technology stack, you're basically solving a random problem.
[00:20:54] Because if we try really, really hard, we really can name all the logging libraries in Python, for example. I'm not saying there's a good idea to do it.
[00:21:04] But we could do it. So it's a random problem.
[00:21:09] When we're thinking about software design and how to create domain models and how to put those domain models in our code. We're in an indeterminate problem. Because there are different answers, all are possible and not all are identifiable.
[00:21:27] I've said domain models is the best example. And I think that's really important because people often ask us, why is programming so hard? And I would say, if they're just writing some code, and I would say just coding, yeah, it's probably not that difficult, but programming is more than just coding. It's about understanding, trying to get that domain knowledge, see how I can convert that into a model that actually helps them solve the problem and then convert that model into code. And it's an indeterminate, it means that judgment is very high. We have to sort of try to assess ourselves whether or not what we came up with will be useful right now and for the future. So if people are saying, why should we try to um dedicate time to collaborative modeling, why do you want to talk to your business analysis, why do you want to talk to the business as a whole? Let's say we're trying to solve an indeterminate problem, and that is actually quite difficult. Because judgment is very high and the role of fact is almost non-existent. So I find this a very helpful model to sort of communicate why some things in our industry are hard and why some things are actually um rather easy like the difference between coding and actually programming.
[00:22:53] The second one, um, is a way of looking at uh problems. Sometimes, if we look at it, there's this mess or a pain point that we notice and we're sort of trying to figure out what it is. So we're trying to uh determine what is the problem exactly because we're not sure. Which is not an easy position to be in, we just feel the pain, but we don't know the cause.
[00:23:22] Sometimes, we actually try to achieve something and we're not quite sure how to reach it. Maybe we are aware, we know where we are right now, we know where we want to go or we have an idea of where we want to go. But how to get there is a total mystery. If we're looking at redesigning software system or or refactoring some parts of the code, often we are in that second problem, how do we get there is a total mystery. And so we need to sit down, think about what do we want it to look like and how can we find a path from where we are right now to where we want to be. Also not something that that easy to do.
[00:24:04] And the last one, and is my favorite because it's funny, uh, not because it's helpful. But is that if someone has a solution they fell in love with and now they're looking for a problem. to solve with it. what problem is the eye we're really solving here and we made a tool and now you're going to have problems. And when we're talking about a uh hype and and following trends, we often we're in that last one. I have done this, I have, you know, um, fallen in love with this solution and then try to find a problem so I could use it at work. So if you, if you look at this, if you show this to to people like if you have a, you have a bug, but they're the pain points in inside your system and or there's a bit of an ill-defined mess there and you can't quite figure it out, um, or if you're trying to redesign something or refactor something and you don't really know how it goes, um, or if you're trying to make people laugh while also saying that no, we're not going to do that because it's we don't have a problem, then actually you need the solution for that. If you're trying to make people laugh, while also saying that no, we're not going to do that because it's, we don't have a problem, then actually you need the solution for that, then you can show this to people and it helps a bit to communicate and to make them understand better how you should deal with everything.
[00:25:24] So I already said it a few times, what exactly is the problem that you're solving? So in order to do that, we need a problem statement, something that explains what is wrong. And that's not an easy thing to actually formulate quite correctly.
[00:25:40] There are a lot of pitfalls when we're trying to do that. The first pitfall is that there is no focus. So how can we fix our big ball of mud? How can we fix the bad architecture? How can we improve that architecture?
[00:25:54] There's no real focus there in this problem that we're trying to solve. Do we want to look at the entire system or do we want to look at the most critical parts? Where exactly are the things, you know, the most painful for us, is it the most painful for our users or is it the most painful for our developers? So how are we going to do this? So there's no focus and there's so many questions, we actually need to formulate that a bit better and look a bit deeper into it and then settle on a problem.
[00:26:28] that we want to solve and that is defining that frame. as a decision making. How wide are we going to look at the entire software system or how narrow we're going to focus on the most important parts of our software system. How are we going to readjust that thing? The second pitfall is that the focus is driven by assumptions and by solutions. How do we move to microservices? Microservices is very much a solution that is trying to solve certain problems.
[00:27:01] And by adding the solution already in here, we're eliminating the options, we no longer have those two or more alternatives that we need in order to make a decision. There's just microservices, we're already done, so also not really a decision to be made.
[00:27:19] you know, unconsciously already made it.
[00:27:26] And how you state the problem is very important because it will influence the outcome. It determines how you look at it, which type of uh options can I actually come up with, is going to be determined by that and therefore, which type of outcome am I going to get once I select one of the options. So we really need to spend a bit more time there, play with the problem basically.
[00:27:51] We can restate it by paraphrasing, how do we convince people to do domain-driven design? It's a question I get a lot. Um, but you can also say like, how can we make our team enthusiastic about doing domain-driven design? Which is a very different sentiment in those two questions. If we're talking about how can we convince versus how can we make them enthusiastic, you will come up with very different options to actually fix something.
[00:28:20] The second is that you can redirect the focus. How can we fix our big ball of mud? is how can we increase the user experience? Because the users are feeling our pain, feeling the pain of not having a well-designed software system. We actually focus on the user experience instead of just trying to move to microservices or trying to redesign our monolith. So we redirect the focus completely and we will come up with different options with different ideas because of that. And the last one is ask why. It's something I have to do very much as a software consultant all the time. It's also something that five year olds do very much and somewhere between being a consultant and being a five year old, people have informed me that it was not okay to keep asking the question why.
[00:29:16] Um so I had to relearn that bit. But basically say we want to move to microservices, so it's a solution-based problem statement. It's like, why? Well, our monolith has turned into a big ball of mud. Okay, so how can we re-establish the boundaries in our monolith? That's actually the question. The problem that we want to solve. Okay, but but why? Well, because we can't understand the code anymore. And then you said, okay, how can we actually regain the knowledge of our monolith? Because that is what we want to do here. Why? And you know, you keep going on. And as you can notice, we started with moving to microservices and we ended up just by doing it three times, maybe you have to do it a bit more, to actually want to regain the knowledge that was lost in our software system. Again, two very different problems.
[00:30:06] And most of the time when people want to move to microservices, it's about lost knowledge and trying to regain it and trying to be able to have control over it again so that they're not uh that lost. There's a very fun, well, I find it fun, reframing canvas. that you can fill in, I didn't put it in a canvas. because I feel that the canvas doesn't really add any value. But there are a few questions that you can ask yourself when you're trying to sort of define the problem that we're going to solve. What is the problem? Who is involved? What are we missing looking outside that frame? You can determine it and say, okay, but what else is there? Because maybe there's something outside that frame that we can do, which makes it irrelevant. it's about lost knowledge and trying to regain it and trying to be able to have control over it again so that they're not that lost. There's a very fun, well, I find it fun, reframing canvas that you can fill in. I didn't put it in a canvas because I feel like the canvas wouldn't really add any value, but there are a few questions that you can ask yourself when you're trying to sort of define the problem that we're trying to solve. What is the problem? Who is involved? What are we missing? looking outside that frame? You can determine it and say, 'Okay, but what else is there?' Because maybe there's something outside that frame that we can do, which makes it irrelevant. Rethinking the goal. Is there a better goal to pursue if we say we want to improve our user experience instead of saying we want to have micro services, maybe that is a better goal to pursue. Examine the bright spots, what are the positive exceptions, like which part in our code base is actually easy to deal with. You try to look at the positive things because we often just talk negative about uh or us our monolith and you know, we have nothing to do with it that it's all messed up now. So what are some of the good things about this? very important. Look in the mirror, what is my role in creating the problem? How I have, how have I contributed? Is not something we often do. Or I have been responsible for creating messes in code basis. Or I'm responsible for making bad decisions. Um so how have I contributed to this? And what problem are other people in our company trying to solve? Look at what is about the team and how to get to production. A bit better, but maybe the team next to me is trying to solve a different problem and maybe they have a better understanding and and we can actually learn from each other. If we say that, well, our our product manager or product owner is never available for us or they won't listen to what we tell them, we have no input in making decisions. Okay, but what are their problems and what are they trying to solve?
[00:32:25] And can I some somehow help them solve their problems, which would make it a bit easier for me as well. And so I find it's very helpful in getting the frame right as a decision maker. Okay, so we understand the problem a bit better. Now what? Well, now we need information.
[00:32:54] And so this is one of those three things I said that went into the process of making a decision.
[00:33:01] When I try to redesign a software system, I use collaborative modeling to get that information. I try to understand the business processes. I try to understand the rules and the policies. I try to look at the user journeys, which workflows are there. And I do that together with the people who actually have this knowledge. Which most of the time isn't me, because what I understand is how the software system works, but that is not necessarily reality. And so I want to sort of get it from the person that knows the best. So I organized a collaborative modeling session there. There are a lot of tools that can do that. Let's all give you a easy. The thing I have is that it has to be simple. I don't want to explain for one hour how the tool works before I can start using it. So it needs to have easy access for everyone involved. And it needs to be visual. And that's also one of I'm a very fond of visualizing things, writing problems down, writing options down, writing my analysis down, making everything very visual. We have event storming, domain storytelling, user story mapping, example mapping, all that kind of stuff. I also go look at different industries, like I often use the business model canvas to understand the company. What are the goals, how do we make money, who are our customers? Because I also need that information when I'm trying to redesign the system because that will influence my options there. So any tool can be done. And then the question is, yeah, but how much information? Because I can't I can keep doing this forever.
[00:34:48] So the moment certain information doesn't change your mind anymore, it's kind of worthless. It's too much time and too much money because our time is paid, I think, for me, that we're investing right now in trying to make this decision.
[00:35:05] Um, so I stopped there. It's not an easy thing to assess. And sometimes you'll spend a bit of time and then you realize, oh, actually the information I'm getting right now is actually not changing my mind anymore, it's not useful anymore. Um, so then we stop. So we also do a bit too much information. But uh, not enough. I already said that we need to options and the alternatives. I didn't say when I design a software system, how exactly I I got there.
[00:35:48] Let's do get the tension up in the room, like, oh, how does she do it?
[00:35:55] So I designed alternatives. It's something I have not seen done many times in companies. They come up with one software design and that's it. They call it the to be. And they don't make more options than that. The same with when we're designing our domain models for code, when we're looking in the team, we're trying to figure out how can we put that in our code, we design it one time.
[00:36:24] And we one thing, and that's then the solution. Unfortunately, these solutions does not exist. There are many, many solutions and we're trying to find the most useful one for us. So like I'll do something that this, oh, actually this separates the back office, this actually separates payments. For now, even when we're redesigning a monolith. And the the fun thing is that once you have two designs, it is very easy to get more designs. So once you have two alternatives, generating more alternatives actually isn't that difficult anymore. And then you might wonder, but how many? And most of the time go for three.
[00:37:09] When I'm looking at, you know, we have to add, at some point with one of the clients, I needed to add an ERP system into it, and so I made three designs on how we could actually integrate it into it. And the reason for that is because I want to avoid an us versus them situation. And if you only have two options, then you can very easily, you know, get that divide, while if you have three options, the people are more spread and it does not become us versus them anymore. I don't know if you ever been in a conflict over which technology. Where you just have two groups and they were actually attacking the people instead of thinking about, you know, we're actually talking about the technologies. So I try to avoid that a bit, because that's a harder mess to clean up than redesigning a software system. And when relationships at work have form bad. How do I do that? I actually use heuristics. It's basically, it's again a very boring and very long definition. We know heuristics, we talk about them as a rule of thumb. But the reason that I do give you this definition of believe on cool, um is because so it's a plausible aid that will get you a solution to a problem, but is in the final analysis, unjustified, incapable of justification and fallible. So it means that the solution I can come up with might not be the correct one. But I do use design heuristic to sort of create my options there. The good news is that heuristics actually perform equally well as doing bigger analysis on problems. For example, um in the ER, they have a heuristic to determine whether or not someone is having a heart attack.
[00:39:09] And the reason for that is because if you're having a heart attack, you need to be treated very fast. And so they have a checklist and if you have six out of eight or something, they're going to treat you like you have a heart attack, even though they actually don't know at that point. And they discovered that it's actually more beneficial than running tests that takes time. So that heuristic saves more lives than if we actually would sit down and, you know, do more tests to see if this person is having a heart attack. So they're fallible, but don't necessarily give worse results. So I think that's a wonderful news.
[00:39:47] So what I do is I decompose into boundaries. I start with one of my collaborative modeling techniques, in this scenario, I was showing you an event storm. And then I started dividing into boundaries and I apply my design heuristics accordingly. For example, one of the design heuristics I have is that we put communication from external systems into a different boundary. And we got the payments out of that, the first option that payments separated. Redesign, I showed you that's how it got it. There's another talk on how to do the design very well. I'm talking about the decision part.
[00:40:30] Um, so I'm not going to go too much uh into how to design uh boundaries. As I mentioned, we wrote a book about it called collaborative software design. where you can read it all about how we use these heuristics to do it. And then the last thing we need for a decision is preference. You can use value-based heuristics here as well. For example, someone might care a lot about climate change and the environment and that might actually change their preference of the options that you have created. You need preference. Because if you don't care which future you're going to get, again, you have no decisions to make. You might as well throw a dart at the options and just go with that because you don't care. So we need preference. I was doing an interview a while back on facilitating software architecture decisions. Um, and I said something which I actually thought I hadn't said it in that sense before. I said, after 20 years in the industry, I have found a way to talk about emotions without actually talking about emotions. And that is what preference is about. You're trying to see like, why does this person really want to go to microservices? What is behind it and often, and like they had a bad experience with the monolith. Um, so they don't want to redesign the system into a monolith, because they're afraid that it will just end up as a mess again. By talking about preferences over options, I actually get to have information that we're not very likely to talk about. Because we do need to care about the decision, so that's not bad. So then we have some sort of logic. You know, to boil down to a single option, that needs to be there.
[00:42:28] When it comes to technology, I did a talk on that. I sort of tried to create a process that's um, is simple enough to do easy, but it's a bit more structured than how we pick technology stacks these days. You can find it via the QR code. When it comes to uh software design, I can use heuristics again. They they're really good at making fast decisions there. If you ever heard things like Occam's razor or Hanlon's razor, the laws basically on which system thinking is based. Then those are heuristics to make quick decisions because they shave off options for you. Um, so if we if two competing models both have equal explanatory power, it's more likely that the simple solution suffices. So if we create multiple domain models for our code, then we can actually pick the one, you know, if they have equal explanatory power, then we can pick the simple one and so we don't have to really think about the others that we designed anymore. We can also use heuristics for that. Or if we want to do a bit more of an analysis. Economics talks about probability at this point, but I didn't felt that was very helpful in software design. Um, I use the procon fix list. Um, basically it's a visual tool. It helps me think about, okay, what are the good things about this design and what are the negative things about this design. Um, but what makes it most interesting is the fix part about this. It sort of lets you think about how can we have those negative things have less impact on us.
[00:44:20] For example, if we're going to move to microservices and we're going to work in an event driven architecture all of a sudden. Then one of the downsides is that actually we've never done this before, we have no knowledge on it. And then one of the things we can do is you know, um, organize a lunch and eat where we figured things out together, or we can look into training and asking for budget, or we have budget in our team to actually educate ourselves. So we can make this negative thing have less impact. And I find that very helpful. You'll never turn it into something positive, but you can have it make it have less impact. And we don't really think about any of that, so how can we do some things that actually makes this better? And then when we do this for all our options, you know, we keep hearing in our industry, everything is a tradeoff. But people don't really know what the tradeoff is. And so if you fill this in for your options, then it's basically everything you're going to get from option one and nothing you're going to get from option B and that is the tradeoff that I'm getting with picking one design over the other. And it's very visual and it's very clear and everyone understand which tradeoff they're actually making when moving forward. I already mentioned it if you want to dive a bit deeper into that. Use the QR code. I'll publish my slides afterwards for that. And then when we do this for all our options, you know, we keep hearing, you know, in this tree everything is a trade-off. But people don't really know what the trade-off is. And so if you fill this in for your options, then it's basically everything you're going to get from option one and nothing you're going to get from option B, and that is the trade-off that I'm getting with picking one design over the other. And it's very visual, and it's very clear, and everyone understands which trade-off they're actually making when moving, um, forward. I already mentioned this, if you want to dive a bit deeper, um, into that, into the QR code. I'll publish my slides afterwards, um, that. So when to do what, when to use heuristics and when to do an analysis. Um, if you have limited knowledge and limited time, you can do heuristics. They don't use, um, worse results. If we have limited knowledge because your knowledge is always limited, um, but we do have time, you can do a bit broader of an, uh, analysis.
[00:46:23] And then the question becomes, how much time?
[00:46:27] And then I have to say, it depends, because I'm a consultant.
[00:46:32] But I don't leave it at that. I say more than that. From an economical perspective, it's okay to invest a million dollars into making a billion dollar decision. So if it's something that's actually going to cost your company a lot of money, it's okay to spend a lot of time analyzing the problem, trying to, trying to do that. And so if we have random and indeterminant problems where judgment actually plays such a big role over fact, we can dedicate more time, we can take the time to try and redesign our system, uh, there. Which links back to that model that you use and then you can communicate better as to why it's actually worth slowing down, um, for a while. And to really think about how are we going to approach this.
[00:47:32] The second way to look at this is asking yourself the question, is this decision an irreversible or a reversible decision? Um, so sometimes referred to as a one-way or a two-way door. Um, basically,
[00:47:50] but with our definition of a decision where we have, the decision isn't a point in time anymore, it's now a process that we're going through of designing, of getting alternatives, getting information, talking about preferences, about that process. And we know that if we pay the cost, we can change our mind. There are not that many irreversible decisions left for your team. If you are willing to pay the cost. And then instead of like, oh, should we change our mind again, you're just, are we, are we willing to do this, is the information, is the new knowledge that we have valuable enough to go back to analysis and see if we changed our mind, basically? So, I have good news that unless it's a decision that will bankrupt your company, which is irreversible,
[00:48:42] most decisions are reversible. And it's a very different way of thinking about it because it really sort of helps with stress and anxiety when you have to make these type of decisions. at work because I can't change my mind, I can be wrong about the option that I picked, I can reverse it along the way.
[00:49:06] And the reason why I said you're always working with limited knowledge is because of uncertainty. And it's not something that everyone used to, but every decision is made with a level of uncertainty. And sometimes that level of uncertainty is very, very, very low, and sometimes the uncertainty is very high. And again, when we're talking about indeterministic problems, because it's judgment, uncertainty is is higher than if we have a simplistic because I mean, I might get the answer wrong to the question.
[00:49:40] But I can easily, you know, fix that. And we need to learn to deal with that uncertainty, and we're not very good at dealing with it. I have a clairvoyant heuristic that I use, um, if I could ask a clairvoyant one question in order to feel confident making this decision, what question would it be? And I try to formulate that question and then I go find the information, see if I can find the information, um, to the, to that question. And the moment where I'm like actually would really want to ask anything anymore, is the moment I know that I can actually start eliminating, uh, options. In teams, I sort of invest in certainty. Um, so I start with them mapping from one to 10, how confident do you actually feel making this decision right then? And then at some point in time I ask again, and if I notice that, you know, confidence is no longer moving up, then I'm, you know, the information that we're getting is is worthless, and I should try something else or I should stop and start eliminating options there.
[00:50:52] So decisions can be easy or hard. If I want to pick an ice cream flavor, it's a very easy decision. If I want to buy a house, you know, it's a bit harder. Some things are very hard. And so uncertainty actually determines whether or not, uh, something is more easy or harder to make, if you have a hard decision to make, then you should spend some more time to it. Um, I do have friends that don't have easy decisions and even for ice cream, you have to think about it for five minutes and it's quite frustrating, so I try to introduce them to heuristics. Um, we'll see if that helps. We have reactive, a decision can be reactive or proactive.
[00:51:40] When it comes to software design and refactoring, most of what I have seen are reactive decisions. And that means something happened and now we have to respond. And most of the time, that's it, right? We have a big ball of mud and now we actually have to fix this, the code is not easy to refactor anymore and now we have to fix it. So most of the decisions I see in teams and software are reactive. Proactive works differently. It's I want something or we want something.
[00:52:11] Um, so now we need to make a decision in order for that to become a reality. And it's important to sort of understand which type of decision this is. Because if you're reactive, the amount of time that you have might not be the same as when you're in a proactive situation in a proactive situation, nothing is burning, so I can take more time. In a reactive, there's pressure, there's emotions, um, often people are getting frustrated, uh, things like that, you know, so I do feel it's valuable. And so it's not one or the other. It's more of a scale, basically, a more proactive or a more reactive. But as I said, software redesign, I have seen is always more reactive than proactive. And you should really, you know, look into your company and see what is the sort of the main default that we have for making decisions, are we in a reactive mode or are we in a proactive mode? And if you are in a reactive, ask yourself, how can we start changing that within my team, how can I actually start going for proactive decisions, because it's a much more relaxed situation to be in.
[00:53:24] And a decision can be good or bad.
[00:53:30] So, I have an example, it involves, um, drunk driving, but it's the best way that I can explain this. Um, so Laura had a lot to drink, but she decides to drive home anyway, she loses control over her steering wheel and hits a tree and is, um, injured. I think we all kind of agree that it is a bad decision. Okay. Second scenario, Laura has a lot to drink, but she decides to drive home anyway, she gets home safe without any accidents. I still think that we all agree that drunk driving is a bad decision.
[00:54:07] So Laura doesn't drink at all, then she drives home and she gets home safe without any accidents. Yay, good decision. And Laura doesn't drink at all, but she loses control over her steering wheel and hits a tree and is injured. And sort of this is the point where people sort of like, that's a bad thing because she got injured. Like, well, no, because she didn't drink, um, at all, and she drove home and it's, it's what we decide. So the bad news is that a good decision does not guarantee a good outcome. The good news is that a bad decision does not guarantee a bad outcome either. And when we're talking about good or bad decisions, what I notice is that people don't understand that you have a quality of the decision and then you have the outcome. And because we have uncertainty, there's no guarantees that we'll have that. So I try to judge the decision, which means were all the elements there with their decision maker, um, were they committed, did they have permission, was there a process, did they have more than a few options? And if all those elements were there and if we took the time, then we made a good decision and we're having a bad outcome because of uncertainty. And it also helps to reason, um, about it when you don't say that we made a bad decision.
[00:55:38] So that is what for me is a good decision, I kind of explained it there when I was looking at the other slide. So if all six elements were there, and we did a good job, it was a good decision, we just got unlucky.
[00:55:54] And I was trying to explain this and it's a bit difficult until I went into the poker world and how do they, you know, play poker and how do they make bets there. And I came across this term and it's called resulting. And it basically means equating the quality of your decision with the quality of your outcome. So you look at the outcome and you say, well, the decision was a bad decision, which wasn't necessarily true. And it's very important in poker that you can make the distinction between that. Someone might still have a better hand, but you made the right move. And so when you're starting to confuse the quality of your decision with the quality of your outcome, they call that resulting. So I'm very happy that I now have a word for that, and I can tell people that actually, the Mulaner was not a bad idea, it was not a bad decision, it's just that we had a bad outcome, and you are, um, resulting. So I do want to put Mulanelist back on the table as an option. I say it way more politely than that.
[00:56:56] By the way. And you might ask yourself, so why bother?
[00:57:03] And for me it's for two reasons. Having this, you know, decision as a process creates clarity. Clarity for me and my thought process, but also clarity for everyone else. I can explain what decision I made, which options I considered and why in the end I picked one option over the other.
[00:57:26] And the second one is consistency. So if you have this process, like I showed you the process of redesigning a software system where I use the heuristics to design options, and I use the pro con lists to sort of see what are better. And so if you do that, you create consistency within your decision-making process and you're always making it a little bit, uh, better. Because you now know where something was a bad decision and how to improve it. And so over time, you will see that the general quality of your decisions are going up, and so the quality of your outcome is also getting, um, better. Because we thought more about it, we didn't just go with the hype or with the latest trend anymore. And so I get consistency in my decision making. Which is why I can actually, um, you know, speed up, again, over time, you will find yourself making decisions in a similar, um, way. And that really helps.
[00:58:34] So thank you all for joining my talk. I hope you learned something. I am here until tomorrow around four, so please feel free to come and talk if you have any questions.
[00:58:54] One question.
[00:59:00] Thank you.
[00:59:39] how do I deal with, um, um, ego problems? Very gently. Um, and I'm try to have like an most of the time like I would do a one-on-one. I don't think, uh, things like that, there's always something at play and I try to find it, um, people being stubborn for no good reasons, I've often felt that that's not the case. We're back at those preferences, we're back at those value-based heuristics, we're back at the emotions, which we're not allowed to, to talk about. Um, so I try to have an open and honest conversation and really listen to this person, it's called active listening, we talk about it in the book a bit as well there.
[01:00:30] And see, you know, what actually is the problem here? Um, and also one thing that, um, if someone else makes the decision, like if it's not your preference that we're going with, what we often forget is that to ask the question, what do you need to to come along? Like, you don't want to re-evaluate this decision, it's failed, but what do you need to actually come along here with me so that we can do that? And then often you get some good answers, and you do need to take them into account, you can't just ignore everything that was said. Because I've seen that happen with bosses as well, they ask for your input and then completely ignore your input. So don't do that one. Um, but that sort of helps most of the time.
[01:01:21] Uh, to get a bit further. So yeah.
[01:01:24] So next session is the last two. Have a good lunch. We're in France.

Transcript