Anti-Pattern: Make Everyone Happy

Welcome to building better developers, the developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season. We're looking at patterns and any patterns for software architecture. We've gotten through the patterns for the most part and now we are into the anti patterns. This episode we are going to look at one that is sometimes known as the make everyone happy anti pattern. This also more frequently, particularly in the discussions we've had over the years now, this is often known as design by committee or something along those lines, in this case architecture by committee. The problem with the committee part goes back to what we're referring, we're focusing on today in this episode, which is make everybody happy because it's not, it's not necessarily okay happy, maybe overstating it, but it is the idea of everybody having a say, everybody their way, having an equal part in the decision process. This can become quite a challenge. Now from efficiency alone, a single person can make a decision typically, and granted there are people that are not very good at making decisions, but when push comes to shove, a single person can make a decision and you can move on. And sometimes any decision is better than trying to figure out what the quote right decision is. It may be better to make a decision that is not perfect or maybe not the best option, but at least you're moving forward as opposed to sitting around trying to figure things out the analysis paralysis and similar kinds of issues that we've run into and discussed over the years fall under this category. When we have a committee, when we have a bunch of people, a bunch of voices that are giving input into anything, including an architecture, when we give essentially equal weight to each of those, it's easy to get into an impasse to get to a point where you have two people with maybe not completely conflicting, but at least not decisions or choices that are going to go hand in hand that are going to add complexity because now you're supporting two things that technically really you don't want to support both of them. You really want to do one or the other. But if you don't have a decision maker, if you're trying to please both of those parties, then you're stuck. You basically have to do it the hard way. You have to find a way to make that work, even though it may technically not make a whole lot of sense. And that is the anti-pattern at its core, at its worst, is that you end up making decisions that are based on the committee, the group on making people happy. And you stumble across the old saw where it says that when you try to make everyone happy, you end up making no one happy. And that's essentially what we're going to run into with this is that we're going to have situations where we say, okay, everybody is providing input and they've got their opinions and their points of view and we want to make them all happy. We want to be fair. We'll use the F word there. We want to be fair to everyone. And so we're going to find a way to incorporate all of that. One, that can sometimes be a major scope creep. The basic solution you're looking for, basic is probably the hard word, wrong word to use, but the primary solution you're looking at, the thing that actually solves the problem is going to get stretched and moved and adjusted because these different people have different ways that they see the problem being solved. And that's okay if you've got a group that wants to get together and discuss it and come down to a, this is the solution for all of us kind of approach, but it's going to take a lot of time to do that. And in doing so, you really have to have somebody that's a key or primary decision maker. It's okay to have all of those opinions and all of that input, but when it gets down to getting things done, somebody has to make a decision. There are going to be trade-offs almost always. It really is not possible to make everyone happy. So if that is your pattern, we're going to find out as we've seen, it's an anti-pattern. It's a losing game. And really, when we go back to some of our core concepts, our core goals and objectives, they are to solve a problem. Solving a problem is not necessarily making everybody happy. It's solving that problem. It's finding a way for that problem to no longer be an obstacle or to make it something that we can work through or work with. For example, medicine is a great place that we can see such things, and actually dentistry even more so. There are going to be solutions to things that include getting a shot or having a cavity filled or surgery of some sort where you're cutting skin and there's recovery time and there's pain involved. However, the solution that it provides is that you are healthier or in the long term you have removed something that is bad from the system, from your body system. That is not necessarily a solution that's going to make you happy, but it is one that says, hey, I'm going to have to suffer for a little bit. I'll get through it. It'll be better on the other end. That may seem a little extreme, but when you talk about software development, we do have that sometimes where you've got players in the decision making process that basically want ... I don't want to say it seems almost dismissive of them to say that they want something for free, but in some cases that's sort of what it is, is that they want this solution to do things without side effects. Because it's either not possible or it's going to be very costly to do so, possibly cost prohibitive, which goes back to a whole design by committee kind of thing. If you want to sit down a committee of, pick a number of people, five, 10 people, whatever, and say, okay, we're going to put you guys in a room and you guys are going to come up with something that everybody agrees on and that everybody's initial thoughts on how this is to be done are all going to be a part of this solution. They're probably not going to come back out. Eventually they will because they're going to get hungry and want to go to sleep and all that kind of stuff. Generally speaking, there has to be compromise. There has to be a big picture view of what we're doing when we're building our solution, creating, designing, defining an architecture that we need to keep our eyes on the prize. We need to keep focused on what is it we're really doing so that we don't get lost in all of these bells and whistles or other things that people want. I guess there are wants and nice to haves over the needs of that solution, the needs of that team. When you try to make everyone happy, that's not going to work because you're spending too much time serving all of the people that are coming up with the architecture as opposed to working on the solution itself, the architecture itself. I think this is something that we all know intuitively. It's sort of common sense that you can't please everybody all the time. Even in certain situations, it's going to be almost impossible to please everybody, to make everybody happy. But when we get into the business side of, I guess it's really more our personal attachment to the business side, we want people to be happy. We want our customers to be happy. Sometimes, most of the time, everybody that's on that solution team, they have different experiences, they have different knowledge, they have a different perspective, a different everything. Their background, they are unique individuals. That means that they're going to have a slightly different take on the solution, which again, this is not a treatise against having a lot of people provide input and getting feedback. This is more about the decision process itself. It is where we have someone that can say, okay, I am taking into consideration all of your feedback and input and suggestions and recommendations. Based on that, here's what I propose. Here's the architecture and how we're going to do it. This is how we're going to implement it. It's okay for them to do that person, that decision maker, or maybe a couple of people, a very small team, but essentially for them then to present it back and say, hey, this is what we think we want to do. Let's get some feedback, make sure everybody's on the same page, just make sure we didn't miss anything and that the needs are met of the problem and the users involved, not necessarily the wants. They may not be happy. For example, you may have a solution that still requires some manual data input or requires a user to log in every day when they really don't want to and things like that. So they're maybe not happy, but that's okay. We don't need to worry about that piece. That's not a big enough piece, which again, sort of points us back to that decision maker. They need to understand the players in the solution, the users, the implementers, and everybody in between so that they can help provide some value, some judgment over whether something or whether an approach, whether a certain tact or a feature is important to the solution or important to someone that's involved in the solution. Those are two very different things, even though sometimes they coincide. Sometimes everything falls into place and it's okay to make everybody happy. Just don't make that your primary concern. It's okay to have a committee that provides input. Just don't allow them to make that final decision because it's going to be a problem. It's going to take too long. And it's going to end up being compromised when sometimes it doesn't work. If you have to get across a chasm, you got to get all the way across. You need to either not go or make it all the way across. If you compromise and say, we'll get halfway there, well, that could be a problem. That could have you plummeting to your death. It may seem a little bit morbid, but hey, there's sometimes where you have to go with a one or the other. You can't find compromise. Somebody has to win, somebody has to lose in a decisional sense. Hopefully they don't take it personally, don't feel like it's a loss or a win, but somebody's recommendation has to be selected, which by its nature sometimes means others will not. And so if we try to compromise everywhere, we're going to end up with all kinds of issues. And there's plenty of places you can search on the web to find nice examples of such things where compromise does not always work. It's great in politics. People love to hear it, love to talk about it, but actually even then, you look at how they do it, it's usually more of a, okay, I will be right now. I will get my thing now. You will get your thing later. It's a different sort of compromise. That being said, I think we can move on from this anti-pattern. I can't please everybody, but hey, we're going to do our best with this episode by ending it more or less right here. So as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go. Develop-a-Nor podcasts and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, it'd be great if you go out to developernor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.