Patterns and Anti-Patterns in Software Development

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We have reached the end of yet another season. Season 16 after this will be in the books and we'll be able to move on to season 17. Part of it will be an interesting one, contemplating a couple of different directions to go with that one in particular I think will be interesting to go through and could take a while depending on what we do. I'll leave you with that cliffhanger. For now, I want to go back and sort of summarize in a sense or just I guess review a little bit the idea of patterns and anti-patterns. With architecture, much like software development in general, there are these patterns and anti-patterns apply to often doing the work, solving the problems that roll up into being an architect or architecting a solution. But there are also some that are, we'll call them process patterns and anti-patterns. And even probably the best thing to consider, to look at them as is consideration patterns and anti-patterns. In which case, those are things that we need to have in mind as maybe rule of thumb or things that we want to avoid. Which in general is what our patterns and anti-patterns are. Either we have this pattern that is something we can follow and it's more likely to make us successful or we have these anti-patterns that is something that if we follow it's more likely to make us fail or at least impede our progress towards success. Now through this season we have covered over a dozen patterns, over a dozen anti-patterns. And when you add in patterns and anti-patterns we've discussed in the past, you may have in your head, I don't know, two, three dozen patterns, two or three dozen anti-patterns. And that can be mind boggling. Those are things that if we want to keep all of them in mind and be cognizant of them at all times, it may just be too much. It may get us in a situation where we're spending too much time saying, are we using the right pattern? Are we avoiding the right anti-patterns? All that time spent is actually just us not getting things done. So patterns and anti-patterns are not for daily use. You may run into them daily. You may be in the midst of one daily. As far as trying to choose patterns and as far as trying to avoid anti-patterns, if you're in a daily retrospective looking into those, you're probably doing it too much. You're probably getting too granular because usually, particularly at the architecture level, patterns and anti-patterns are not, they're more like overall kinds of things. Yeah, there are a few that get down into the weeds of doing it. But for the most part, these are things that we can periodically look at, you know, like at the beginning of a project or while we're designing it, we can say, hey, where do we see some potential patterns? And then maybe periodically through doing this, you know, through creating the architecture, we may pick our heads up and say, okay, we've gotten 25% of the way through maybe. Are there some patterns that we now see that maybe we should use? Are there some anti-patterns that we may be falling into? And it shouldn't be like a long exhaustive kind of study for either. Because again, all these are generalizations. So we shouldn't need to be picking through every little bit of what we do. This should be something we should be able to spend, you know, maybe look at a list of patterns and anti-patterns, whether it's through looking at the seasons we've done it or just Google them and just get a list or create your own. Because you may have your own that are beyond what anybody else has run into. And just have a list of patterns, a list of anti-patterns, and then just sort of scan them. Just sort of walk through them real quick. I think with most of them, particularly if you have a general idea of what each of the patterns and anti-patterns are, if you can look at the name and go, oh yeah, that's that thing, then you should be able to skim through that list pretty quickly. And there are going to be some that you're going to write away throughout and say, no, they're not an issue. That's not a pattern that is at all going to apply to my situation. That's not an anti-pattern at all that applies to me. And there'll be some that can. And you probably even with those should be able to pretty quickly with a few of them say, yep, definitely I don't want to use that pattern or I am using that pattern or definitely that's an anti-pattern I'm avoiding right now. And then there may be one or two that pop up and you say, oh, maybe that's a pattern I should take a look at closer. Maybe I can utilize that. Or I'm falling into a situation where that anti-pattern may, that doesn't look like it's impossible for me to get to. And then take that, you know, the adjustments that you need to do or the further review to make sure you either do the right thing or avoid the wrong thing. These are areas where you can really get lost worrying about patterns and anti-patterns. It's just one of those areas, much like when you're designing a database and normalizing data or when you're creating object oriented design and you're creating all these objects, you can get too far. You can do too much. Some people may argue, but I don't think they've spent enough time in the reality then not to demean them too much. But there are definitely practical limits to such things. And it's just, there's a diminishing point of return as well. Sometimes we spend so much time trying to get to that perfect solution. It goes back to that Pareto principle again, that 80-20 rule. Sometimes we spend so much time trying to get it perfect that we end up losing the overall value. We put too much time into it. It's just like if you've got a car that's fallen apart and you're having to spend thousands of dollars a month on repairs or even sometimes hundreds of dollars a month on repairs, it's probably, you know, you're going to be money ahead unless you just enjoy doing the repairs. You're going to be money ahead, trashing the car, go buy a new car. And instead of those repair payments, you know, making those payments on repairs, you make a new car payment. And sometimes the car payments cheaper and it's much more reliable. You don't have to worry about, oh, do I have a, is this going to be a bad week? Is this going to be a good week? Or is it going to be a bad month, a good month? Is the engine going to fall out of the car or what? It's just less stress. It's just like that with patterns and anti-patterns. Sometimes you're going to look at these and you're going to be too focused on them. And it's not the pattern or anti-pattern itself because they should not be that in the weeds, that detailed. You should be able to, like I said, these are like general suggestions and recommendations and cautionary tales. If you're really digging into a pattern, trying to understand all the nuances of it, then you're probably doing it wrong. Instead take a step back, look at these and say, what is it? You know, look at your names. Okay, so what is this roughly? What is this roughly? What is this roughly? And walking through each of them saying, okay, does that, is that something maybe that can help me? Yes or no? And I'll take a look at it. Maybe I can find where that, those guidelines are some things I can say, oh, I'm going to, that gives me some ideas that's going to help me solve this faster. Or with anti-patterns, oh, that sounds like some things I'm doing and that doesn't end well. So I need to back those off or just be very cautious in how I apply them. A good example would be just the one we covered in the last episode, the BHAG, that big hairy audacious goal. Yeah, it's a great thing in moderation unless you focus too much on that goal, that end stretch goal and end up missing the idea that you've got to take some steps to get there. And that's really, I think the nut of this season. That's the key, really, I guess out of two things, that's one of the two things I really would like you to take away from this season. The one is that these are not to be, you don't need to overdo these. Learn them, get comfortable with them. Hopefully you've got them in the back of your mind enough that you can just sort of, you know, every so often say, am I running in it? Is there a pattern maybe out there? You don't have to know it completely, just like, I remember a pattern sort of like this, that may help me. Or, wow, I remember some sort of warning or anti-pattern about this. So maybe I could look further into it. And of course, the other one is the one that the drumbeat that has been throughout this season is that through all of these patterns and the like pattern of patterns and the pattern of anti-patterns points us to keep it simple, do not get stuck on solving the big problem. Instead, take that big problem, find ways to break it down into something smaller and then work on those smaller problems. And then as you roll those up, you'll eventually get to the bigger solution. It's like if you want to cover, if you want to carve, you know, like some something out of stone, you got a big block of stone, you're going to cover this incredible, you know, instead of sculpting it, you're going to, you know, carve it out of the rock. It starts with chipping the, you know, the first time, chip that first piece of rock, chip that second piece of rock. If you're going to eat a big meal, it starts with one bite. If you're going to tackle a big problem, if you've got a big project, it starts with a little task. Or maybe it's the first one is like, let's break it into tasks. What are the tasks that need to be done? And then focus on getting those tasks done instead of getting lost with this. Oh, we've got this big problem we're solving because you're not really solving that big problem per se. Instead, what you're doing is you're just solving a bunch of smaller problems, taking, doing these smaller tasks. And when you get them all done, you will have solved that bigger problem. So hopefully these patterns and any patterns will help you reduce your stress, focus better and really be more productive. That is the goal. These are lessons learned and cautionary tales from people that have done it a bunch and said, hey, here's some things that we have found in doing software and doing architecture. And we want to share those and share all of these things out there so that hopefully some other people will be able to learn from our experience, learn from what we did and be a little more productive and jumpstart their projects. Maybe. That being said, I think that'll do it. I'm going to wrap this one up, wrap up the season. I have not yet decided on a hiatus or not, so apologize for that. So we may come back just in a few days or it may be a week or two before we come back with the next episode. As always, you can take a look out at developer.com. You can follow us on Twitter in particular at developer.com. That will probably be some notes about the next episode or sign up for our newsletter. It's monthly, so I'm not sure how timely that will be if we just do a one week break. But you may also see some stuff there or reach out to us and fill out developer.com and ask us actually whatever you want, including if you have recommendations for future episodes and future season topics. So just want to thank you for spending your time walking through this. I know it's been a while. Some 30 some episodes that takes a while to get through them, but. Hopefully it has been beneficial to you. And if we can change anything, let us know. That being said, 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-Noor 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. Here we go. My song for Rob, my little insta hit. Now they always a little bit of a have a bit of a love song vibe to them, just because I think it's funny and it makes it a bit creepy and weird. So just heads up. Here we go. Well, give it up for Rob. He's my new best friend. I think I love you and we haven't even met. So I thought I'd rather be alone. I thought I'd write a little song for you because I think that you're so damn cool. California born Memphis raised, but Nashville's aware he likes to spend his days. That hockey rink is where he likes to be, but he's dying to head to Italy with Tim, Ian, Ben Beck and Tom. Where he can stare at the stars all day long. Yeah, he can eat that pasta till he passes out. Oh, well I love you Rob. I think there ain't a shadow of doubt. Come on. So I said, give it up for Rob. He's my new best friend. I think I love you and we haven't even met. I want to say thank you for having me on your show. Cause this friendship of ours is one that can only grow.