Keep It Simple

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 are continuing our season where we're looking at patterns and anti-patterns for software architecture. This episode, we're actually going to flip back and look at a couple of patterns. Last couple of episodes, we essentially created some new and talked about some new anti-patterns that you probably have not seen before. And there's a couple of patterns that are not fully patterns, but I think they're approaches that make sense to discuss in a pattern, anti-pattern discussion about software architecture. This one, this episode, we're going to talk about KISS or Keep It Simple. The second S has various things. Sometimes it's SAM, sometimes it's something less more specific and a little bit derogatory. But nevertheless, we're going to focus on Keep It Simple. Now this may not feel as much as a pattern as a thought process or maybe a problem solving approach. However, when you look at some of the patterns and anti-patterns that we've discussed, we've talked quite a bit about the idea of breaking a big problem into smaller ones. And really the concept behind this is Keep It Simple. It is much easier for us to do a lot of simple tasks than to try to do one big task. If you think about something that's not a perfect analogy, but still pretty good, think about the idea of climbing up a steep hill. If you have stairs and you do it a step at a time, that's going to be easier than just going up a non-stair sort of rough slope. Same thing as a ladder. You can try to climb a cliff face by nailing in your little your pitons and connecting your ropes and all that kind of good stuff and climbing up. Or you can do a ladder and do it one step at a time. To some extent, those are not great and perfect analogies, but the idea here is that when we have to do more in a step or at a time, then it's going to be tougher than that minor, that smaller step. It all goes back to that whole way back when somebody said journey of a thousand miles starts with a single step. It may be overwhelming to consider a journey of a thousand miles, but it's definitely not overwhelming to think of a journey of a single step. And there's a lot of other things besides just the overwhelm or the wow factor of a large problem. There's also the whole delayed gratification. If you can make progress, then you're going to feel more positive. You're going to be able to keep morale up a lot easier because you're going to say, we're closer than we were five minutes ago or yesterday or last week, as opposed to going long periods of time without a some sort of a milestone or a marker where you just, yeah, we're on our way to this thing. It doesn't it doesn't have the same feel. You may still be progressing, but if you're not feeling it, then it can get a little bit demoralizing. It can be challenging because you feel like you're just a drift. If you think of a sailing type analogy, it would be where you have a long time that you're sitting on the water, you don't see land. You may start to worry that you're lost, you're adrift, whatever, versus if you take that same journey and you can follow a coastline or something like that. So you can always see land. It's going to feel better, almost safer. And with the keep it simple approach, the other thing we're looking at is really the life of this solution. If it's complex, then it's going to be harder for you not only to implement it the first time around, but also to communicate to somebody else forever. For example, the maintenance group that this is how it works and this is what the key cogs are that you're going to have to watch out for or make changes to as part of updates and enhancements. Complex systems also tend to have more points of failure. If you think about like an Apple, when you look back at the original iPod, it only had a couple of things. There are only a couple of interfaces to deal with, so there's only a couple of things that can break. If you look at, for example, your laptop or desktop computer, there's a lot of things there. Just think about a keyboard. It's a difference between a mouse where you have maybe a click or two, a couple of buttons that you can click and you can move stuff around versus a keyboard. You've got all of those keys that could potentially break or cause some sort of a failure or get wonky if you want to get technical. So when we keep it simple, what we want to do is in building out our architecture, focus on function over wow factor. We want to keep, as we have mentioned before, the solution, the problem and the solution at the top of our mind. Our focus needs to be how do I solve this problem, hopefully in the most direct way versus how do I solve this problem and impress somebody or try out some new technology or any of those things that are not solving the problem directly, any of those other distractions that we can easily run into. Now we've talked about in the past the issue of a hammer. All you've got is a hammer. Everything's a nail. We see this with frameworks and technologies where there's a solution that we need to build, but we're limited in our, if we don't have enough arrows in our quiver, then we may end up not using the best technology or the best framework or the best approach to solving our problem. Keep it simple as falls into that same area of not only do we want to use the right tool at the right time for solving this problem, creating a solution, we also want to make sure that it is not adding more work or complexity to the situation than needs to be. Now you will see this actually, keep it simple actually works well even at the requirements gathering phase. There are definitely, and we talked about anti-patterns like misdirection and some of these others, it is basically not keeping it simple with some of those requirements. Instead of focusing on the problem, we focus on something a little different that may be a more complex thing to solve. It may even be not the correct thing to solve. This goes back to putting a bandage on something as opposed to solving the core problem. If you've got a pipe that's failing and you've got fluids going through it, you can slap some duct tape on it or whatever and stop the leaks or you can look at it and say, okay, this whole thing's falling apart, we need to replace this pipe or this section of pipe. We see this a lot in software. We can either keep going back and you see bugs and you have to fix them and you have to address it or you have to bite the bullet and say, all right, we're going to do a bigger fix to this and we're going to actually replace or rebuild this section of code or this buggy area. In an architecture, it seems almost simplistic to look at it this way, but if you have a lot of objects, a lot of boxes on your architectural design and a lot of lines going back and forth between them, you're probably not focused on simplicity. Now simplicity is not always going to be, it's not going to be the same from project to project or problem to problem. Sometimes the simplest solution is still a very complex solution. You think about putting a, they decide to put a man on the moon. There's not, you know, the simplest solution I guess would be, you know, put somebody on a catapult and just launch it, but it's not going to work. Sometimes your simplest solution is still going to be very complex. So you may ask, well, how do I work? How do I focus on using this pattern? And it is a pattern that you can use in any situation. And the way we do this is we essentially do a self-evaluation or a review or better yet, some sort of a peer review where you push this out to some other people that are varying levels of knowledgeable, depending on what you need. And basically take a step back and say, okay, this is what I came up with. This is the architecture we have put together. Let's take a step back and look at it. Does that make sense? Are there areas that are very complex? And if they are, do we need those or is there a way that we can simplify it? In math, there's the idea of lowest common denominator where you try to figure out between two numbers, what are the lowest, the smallest numbers that they share as part of their makeup. So six, it could be, you know, one times six, two times three. If your number is a hundred, it could be, you know, four times 25, five times 20, 10 times 10, all that stuff. And you try to find the lowest common denominators. What's the number that goes into both of them? Sort of the same thing when you're looking at keep it simple from an architecture. Is there a way that we can either eliminate some of the complexity within this piece, or this section of the architecture, or is it something that maybe we should break down? Yet another example, in some sprints, there are point systems essentially that are done within the estimation so that you have a, you know, roughly very simple all the way up to very complex. And depending on what your task is when you're estimating it, it may be one, two, 10, a thousand points or something like that. Well, sometimes the number of points that a task would be estimated are actually even more than a sprint. So you can't, there's no way you could complete that task within a sprint. And a lot of times there are rules that a team will put together that says, okay, if it's that big, it's not defined properly. We need to find a way to break that into smaller pieces. So now we can make progress within a sprint and still eventually grow towards that overall solution. And usually if you see something that's big and hairy and complex in your architecture, you want to review it, that piece on its own, what is it doing? And then are there ways that we can break that into something smaller? Because sometimes that's not enough to just break the big problem into some smaller pieces. Sometimes those smaller pieces that we broke it into are still too big and we need to take those down a notch or two in order to be able to really understand and have a firm confidence about our solution. Because that's the other thing about complex solutions. There's a certain level, there are limits to what we as human beings can just feel comfortable with in our mind at a time. It's like, yeah, it's a phone number. You can, seven digits you can memorize. If it's 400 digits, you're going to really struggle to memorize it. So break it down into smaller pieces. Same thing with any other problem is let's break this down into smaller pieces. So that review process of our architecture becomes a way to try to use this keep it simple pattern as we look at what we've built and say, is it simple? Does that make sense? Or is it something that we can look at and reduce to something smaller? So we have a, instead of one big black box in this area, we have, you know, maybe smaller black boxes that have some connections between them. And of course, within that, that means that that big black box with one button, when we break it down into smaller boxes with buttons, we get to see inside it. So that big black box is now not quite, it's not as big, but it's also not so much a black box. So we're seeing something about that solution and it's not all just hidden within this component. So there's a lot of benefit to keep it simple besides the whole idea of just not being overwhelmed with what it is we're trying to solve. That being said, I'm going to try to keep this one simple and not belabor the point too much. We will come back. We're not done yet. We've got some more that we're looking at. Now we're sort of in the autumn of our series though, of our season. So we are going to bounce around probably a little bit between patterns and any patterns moving forward as we get these last couple in and almost get into like this, there's a little more thoughts about processes and some things that we can do to make our life easier. Just depending on the, we'll call it the flavor of problem that we're trying to solve. Because there are definitely some similarities and we're going to take a look at those. That being said, it's time to wrap this one up. So I'll let you get out there and enjoy your day. And as always, have a great day, a great week, and we will talk to you next time.