The Game Theory of Software Decision Making

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.

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 80's and techno music. You may find my live DJ sets on YouTube, enjoy it. And I'm also volunteering as 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 types of users, whether you are 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 we see here, very diverse in many, many ways. And you know, it's okay because we are all human after all. Within my work at Wix, I was lucky to start a brand new Wix product. 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 brings a lot of challenges and also along 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 situations 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. A 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 hours a week at 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 decisions 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, let's see what my decisions are based on. So I have my training and protocols, okay, in every field. I always use my past experience, okay? 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, okay? 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. Okay? 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 okay. 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, if the person, 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. Okay. Nevertheless, we have this little thing that's called ego. Okay. 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 space.

No, no, no, no, I don't. It's not hate hate strong word. Um, 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 you anyone use spaces over tabs, like if it's all the same, well, 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 them over Emacs. Oh, God, help us.

Okay, uh, you know what, I just I don't think this is gonna work. I'm so sorry. I mean, like what we're gonna 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 gonna 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, okay? Maybe even before starting to discuss the issue and define whether the issue is a critical one or not. And why is it so painful for you? Why do you even care? Okay? In any way, just try to leave your ego outside.

Let's take another example, okay? 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 at 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 option is to call the function and put in 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 these kind of coding dilemmas that sometimes even rising in a code review process. And those dilemmas can lead up a passionate discussion that quickly escalates to an entire team rumble, okay, and this is exactly what happened in my team just a few weeks ago, and it was over Slack, okay, with more than 15 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, okay, that I made the wrong decision. Now, if the issue is reversible, okay, I mean, if the decision I make and implement the code by that decision is reversible, then good, problem solved, okay, 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, okay. 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 own a backout strategy. It means that if we consider two or more approaches, and we picked one, and we probably guessed that we might want to switch to another one, so we need to have a backup strategy so the transition will be, you know, as seamless as possible for users in case the decision 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 timeframe. So if you don't make a decision within this timeframe, just consult the jury. Okay? 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. Okay? Don't put them in this awkward situation where they have to choose between you or someone else in the team. Okay? 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. And the decision is yours to make. Okay? It means that you are the team advisor.

Okay? You can provide some more insights based on your real experience. And if you're not experienced with a specific problem or topic, then you're not just as better than the most junior developer in the room. Okay? For example, I have more than ten years of experience and I've never dealt with garbage collection. So, I have no input in this kind of discussion about performance of garbage collection.

And 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. Sometimes this 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 canceled 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. Adopt a faster process and follow your intuition. Remember that you're not in a zero-sum game. Okay? Everybody wins here. All proposals are correct in some way, and you just need to understand what are the trade-offs. And no ego, okay? Leave your ego outside. Players with ego never wins. And try to stay rational, okay? Bring rational point of view, okay? Be technical. Bring the data. Use the data for your argues. And call a jury, okay? Let someone else decide. It's always much easier. And remain a pro, okay? Remember that when you're arguing with… you're arguing about professional issues with some of your colleagues, you must stay professional, okay? Don't go personal with them. Don't tell them what to do, okay? In a bossy manner. Don't tell them what they can or cannot do. And, you know, sometimes people think outside of your box. And that's just because 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, okay? 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, okay? Just consider yourself on a first date. Be a gentleman. Be polite, whatever, and maintain cool. That's it. Thank you. I was Ziv Levy. I have a lot more to share. I'd be happy to meet you and chat with you more. Feel free to pin me also on Twitter, underscore Ziv Levy.