Misdirection in Software Architecture

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We're continuing our season where we're looking at software architecture patterns and anti-patterns, and we are deep into anti-patterns and even looking at a few new ones. This episode, we're going to continue with the improper focus series of anti-patterns. We're going to talk about what we're going to call misdirection. This could also be sleight of hand or something similar to that, which is where you should be looking in one direction, where what matters is in one direction, but you're looking at something completely different. Misdirection or sleight of hand, when you think of magicians as in modern sleight of hand magicians, their work is primarily based on misdirection. If you've got, let's say, a coin in one hand, and you want to do something with it, but not let the audience see it, then you find a way to get them to look at the other hand. That allows you, makes you free to do whatever you want with the hand that they're not looking at. That's sort of how it goes. In this anti-pattern, it's sort of the same thing. This is where we are focused on what we really should not be focused on. The thing that really matters is thus forgotten or left to its own devices. This again goes back to some of the things we talked about with the statistical bigotry was where in that case, you're doing it based on essentially some sort of analysis, some sort of numbers or estimation or something like that, that drives you to focus on certain areas and give them all your attention. Misdirection is similar but different. In this case, it can be and often is solving the wrong problem. It's not getting to the root of what needs to be solved and instead dealing with something that's, let's say, more surface level or at least maybe it's instead of the cause, you're addressing some of the effects. That's almost like a bandage type of approach. This typically comes from not digging deep enough into the requirements and actually understanding what they are. Now, we've talked prior about doing that and not digging into the requirements enough and having enough context around them to understand what's important and what's not. It's a little different. In this case, this would be where you start with a general problem, a general pain point. Instead of digging into that to figure out why that pain point exists, instead you try to just alleviate the pain. So if you had a, let's say you've got a poison running through your system from a health point of view and it's causing sores to appear that you treat the sores as opposed to fix the source of the poison. Those sorts of things are what we see in this anti-pattern when we're looking at architectures in particular. A good example would be where, and this happens actually quite often, where there are requirements that are unstated or hidden. And instead of solving it correctly with those hidden requirements in play, you miss it. Now, these often, the good ones, or I guess the ones that it's better to run into, are the ones where they deal with things like maybe some sort of a requirement for that system, some sort of, like maybe it's a compliance issue or something like that. Let's say you're a HIPAA type or one of the financial related compliance applications and there's certain things that you need to do, maybe certain reporting, maybe it's got a certain format, a certain style, a certain frequency. And instead of those compliance requirements being laid out, somebody just says, well, we just need this report. This report needs to be done and it needs to look roughly like this. Well, you may end up going down these essentially rabbit holes of changing up that report thinking that they're using the report for something other than simply compliance or vice versa. There may be something that is really maybe initially built as a compliance report and not until later you find out that, well, no, that's actually being used in other areas. So maybe there's, like maybe from compliance, let's say it only needs to be run once a month, but because that same report is being used in other areas of the solution, it needs to be run every day. Or that data, maybe it needs to be real time as opposed to just a monthly roll up. Things like that are big differences in the architecture and the approach and the solution. And you're not going to know those if it's a surface level look at the application. Now, a good example of where this shows up on a regular basis and in frustrating sort of way is when somebody will say, take, you know, ABC application or site, and we basically want to use that as our, essentially as our requirements document, and we want to rebuild that. And that may be because they see something somebody else has done. Like let's say Airbnb, they see this Airbnb approach has worked really well. So they want to take that and they'll just say, well, I want Airbnb except for I'm going to do it for car rentals or something like that. Or they've got an application that they really didn't document that they never had actual requirements. And so over time, instead of being able to say, here's the requirements, we need you to build it, there's a, you know, maybe there's a migration or an upgrade or something like that. And they say, well, just take the existing application and rebuild it in this, on this new platform or in this new software version or something like that. That can get you somewhat there because you can look, you know, you can look at the application, you can use it. And some of the, in a sense, a lot of the inputs and outputs will be roughly the same. The challenge is that while you can guess at the inputs and the outputs, you're not always going to be able to confirm those. You're not going to be able to figure out what are all of the art. I guess you could, but it's going to be exhaustingly difficult to walk through that application and enter all the possible combinations and permutations of data in a way that basically covers what are all the inputs and what are the related outputs for it. Instead, you're going to say, well, we're going to, you know, have this, these families of data that we're going to enter. Here's what it looks like. Here's what the results are. Okay. That works. But what you often find in those applications is that there are outliers or special cases that as you get in the application, you find out, oh, we thought it only did this, but it has to do that. For example, particularly if you don't have a good discussion with the user, you could have something as simple as, oh, when we were going through, looking at the application and starting to build out the requirements, we never entered a negative number in this field because we thought it always had to be positive. And then you find out from the users that, oh no, we enter negative numbers all the time. Something like that can be dramatically different because it can change what you're, the problem you're solving. It can change how you look at the data. It can change also in a lot of these cases, it can change what other data is impacted. If you've got side effects that you don't see from the application, which often is going to happen, you're going to have this underlying model that is changing, updating, evolving, calculating, whatever, based on the interface, the inputs, and maybe some of the calculations based on that and the data manipulation, you're not going to be able to see a lot of times that internal memory structure and what's being done. So you may have cases where you put data in and you have no idea why this different data comes out on the other end. You're not necessarily able to see, in this case, the entire, because it's sort of a black box, you're not able to see the entire box and all of the controls and understand it in a lot of cases. Or maybe there's going to be some cases where it's very straightforward, but this is where that anti-pattern comes in. If you haven't dug deep enough, that's where you're going to run into problems because you're going to be going through, walking through the problem, crafting your solution, building out that architecture, designing your solution set, and it's going to be based on assumptions that are potentially false. And the problem with all of this is like a lot of the focus-related anti-patterns, you don't see it right away. You don't necessarily see it, and you may not even see it in testing. You may not see it until it gets all the way to production, as we've spoken about before. You may not get this pointed out to you until it gets all the way to production, the end users get it in their hands and they say, wait a minute, this thing that we used to do all the time is no longer there, or this thing that we do all the time is not available. And this is where if you're not thorough, you're going to fall into this anti-pattern. So avoiding it, you need to be thorough. The best, I guess, trick or approach or process that I've heard related to architecture and gathering requirements is to keep asking questions. So when you're going through that, and you should be always going through that interview with an end user or somebody representative of them, and you're saying, okay, tell me about your, what is it that you do? How is this problem need to be solved? Do you work with this daily? Do you work with it weekly? Do you, how often do you need to do imports or their exports and all that kinds of, all those typical questions. But with each of the answers, particularly when they're walking through a process or saying this is how it should be, don't be afraid to ask. And then what? So they may say, oh, let's talk about like just a simple, you know, ATM machine. Let's say that you're building an ATM and you say, okay, let's talk about a withdrawal. So how did it walk me through that? And they'll say, well, you know, person comes in, they put a card in the machine, they enter some sort of an ID to tie to that card. It goes, that gives us an account number. It goes out to the account and verifies there's an account and then pops up something that says, how much money do you want? Okay. And then what? Well, they enter a number and it checks for the balance. And then if the balance is available, it spits out the money. And then what? Well, then it updates the account balance and ask them if they want to receipt. Okay. So gone through, they get the money, balance gets updated, they get a receipt. And then what? Well, and then they can either ask for, you know, they can either perform another transaction or end the transaction. And then what? Well, there's not much more. Well, what happens, you know, so let's dig a little deeper. What happens if they don't have the right balance? What if they ask for a hundred dollars, but they only have $80 in their account? And then what happens? Well, they get a message. Okay. Does that, and this is where we're going into that. We're digging into this. Well, okay. So they get this message. Does that need to be logged anywhere? If they, you know, for example, also in this little bit of piece, a little bit of a functionality, when they log in, if they fail to use their, if they enter the wrong ID, what happens? What if they enter the wrong ID again? What if they enter the wrong ID 10 times in a row? Does that change it? Those are the kinds of questions that we need to ask to avoid this anti-pattern. Because what happens in sleight of hand in the misdirection is that we may think from the initial conversation that there's, there's one path or that it's a very simple path. But as we continue the interview, we find out that, oh no, there's actually multiple paths maybe there's multiple entry points and multiple exit points. Maybe there are multiple ways that you can join on this path midway or exit this path midway. That can dramatically change your application. And this is why the, the approach basically of, well, just look at this site or this application and I want you to rebuild it, you know, build it from scratch for me or build it another framework or whatever it is or build it except I want it to work in a different vertical, you know, instead of real estate, take this real estate application and now I want it to work in, I don't know, the healthcare sector, you know, something like that. It's not going to be that vague, but it can be pretty darn close. And so that's where you need to say, hold on, I don't even know what your understanding is of this other application. So let's talk about what you really need and then we'll even see if that application makes any sense for you. Because sometimes it won't. And that would be massive misdirection. If you spend all your time focused on, okay, let's look at this application that you pointed as the, the source essentially for essentially for where we're going to start on our requirements. And you get pretty deep into that and then realize somewhere along the way, oh my gosh, this isn't going to work. This is a horrible way to start. This is the wrong application for you guys to use as a starting point. You're in a whole different area. All the concerns, the users, everything is completely different. And so if you model it off this other thing, it's only going to be a train wreck or just maybe far more complicated than it needs to be. And so that's where the misdirection really bites you is that you end up spinning your wheels. You end up spending time on things that are not useful, that are not the actual problem. And so I think that hopefully lays that out enough for you because it's time for me to let you go on and enjoy your day. Hopefully get out there and get productive and all those kinds of things. But we will come back and we will continue talking about patterns and any patterns. And we are getting closer to the end of this season though. So we're starting getting close to wrapping some of these things up, but we will return until then 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-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 Broadhead 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.com if you would like more information. Now go out there and have yourself a great one.