Building Better Developers

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 start a new year and a new season. This is season 16 and we are going to be looking at software to architecture patterns and anti-patterns. This first episode, we're going to kick off the season with a little bit of a flashback to patterns and anti-patterns in general. Now, we're going to focus a little more on architectural patterns, which have not really been covered as much in the past. We've looked more at general software development patterns. We have looked at project patterns. We've discussed architecture a little bit, but this time that's going to be our focus through the season. Now we'll start with a nice definition. From Wikipedia, an architectural pattern is a general reusable solution to a commonly occurring problem in software architecture within a given context. The architectural patterns address various issues in software engineering, such as computer hardware performance limitations, high availability, and minimization of a business risk. Some architectural patterns have been implemented within software frameworks. Now, that's a pretty long definition. The key is to remember that architecture is going to have usually a specific focus. So it may be scalability, it may be maintainability, it may be stability, it could be performance, it may be high availability. There's a lot of different things that go into an architectural pattern. Like all software and really design and implementation anywhere almost, there is give and take. There is also always going to be some level of risk, and part of this, part of whatever architecture we go over, will sometimes be riskier and sometimes be less risky as far as the typical solutions that that architecture works for. We're going to see this as we have in the past, where patterns and anti-patterns also have related problems and solutions. It's not a one size fits all kind of approach. Now, the last little thing I mentioned there that is going to make some of these things feel familiar, although they may not even have that being named as such, is that often software frameworks are built with a specific architectural pattern in mind. They sort of hang the implementation on that pattern and often will lock you into it. Now, we'll find that there are related patterns, so there are ways you can sort of shift from one to another, particularly even in the early ones we're going to discuss. frameworks are typically going to be best suited for certain or maybe even a specific architectural pattern. Now, stepping back a little bit, patterns in general are ways to get things done. If you think of a sewing pattern or even color by numbers kind of pattern where you have something already there and you're basically fleshing it in, you're basically filling in the blanks. That's what we get out of a pattern is a faster way to get going. We don't have to start from scratch. We don't have to start from a blank sheet of paper. We already have something that we can work from, and that's going to speed us along. And there's decisions that are made within that pattern that are going to help us be better, that we're going to have a higher quality, higher scalability, higher availability, depending on the pattern, those things are there and give us a solid foundation to work from. We also don't have to reinvent the wheel. Now in patterns we've seen in software, a good example that I've used a couple of times would be a login, just basic authentication into an application. We all have seen enough that we see the general pattern of you have a login, you have a password, you have a verify password when you want to actually create an account to make sure that you've got to, you've got a forgot password. A lot of times, depending on security, you've got patterns that are around, security type patterns around a number of failed logins. Maybe there's some sort of multi-factor authentication where you log in, but now we send to your phone or your email some additional code that you have to enter. Those patterns are things that over time people have learned are great ways to implement that solution. We're going to see the same thing in architectures. Although architecture is higher than software development at a higher level, more general purpose, so you may not see specific solutions that these architectures will fit, but we will try to sort of mix those in as we're talking about those through the season. Strengths and patterns very often, as I said, go more or less hand in hand. And we've seen that with several of the frameworks we've talked about over the years have strengths and weaknesses that are based on what the framework is best suited to do. For example, there's an old object relational mapping framework. It's been around for a while. You could say it's old, but it's been around for a while. And it is built on essentially simple CRUD functionality and simple relational databases where most of the stuff is mostly table-based. You don't have a huge amount of normalization, nor do you have very complex multi-table join types of relationships within the data. Maybe like a Microsoft Access or FileMaker or something like that, or even worksheets in an Excel spreadsheet where you have blocks or constructs of data and they don't really relate too much amongst each other. The thing is, this framework works awesome when you have that. But if you start having things that are highly normalized, it blows out the memory of your application because it's trying to load all of this stuff in. Its lazy load is not terribly good. And at least up until a few years ago when I last used it, lazy load was not by default. You had to go in and actually had to tweak a couple of things to get it to lazy load. And it was not uncommon that your entire database got loaded into memory, which can be time consuming and burn up a lot of memory very fast. It sort of defeats the purpose of a database in the first place. Digress a little bit, but that's an example of a framework. And it has a specific pattern that it was built for, that it is best suited for. And if you get away from that, then it's not going to work. And when we talk about frameworks, particularly, I don't know how much we'll cover those this season, but Mel makes a mention of them. And it is important to note that if we say framework X is really good, it's going to be within the context of that pattern, that architectural pattern. Don't assume that because I say it's great for us to use this framework with pattern ABC, that it's also going to be good for pattern XYZ. In fact, it may be horrible for that other app pattern, or it may be actually horrible for any other pattern. Those things are very tightly constructed for things like speed and performance, memory, things like that, where it's highly tuned and it's built for a very specific cause or solution. And if you vary from that, you're going to have problems. You think about a high performance race car. It is built to go very fast in circles and get the tires changed on a regular basis, things like that. If you go cross country on one of those things, it's going to be miserable and it's not going to be a very good idea. It's going to be probably the worst thing you could choose to go on a cross country trip, especially if you want to load the family in and luggage and stuff like that. Frameworks patterns, the same thing. These patterns are going to be tied to a solution essentially, or point to a solution. And those are where they're going to make the most sense. If you start trying, if you say, Hey, this pattern sounds really cool. And you try to use it for solving a problem that it's not really suited for. You may find out that you are not very happy with that solution, that it could actually cause more problems than it solves. And that's actually most likely as we get into the anti-patterns, you're going to see some of those kinds of bad choices, we'll say. Or it's not necessarily even as much a bad choice as a bad fit. And we've seen those anti-patterns before, such as the one size fits all kind of anti-pattern, things like that, where we look at something, it's great, we're comfortable with it. And we say, great, this is what I'm going to use for everything that I see from here on out. It's the whole, I only have a hammer, so everything is a nail kind of approach. That does not work with architecture patterns either. We're also going to see in this as we go through these, and right away we're going to start seeing some patterns that really, while heavily used and very useful, particularly in the past, they do not necessarily hold up, I guess, in modern software development, particularly because we really, for the most part, and now this means for the most part, so it may be different for you. For the most part, we have moved beyond mainframes and these huge gargantuan servers and lightweight clients and stuff like that, or even fat clients. We've got mobile devices and a lot of times we use APIs and things like that, so we don't even have the direct kind of connections that we had in the past. And we've grown beyond stuff that is maybe dozens or hundreds, maybe thousands of users to potentially hundreds of thousands or millions of users and maybe even at the same time, you know, hundreds of thousands of concurrent users. I don't know if you look at some of the biggest sites like Amazon or Facebook or something like that. I don't know what their concurrent user number is, but it's a heck of a lot more than we had to deal with 30 and 40 years ago when we were building client server applications. All of these things are something you should consider. And as we go through each of these, try to see where maybe a pattern, maybe it's useful, maybe not so much. And there's going to be some that are, it's going to be obvious that, yeah, that would be a great architecture for me to consider for this thing that I'm going to build. And some are going to be pretty obvious that it's not. It's the ones that are in between that you're going to have to take a little bit more time maybe to dig deeper into them and think about how that would, how your solution would map to that architecture. As always with patterns and anti-patterns, the benefit of these things is it comes from people that have gone before us. They have done these things. They have built these things using the patterns that we're going to talk about. And we're going to see that there are strengths and weaknesses and we need to make sure we keep those in mind when we're choosing the patterns to use. When we're looking at any patterns that we want to avoid. I think that's a good kickoff for us. So we will start season 16 in the next episode. We're going to dive right in. As we've done in the past, we're going to focus on one pattern or anti-pattern per episode. And we're going to start cranking our way through these and we'll just see how far we go because I have not even completed the list of patterns and any patterns that I want to address in this season. So welcome back. As we are starting this, we're kicking off basically 2022 and hopefully have a great year ahead of you. Hopefully you can put the last couple of years behind you and maybe got some great products and problems that you're going to solve in the months and year ahead that these patterns will be helpful for you. That being said, I think we'll wrap it up. No challenge this time around, but just as always go out there, 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.