The Worst That Could Happen 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 where we're looking at patterns and any patterns of software architecture. In this episode, we're going to look at a pattern we're going to call the what could happen or maybe more specifically, what's the worst that could happen pattern. Now, this is something that's actually sort of near and dear to my heart recently, because I went through one of those nice little disaster recovery kind of moments. Had a desktop that had been working for a long time without any issue, and suddenly it just gave up the ghost. So the hard drive died. Yeah, it's one of those where, all right, we got to go find backups. We got to go find, go do a bunch of stuff to recover from that disaster. And it reminded me one, make sure we back up regularly, which sort of do, but got sort of bit because it was something that it had stopped running. The backup had stopped running weeks ago, and so it was not the most recent that I had assumed was being done. And it is really it's a it's a pointer to a pattern that is the almost the opposite of the happy path. We've talked about that in testing where you have a the simplest type of problem or data entry or path through your from your problem to your solution. And you make sure that works. It's like maybe solving for a specific case, solving for one record. But things can be very different when you jump to 10 records or 100 records or a million records. And we also need to make sure that while yes, you know, that the happy path is a good baseline, we have to make sure that we cover not so happy paths as well. And that's where this pattern comes in. It's really a. It really is sort of a software requirements and an architecture pattern more than anything, because it is an approach. There's a pattern when we say, all right, let's look at this functionality. And we try to look at it in a very pessimistic or negative fashion, such as what's the worst that can happen? What is it that could break this thing? What is it that could make this component render it useless or cause it to implode or something like that? Or data to be lost or data to be corrupted, which honestly, in most cases, data corruption is actually worse than loss because loss. Loss, at least you know, it was lost corruption. You don't always know what actually was what data is bad and what data is good. And that can really throw you off when you're trying to fix things. Because sometimes it will do damage that now you have to almost start from scratch because you can't distinguish good from bad. And so the what's the worst that can happen pattern is, like I said, almost a process when we put together an architecture and we say, here's what our functionality is, is how these things are going to work. One of the things we want to do is at least take a pass across like a review of the architecture with a what's the worst that could happen kind of mindset. Because what this does is it's going to surface, hopefully, and almost always will to some extent, at least bugs before they happen. What are some of the things that could go wrong? And as part of that, how do we offset those? How do we correct for those? How do we maybe avoid those things from happening or at least isolate those or somehow protect ourselves from those so we don't have damage to our data or processes? Our view from our customers, whatever it is, all of those potential negatives that could happen. We look at it and say, OK, what what could go wrong here? And in so doing, let's make sure that we prepare. Now, we don't want to go down every rabbit hole. You don't want to prepare for, I don't know, the end of the world, because at the end of the world, trust me, it's all for us now. At the end of the world, trust me, it's all for us. Not going to matter. But and there are going to be things like that. There are things that could happen, but are so remote in the the impact is so minor that it's not worth chasing it down. However, you have to have that combination if it's minor, but it happens a lot. It can add up and be quite a problem. If it happens very rarely, but it is very major, then you need to be aware of it. You need to be thinking about that and consider it. It's for thinking about big damage. If it's like a data leak that could be used against you and cause your entire company to have to fold. You run you out of business. That's big enough. Even if the it rarely would happen, not likely to happen, but once every 10 years, you need to make sure that you push that back. So it's not every 10 years, it's every thousand or more. You know, you need to you need to assess the the potential damage of the what's the worst that can happen and then look at frequency and figure out, OK, does this is this something we need to really chase down? Is this something that we need to address or architect for? Because as we've talked about our architecture, our our focus is the problem. Our focus is solving the problem. Our focus is not protecting. The solution necessarily. In most cases, it's not our primary concern is I want to solve the problem, so my customer has a solution that they can use. It's going to be secondary, at least for us to say, OK, I want to be able to do this in a way that is 100% consistent. It's not always secondary to do that, but maybe that is always consistent, that it is always going to work the same way, that there is no way to break it, that there is maybe a. No way for other people to figure out exactly what the secret sauce is to our solution. So they're depending on what your your problem and solving the problem you're solving in the solution and. The environment you're in, they're going to be different things that fall under the what's the worst that can happen kind of approach or I guess the results of doing a what's the worst that could happen review. And this is. This is something that actually combines well with sort of our standard, which we haven't really talked about, although I guess we've hinted at it sanity check approach to designs and architecture and even our software in general. It doesn't hurt for us to get that second set of eyes or third or fourth or fifth and just say, Hey, does this does this make sense? Does this make sense? Is there something some gap, some hole that I'm missing that I need to address or else this whole thing is going to fall apart? Or maybe like you build a car and it's like, Hey, this looks great. And somebody walks around and says, Hey, wait a minute. There's no tires on it. Oh, you're right. I totally forgot. Got to put tires on it. Same thing can happen with our architecture and with our solution. And so when we do a what's the worst that can happen, what it does when we do it properly is. It surfaces. What are the key components of the solution? Because in the what's the worst that can happen, those are the things that matter. Those things matter the most. And those are going to be the things that are going to be highlighted to us as where something could go wrong. Now, in most solutions, there is, for example, input and output. So when you're looking at what's the worst that could happen, it could be input is missing, wrong, or mismatched or something, you know, some sort of corruption, you know, garbage in garbage out. So there's some sort of corruption or breaking of the input. But then there's also potentially lack of output or corrupted output or partial output, things like that. Because in every problem, every solution input and output are pretty key pieces. But as you go into this, what's the worst that can happen? You're going to also figure out that there are other. Components or pieces of your solution that are also very they're essential. Those are the things that if they don't work right, then it can bring the whole thing to its knees or mean that none of it works right. It's not a bad idea to know that it is very useful to have that and have that as a focus to say, OK, these are the things that we know we need to be heavily concerned about. And we've talked about like 80 20 rule and technical debt and some other things where we build a solution and we don't build it out 100 percent. So because we can move forward with it, but in so doing. We may have gaps or issues that mean that it's not going to be ready for prime time. So this is a great review to do to say, yes, we can go for a minimally viable product of that component. Or maybe we can't, you know, maybe it ups the bar of what the minimum is. As we look at we say, you know, we could make this work, but there's a reasonable enough chance that this problem could occur. This issue could occur within our system and our environment, and it could cause very big damage or a lot of pain or whatever it is. And so we want to avoid that. That means we we need to raise the bar. Our minimum that we thought is not correct. It needs to be something we have to set the bar higher. That is the what's the worst that can happen. I think it's I think it's a good place to wrap this episode up is to just sort of leave that hanging there and have that thought in your mind of the what's the worst that can happen. Because with that mindset and occasionally reviewing what we do, it will help us maybe highlight where we need to focus. Now we we don't want it all the time because that could end up being something where you start trying to avoid every possible bump in the road and you essentially never finish your solution because you're spending too much time trying to handle all of the possible cases. So remember, the key to this one is we're going to look at how often or what is the likelihood of the incident occurring and then what is the cost or the impact of it when that incident when that what's the worst that can happen actually happens. We need to look at those and decide whether it is valuable enough for us to go down that rabbit hole or not. That being said, we will wrap this one up. 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. There are two things I want to mention to help you get a little further along in your embracing of the content of Develop-a-Nor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Nor site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time we talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at Develop-a-Nor dot com if you would like more information. Now go out there and have yourself a great one.