The Jumble Anti-Pattern in Software Development 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. Well, hello and welcome back. We're continuing our season where we're looking at patterns and anti-patterns for software development architecture. Software architecture, patterns and anti-patterns. What do we do? What should we avoid? We started out the season looking at patterns and we're now looking at anti-patterns. This episode, we're going to talk about the Jumble. The Jumble anti-pattern is, this is one of those, like more than a few of the anti-pattern names where the name itself is something that even if you're not technical, you're going to say, wow, that sounds like an anti-pattern. It doesn't sound good. There's very rare that you're going to hear the word Jumble in a good way. Maybe you do what they call word jumbles, where it's some letters sewn together and you make words out of them. That may be the closest thing to not negative. It's a challenge, but in a fun way. Jumbles in general, not what we want, and particularly in architecture. We don't want to be doing something that is the foundation for our software and we look at it as a Jumble or that is a label at least that is used with our architecture. Now Jumble is interesting because it's the first time in the anti-patterns and really with patterns that we talk about mixing, well, Jumble is a mixing up of the vertical and the horizontal structure within the architecture. We haven't really talked about this. What you have in any solution is verticals and horizontals. The verticals are, let's call the more general purpose components. These are the things, I'm sorry, that's a horizontal. The horizontal, see, I even mix up the words occasionally. The horizontals are the things that are, think of a horizon, think of a flat line or a line that's going east-west, left to right. These are things that are general purposed across problems. For example, if you have a login, logout component, that would be a horizontal component. It's going to work, it's going to be useful in just about every application that you build. What's different to that is the vertical component. A vertical component is within that problem space. So it's going to be, let's say you're building an ATM machine, there may be a login component that would be horizontal, but you probably have, let's say, an account component or an account management component. That's going to be vertical because it's really specific to that problem. Depending on how you do it, yes, it may have some general repurposing allowed for it, but the focus is going to be, in this case, and that may be a bad example, but generally the focus is within this problem space. So you have in any solution, you have general reusable components, and then you have specific ones that are really, they're components for just for maintenance, scalability, enhanceability, documentation, things like that. Instead of just having a bunch of code, you have these vertical components that are, those are the core pieces to this specific problem, to working this specific task. A jumble is when you mix those things up, when you have things that are vertical that you're trying to treat horizontal and vice versa. And the reason for this is that you have, it's almost like data flows, if you think of it. If you think of like an intersection in a street, you have people going, let's say it's northwest, east, south, or north, south, east, west type of intersection. Well, if you've got people going north and south, they don't, they can keep going in their direction. They don't have to turn. They don't have to worry about going somewhere else, especially if there's multiple intersections. They're just running straight through. People going east, west are going different, different start, different finish. This is a moderately lame example, but just to get you starting to think about the idea of stuff, data, essentially, and communications moving in one direction, but other communications working in a different connection, a different direction. And you really, technically you don't want these things to cross at all. So you don't really want an intersection. If you have, and this becomes very important in the modern world where we have a lot of security concerns, privacy concerns, things of that nature. The data that we have within our problem space, if it is, let's say it's a financial application or health application or something along those lines where we have sensitive data, sensitive information that's within our problem space. We don't want that going horizontal. We want to keep it in our silo. Likewise, the horizontal is going to be dealing with things that we really don't want to force the vertical to know much about them. We don't want to integrate into it. We just want to have an interface where it can use us and that's it. And we see some of the ideas of Jumble and some of the other things that we've come across both in patterns and anti-patterns where we want to have well-defined interfaces, well-defined inputs and outputs. If we start monkeying around with those, if we start tacking things on and moving things around and punching another hole into the black box, we've got a different interface. It's just not good. Nothing good will come from that. And that's the Jumble kind of issue. So we end up within a Jumble. Typically as you think of things like libraries and frameworks that are really more that horizontal piece and there's going to be some, we'll call them custom or extension type components or pieces of our architecture that are specific to the problem we're solving or maybe even to the organization that we're in. Maybe that we're doing multiple solutions. Let's say we're a healthcare company. So we have a lot of solutions that are related to healthcare problems, but we're still sort of in that healthcare space. So we may even have some things that are more horizontal than others. But generally speaking, what we want to do is make sure that the components we're building have what they need and nothing else. That they're not basically jamming other stuff into it just to make it work. In the world of libraries and frameworks, when you get to a point where you basically or somebody on your team says, we have to change the source code for that library or framework in order to make it work with our system. You should see red flags going up and sirens and all kinds of alerts. You're getting into a Jumble at that point. Now in the most direct sense, you see this with any purchased software, whether it's a library framework, anything like that, where you can, where you have access to the source code. So you could possibly make changes to it because if you do, guess what? The next time they do an update, you're not going to work or you're going to have to find some way to remake the changes that you made. So you have now yet another reason to avoid a Jumble. Don't mix and match components. Is there any time to think through what it should do and what really does it need to have? And is there anything that you have included that you say it quote needs to have that really doesn't that is usually is more of a, I don't know, a helper kind of piece of data or a convenience thing as opposed to we need to have this, this function has to have this data in order to properly perform its function. Good example in the real world, everywhere you go in the U S it seems, if you create an account with a company, they will ask you for either like a phone number. A lot of times, a lot of places like doctor's offices, things like that, they'll ask you for a social security number. That is not needed for anything that they do. Phone number may be for them to contact you, but as an ID, no, it's not. They can create their own stinking ID. You can be patient one, patient two, patient three. It doesn't, doesn't and should not have anything to do with you or any data about you. That's a whole different, any pattern problem that we run into. So if you've got a patient object and one of the things it has is a social security number, that's not good. You don't need it. There's no reason for it to be there. There's nothing that you do related to healthcare. Theoretically that requires a social security number. Likewise, you don't need, let's say patient salary. You don't need their salary. You don't need to know what they make. You may need to know what their job is, but probably not. You need to know what their, you know, especially if this is a treatment type of thing. Now I guess you salary if you're dealing with payer and insurance, but if you look at any given form, particularly the worst ones are if you go to schools, secondary schools in particular, but even colleges have that. They will have application forms or they will ask you so much information that really has nothing to do with your education or paying for your education or why you should be accepted or not. I think the most most obvious common thing that's out there is race. There is very little that in the world of forms we have to fill out, there are very little problems where those forms are being entered, where race matters at all, or at least should matter at all. There's no reason to know it. Who cares? Health? Actually, yeah. I mean, there's differences. So there depending on what your race, you're going to be predisposed to certain things and certain stats are going to be different, things like that. Okay. Everything else? No. Race should have nothing to do with getting into a school, with signing up for electricity or getting a phone or all the other things we fill forms out for. And yes, I digress. But the point here is that we have data and we have functionality that is within our problem space. And then because of the way we do our architectures, we have things that are general purpose. There are things that we want to reuse across problem spaces in different silos of problems and solutions. And we want to make sure that those types of components or objects are designed in a way that they do not have a requirement or really even a knowledge of the other components. And think about a horizontal one. If I build something for my application, and I don't even care what it is, I just build something for my application and I include vertical data. Now when I move that horizontal thing to another problem, to another solution, it's going to be looking for data that may not exist in that vertical. And we've seen this sometimes in badly designed systems and solutions. Let's say we have... Well, let's say, let's look at just a person. You've got a contact. Now there's a contact form for, let's say, it's for artists, for musical artists. In our system, one of the things we track is when they're... Let's say what's the instrument they use, voice or whatever else. What's their instrument? So we have that. Well, now if we go into something that is an employee application, and this is employee for, let's say, I don't know, checkout counter at a grocery store, don't care what their musical instrument is. So that system, why would it have that field? Why would it care about that? Why would it require us to enter a musical instrument when we may not even know? Not only that, they may not have a musical instrument. Maybe they can't sing. So then what do we do? And you will see this in situations where there's data or there are items or there are fields that are essentially unused. You see lots of empty or null data because it wasn't designed properly. It was designed with some vertical or horizontal piece to it that it shouldn't have. And you can see this either way. And again, a lot of times it's a convenience thing that was built in originally and really just should not have been. So that's what you want to look for is does this do what it needs to do? Does it have what it needs to know? Does it have the data and the tools to be able to do the job it's needed? And that's it. Is there anything we can do to strip this down, to trim this down, to have less data or information or even functionality and still do what this thing is purposed to do? When you go at it like that, you're going to be much more likely to avoid a jumble. You're going to have nice, clean, well-defined components that easily can move vertically or horizontally. That being said, it's time to slide horizontally down the road until we get to the next episode. But as always, 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. 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, it'd 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.