The Warm Bodies Anti-Pattern in Software Architecture

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 when we're looking at patterns and any patterns in software architecture. This episode, we're going to look at the warm bodies any pattern. This is an anti pattern that we have touched on in the past in other areas, and it's not something that you can simply ignore in architecture as well. Now the anti pattern itself, warm bodies is more or less, let's throw as many resources as we can and fix the problem or hit the deadline or implement whatever the design is. That last one is really where the architecture anti pattern will show up. We sometimes over architect because we had too many features. Sometimes we over architect because we make it just a little too complex. Instead of simplifying and correcting that architecture to make it something that makes more sense for our solution, we say, all right, well, we'll just get a bigger team. We'll add more people or more specialists. When you run into that situation, when you find yourself in a situation where your answer is basically, we'll get more developers, we're going to get a bigger boat, as they say in the old movie line, then you're sort of you're on a slippery slope at least, if not already into that anti pattern solidly. We've talked all through this season in particular about the idea of taking big problems and breaking them into smaller manageable chunks so that you can really get a big solution done without having to take the whole thing at one time. You have these much more manageable, easy to understand, easy to solve problems, and then you combine them into that complete solution, that total solution at the end. This anti pattern is in some ways going the other direction. Instead of breaking simpler stuff into or large things into simpler things, we are making simpler things more complex and adding to the overall requirements, resource requirements at least of the application, while probably not addressing the actual requirements of the solution very well at all, or at least not differently. It's very similar to the idea that you can take a direct line from point A to point B, or you can take the scenic route, you can wander around. The direct line is going to be faster every time. The meandering route is just not going to get you there as quick. You have more space to cover. You have more opportunities for something to go wrong. Same thing in software. The more complex you make it, the more options or opportunities for mistakes, the more ways that things can go wrong, that things can be implemented incorrectly. And that's the issue with this anti pattern is instead of simplifying and looking at our solution and saying, okay, how can we get there in the fastest, most efficient way? Instead, we say, hey, let's do this more complex or flamboyant approach. And now I want to be clear that this anti pattern is not just something that arises when we're doing a we're doing something for flash or bells of whistles or something like that. Sometimes this anti pattern appears when we don't really solve the problem. And we'll see this in a few other anti patterns as well. We have a problem and we are architecting a solution, but we don't really do it correctly. And so what happens is almost think of it as like the Pareto principle, that 80-20 rule. We get in a situation where we can basically solve the problem. We solve it in quotes enough, then we move on. The problem with that enough solution is that it requires more resources than otherwise could. So instead of spending that extra time properly designing or architecting our solution, we just say, and we're going to take a pass on that and we'll just throw more resources at it and get it done that way. Sometimes, actually, a lot of the times, your better bet is to take a step back, review your solution, your design, your architecture and look for ways to simplify it. And this goes back to so many of the patterns that we've talked about and then the flaws and anti patterns that rise up when we don't take that extra time to look at our solution and put those finishing touches on it, clean it up. If you think of problem solving in general, your first solution, your first time at bat, you're usually going to get something that it solves a problem, but it's not an elegant solution, as we say. It's not something that you really want to have to do a lot. For example, if you were going to contact 100 people, maybe your first solution would be to write 100 letters, drop them in the mail and let the post office take care of it. That's not necessarily fun. It's time consuming and it's expensive, but you could do that. Now, if you had phone numbers or email addresses, then that would be a better solution. You could write 100 emails and you could write actually you could write one email and then send it to those 100 people. And now you've reduced the cost, you've reduced the time, you've increased the likelihood that everybody gets the same message, things like that. And that's maybe not the greatest analogy, but you can probably think of a solution that you put together that the first time you thought about it, it was just it wasn't good or it wasn't ideal. And we see this when we look at the path to automation that very often is what happened is the first thing you do is you create the steps to solve the problem. Then you start looking at ways to automate. And maybe initially, let's say it's a 10 step solution, maybe initially you can do one or two of those steps that can be automated. And then later you come back and you can automate three or four. And eventually you get to the point where you can automate all of them. That is the ideal solution. Automated, consistent, it just does it. It just runs. It just executes. We find the same thing with our designs and our architecture. It is not uncommon for us the first time we or the first rough draft that we have. We don't fully think through all of the situations. We don't fully understand the inputs and the outputs and the the ranges of those and how to handle outliers and things of that nature. So we put together solution. Well, let's say we start seeing some outliers, we start seeing some errors or some exceptions. When we just focus on the errors and the exceptions, then we can have some issues and we aren't really we're not really addressing the solution. We're addressing the problems. And of course, the easiest way to address the problems is just to throw people at it, throw resources at it, say, OK, we've got a bug list of 20 bugs that need to be fixed. OK, let's go get enough developers to spend whatever time to get those 20 things fixed, as opposed to fixing them so that become a non-issue. And we see this in other anti-patterns. Well, this will be yet another one of those recurring themes where an anti-pattern is addressing the problem, addressing the. A specific output, a specific bug. As opposed to adjusting the solution properly. Now, it's not always going to be the case, there are going to be situations where the solution is fine, it's just you have to find a different way to address the data input or output, which may mean an extension to the solution. But. If you are just patching as you go, if you're just throwing bodies at it, if you have created something that is complex or not ideal, and the way that you compensate for that is that you say, all right, well, we'll just get a bigger team. Then we're stumbling into that. Then we're stumbling into that. And the problem with this anti-pattern is not necessarily, even though it could be part of it, you may look at it and say, wow, that could get expensive. It may be tough to find enough developers or implementers or resources to offset the design. And that is part of it. But the issue is that even if you can today, typically what happens with warm bodies is things grow and you need more and more and more resources. And you get to a point where there are not enough resources. This harkens back to 10, 20, 30 years ago. You still see it today, but it was much more prevalent before the world of cloud computing, where people had to go buy servers and stack up memory and processing and stuff like that. And you would have solutions that they just needed more power. And so it wasn't a great solution. It wasn't exactly what you want. But the answer was, let's not rewrite the software or, quotes again, fix the software. Let's just get a bigger server and go add more memory to your machine. And we saw this in operating systems and things like that, where the answer is just, well, just provide more resources and it'll be fine. And sometimes you have to. I mean, there are minimum amounts of resources that may be required for solutions. But if you're not at that minimal level and as the usage of the solution grows, the resources required are growing in a line that's different from the solution. So it's exponentially or geometrically somehow increasing. And in that, think about it, if you have a straight line as your solution grows, it's a straight line for the resources that grow, hopefully in a shallow, but straight line. That's not the same because that's actually sort of expected. It's sort of expected. That's not the same as if that line starts curving more and more up, if you think along an X, Y axis. So now it's a curve and it's curving up because eventually, since that is growing faster than the solution, essentially, eventually you get to a point where you need infinite resources. And that's not going to work. We don't have infinite anything. So we need to make sure when we're putting our architecture together that we're thinking through the implementation, the cost of getting this thing done and making sure that as we do that, we have not essentially painted ourselves in a corner, that we have not built a solution that is going to require more resources than it should. And this, again, it goes to the 80-20 rule. A lot of times our first draft or first couple of drafts may be, it's okay. We'll make it work. And if it needs more resources than needed, so be it. But realize you're on the slippery slope for this anti-pattern. And particularly since it's essentially at this point, technical debt, you know that that thing is not correct. You know that you're not going to be able to do that. Correct. You know that you need to go back and fix it, then fix it. I know it seems simplistic, but you need to make sure that that stays on the radar to be fixed. And it doesn't just sort of get pushed off and resources added and resources added and resources added. And it is the nice thing about this anti-pattern is that it is an anti-pattern that tends to get more expensive as you go. You think about it, if you have to add a couple of resources a month, that may be okay. But eventually as you start adding, you know, now it's a couple and then a few and then several and lots and lots of resources, the cost becomes essentially prohibitive. You get to a point where you say, okay, wait a minute, we can't afford to provide this solution anymore. In which case you need to go back and fix things in your solution. Architect it in a way that does allow you for a reasonable amount of resources. And the other benefit of this, or I guess pro to this anti-pattern is that the sooner you address it, the sooner you reduce those additional costs. So something that may be trending towards being completely unviable is actually something that maybe when you fix this, when you correct this anti-pattern. Is something that actually becomes not only viable, but maybe highly profitable. So I think that'll be a good point to wrap this one up. We will come back next episode. We're going to continue talking about anti-patterns. We're going to continue to see a lot of these themes about simplifying and fixing things sooner rather than later and finding a solution that is the correct solution, a complete solution as opposed to one offs. That being said, it's time to let you get out there and tackle your day. So go out there and have yourself a great day, a great week, and we will talk to you next. 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 podcast 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 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.