As we’re working to build the best possible software engineering solution, we encounter many decisions we must make. Daily. Sometimes this involves very active and passionate conversations, which might sometimes go down the negative path, creating a bad atmosphere in the team. On top of that, it’s a huge waste of time. But what if those daily decisions could be much easier and simple? In this talk I’ll try to attack and eliminate the pain points of decision making in software engineering and will show how I helped my team benefit from a lighter decision making process.
The Game Theory of Software Decision Making
Transcription
Hi, I'm Siv. Thank you for joining my talk today about the game theory of software decisions. I hope you could take some tips on how to create a more productive team environment while tackling the day-to-day challenges with decision making. So a little bit more about myself. I'm Siv Levy. I've been working at Wix for the past five and a half years. I'm also a DJ. I mix dark 80s and techno music. You may find my live DJ sets on YouTube. Enjoy it. And I'm also volunteering as a paramedic first responder. And I will expand more on that later today. For those of you who are not familiar with Wix, Wix is a platform for website building for a variety of type of users, whether you are an advanced developer or a newbie, Wix gets you covered with great features for your business and online presence. So I'm part of Wix engineering group. It's a group of very talented engineers, but also, as you may see here, very diverse in many, many ways. And you know, it's OK because we are all human after all. Within my work at Wix, I was lucky to start a brand new Wix products. OK, I did it. I've done it multiple times and for multiple types of users, whether they are users of the company or internal users. Starting a new product from scratch is a great adventure, actually, for every developer. And it brings a lot of challenges and also a long and long with uncertainty. In these moments, people tend to get overwhelmed and that affects directly on their judgment and their ability to make decisions. Let's break out for a moment and talk about game theory one on one. Game theory is a mathematical field which tries to maximize gain or benefit over contradicting situation between two or more factors, usually called agents. It defines a wide range of social and behavioral relations, as well as the science of logical decision making in humans, by the way, also in animals and computers. The main thing that I'd like you to take from this session is that you're not in a zero one game. OK, zero one game is usually when one wins, it means the other lose. Specifically, we'll focus today on the process of how to make decisions effectively and hopefully with less pain involved. It all came to me once I had an argument with one of my colleagues and this argument became worse the longer it lasts. And we finally left the room with very bad feeling, a lot of embarrassment and without any decision made. I thought to myself, God, how come this such unimportant topic needs this kind of attention? I mean, it's a total waste of time. Something must be changed. I don't know. So let me take you to another aspect of my life. Besides coding, I'm also a paramedic. I volunteer as first responder and I'm ready to be dispatched 24 7 for any medical incident around me based on my location and availability, of course. Why am I telling you that? Because every week I make life and death decisions, literally. And I will tell you something about, you know, fatal trauma injuries. You really have just a few seconds to make the hard decisions. So how come I'm able to make life and death decision within seconds or minutes and on the unimportant stuff, you know, unimportant, I allow myself to argue over and over again and waste so much time. Now, I know what you're thinking, you know, it's not the same, right? But and you may be probably right, but what if I can use the same skills and methodology of decision making in the medical field and apply them on the software field that I'm doing on my day job? Let's see what my decisions are based on. So I have my training and protocols, OK, in every field. I always use my past experience. OK, the more I have, the merrier. And I look ahead on the main goal. What is the main goal that I want to achieve here? The main difference between the two situations is the fact that software based systems are virtual. OK, so by nature, the requirements is always the requirement is always changing all the time. And it's not like any other product that we ship from the factory to the shelf and that's it. So the naked truth here is that only in retrospect you know whether you made a good decision or not. You see in any other engineering field as well as medical science, the requirement is constant, while in software it's constantly changing. OK, so after realizing these principles, let's go to the second phase. So the second phase in an argument is we need to know how to let go of the stupid things. OK, and I know that for some people, stupid thing might be the most important thing and vice versa. But I'm really trying to, you know, lowering the level of drama. So if the person, if the person I'm, you know, if the other person proposes best practice A and I'm proposing best practice B, then what the hell does it matter? We both want what's best. And that's what's important. I mean, any decision that will be made is much better than wasting time and keep arguing with each other. OK, nevertheless, we have this little thing that's called ego. OK, and this ego takes us to so low places like tabs versus spaces. Let's see some example of it in my next slide. Come on. Oh, my God. Your roommates are right. You really hate spaces. No, no, no, no, I don't. It's not hate. Hate's a strong word. Truth be told, I do have a slight preference for tabs, but that's only because I'm anal and because I prefer precision. Well, not to pick a fight here, but if you really care about precision when you use spaces, but whatever, once it goes through the compiler, it's the same thing, right? Yeah, yeah, technically, yes. I guess I just I just don't understand why anyone would use spaces over tabs like if it's all the same. Why not just use tabs? Because it could look different on other people's computers. Tabs create smaller file sizes. All right. I run a compression company. Trust me, I've devoted my life to minimalizing file sizes. It's what I do. I mean, I do not get why anyone would use spaces over tabs. I mean, why not just use VIM over Emacs? I do use VIM over Emacs. Oh, God help us. OK, you know what? I just I don't think this is going to work. I'm so sorry. I mean, like what? We're going to bring kids into this world with that over the heads. That's not really fair to them. Kids, we haven't even slept together. And guess what? It's never going to happen now because there is no way I'm going to be with someone who uses spaces over tabs. Richard. All right. So, yeah, this was like a scene from the great show, The Silicon Valley. So Richard here broke up with his girlfriend over this, you know, old, very old and stupid argument. So you have to be transparent with the other side. OK, maybe even before starting to discuss the issue and define whether the issue is critical one or not. And what why is it so painful for you? Why do you even care? OK, in any way, just try to leave your ego outside. Let's take another example. OK, let's take the following code. This code was written just a few weeks ago in my team. Yes, my team and I are not, you know, not innocent. And we're having the same problems from time to time, even though we are all experienced and we are working together for quite some time now. But it still happened. So here we are looking on two ways to achieve the same functionality, which is to call a function create item and get a new item instance as a result. While the first the first option is to call the function and putting all the parameters one after another, the second option defines an interface which owns the exact same properties and the given request parameter for the function should be should comply to that interface. Now, we're not we do not have time to dig in which one is better. So I'm not going to discuss it right now. But you're probably familiar with this kind of coding dilemmas that sometimes even, you know, rising in a code review process. And those dilemmas can lead up a passionate discussion that quickly escalates to an entire team rumble. OK, and this is exactly what happens in my team just a few weeks ago. And it was over Slack. OK, with more than 50 messages around this issue. So imagine that. So again, what I want you to take from this session is how to spot those moments and to either win the game or avoid it in the first place. What I found working to reduce the level of drama around such issues is to ask myself two main questions. One is whether this is reversible. And the second is how fast can I know that I made a mistake, OK, that I made the wrong decision. Now, if the issue is reversible, OK, I mean, if the decision I make and implement the code by that decision is reversible, then good. Problem solved. OK, no need to emphasize over and over this same discussion. And if it is not reversible, well, I'm really doubt about that because I'm not familiar with almost any kind of software field that is not, you know, cannot change the software by over the air update or whatever. The second thing is to define a fast point. OK, we need to know what would be the KPIs, what will indicate us that we made a good decision, a wrong decision or a good decision also. And also we need to be to own a back out strategy. It means that if we consider two or more approaches and we picked one and we probably guess that we might want to switch to another one. So we want we need to have a back out strategy. So the transition will be, you know, as seamless as possible for users in case the decision is implemented and on production. Another lesson I'd like to share is that if the issue is critical and you don't get to a decision within 10, 20 minutes, maybe a bit later, but, you know, try to bound the argument in a certain time frame. So if you don't make a decision within this time frame, just consult the jury. OK, this jury should be someone you're all agree on and appreciate their knowledge. And by the way, it should not be the manager or the team leader or whatever. OK, don't put them in this awkward situation where they have to choose between you or someone else in the team. OK, it's not their job and it's unpleasant for everyone. Also, I want to emphasize some meat around seniority level. Now, being a senior in a team doesn't mean that the decision is yours to decide. The decision is yours to make. OK, it means that you are the team advisor. OK, you can provide some more insights based on your real experience. And if you are not experienced with a specific problem or topic, then you're not just as better than the most junior developer in the room. OK, for example, I have more than 10 years of experience and I've never dealt with garbage collection. So I have no input in this kind of discussion about the performance of garbage collection. In other cases where the issue is not that critical, such as code quality or code conventions, we set up a weekly meeting for the team to suggest and discuss those topics. OK, sometimes this even meeting becomes like a venting meeting, a discussion around some other stuff. We always tend to try, you know, make it with some drinks around so the atmosphere would be like in a good one. And, you know, if no one proposes any topic, then meeting is cancelled for this week or for this month. So it really helps to coordinate stuff. We are about to finish this session, so I want to finalize what are the game rules here. So be fast, OK, adopt a faster process and follow your intuition. OK, remember that you're not in a zero sum game. OK, everybody wins here. All proposes are correct in some way and you just need to understand what are the tradeoffs. No ego, OK, leave your ego outside. Players with ego never wins. Try to stay rational, OK, bring rational point of view, OK, be technical, bring the data, use the data for your argues and call a jury, OK, let someone else decide. It's always much easier and remain a pro. OK, remember that when you're arguing with, you're arguing about professional issue with some of your colleagues, you must stay professional. OK, don't go personal with them. Don't tell them what to do. OK, in a bossy manner. Don't tell them what they can or cannot do. You know, sometimes people think outside of your box and that's just because it's not, it doesn't fit your box or you don't get to the bottom of their thoughts. It doesn't mean it's not a good idea. And the last rule of thumb is consider yourself on a first date. OK, in a first date, you let go of the non-important stuff or else you won't have a second date. So you should do exactly the same here at work. OK, just consider yourself on a first date. Be a gentleman, be polite, whatever, and maintain cool. And that's it. Thank you. I was Zeb Levy. I have a lot more to share. I'd be happy to meet you and chat with you more. Feel free to ping me also on Twitter, underscore Zeb Levy. Thank you.
