Architecture by Implication

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 when we're looking at architecture patterns and anti-patterns. We have started with patterns and we're now getting into the anti-patterns portion of the season. We have gone through quite a few patterns. The anti-patterns we're going to talk about are going to sometimes feel a little bit familiar, maybe similar to some things we've discussed in the past. Maybe even not an anti-pattern per se, but definitely a don't do this kind of thing. This episode we're going to dive right in and this is probably the worst and maybe the most frequent of anti-patterns. It's called architecture by implication. And this is basically, we're just going to do it and assume that everybody knows what we're doing. In a nutshell, we are not communicating. We're not really thinking through what we're doing and we're just doing it. This is often based on an assumption by probably numerous people that are involved in the project, the solution from designers, implementers, whoever, where the assumption is that we all know what we're doing. We're going to do this thing this way. And it's so obvious that everybody knows it and everybody knows how to do it. The funny thing is that never really happens. I don't care how obvious something is. I don't think there's anything out there that's such common knowledge that you can go to even the average room full of people, dozen people, two dozen people, whatever, and get the same description or definition from each of them. In some cases, that's not going to matter. If you ask a room full of people how the game soccer is played, more or less you're going to get an idea of it and that's okay. However, if you actually go to play a game of soccer, there's going to be rules are going to be missing. There's going to be a confusion amongst those people on what the rules are, how they work and everything about it. Maybe even from number of teams to, or I'm sorry, number of players, maybe even number of players, the amount of time spent, what constitutes time running and not running, balls in and out of bounds, all that kind of stuff. Software way more complex. When we assume or walk into an architecture and say, okay, let's just give it, we're going to give it a label, even if it's a well-known pattern. Think of any of the patterns we've done. We're going to go in and we're going to do a, we're going to use a microservices pattern for our architecture. All right, everybody go. That is not going to work. People are not going to be on the same page. That's the challenge of this anti-pattern is that instead of everybody rowing together and going the same direction and building something in a way that is a coherent way to do it. People will have their own little variances on how to do things. And this is not an indictment of the individuals. They may not know that they don't have quite the same point of view as a person next to them, which is a huge danger of this pattern. This anti-pattern is that we fall into it and we don't really know that we're in it until it's too late. Basically, we get to a point where maybe the rubber hits the road. Maybe sometime before that where we're, maybe we're into deep into design discussions or QA and where something comes up and things aren't quite looking right. Or maybe we've got a situation where we have a lot of the implementers are sort of in their own silos. And there comes a point where somebody has to work cross silos and suddenly they realize, hey, the architectural approach those guys are using does not really match what we're doing and that may cause a problem. Now yes, honestly, you could architect all the silos potentially very differently and find some way to make it work. That is not an impossibility. However, the maintenance side of that becomes a nightmare because then whoever's maintaining it has to think about the architecture in the particular way it's implemented in the silo that they happen to be working in. That is not a trivial thing to do. And it can make it very confusing, very hard to ramp up to understand what's going on enough that you can maintain or enhance that code base. And that's at a high level. There are often going to be lower level details that come about based on the architecture and more specifically, of course, the design of what we are building. If we build our solution with an architecture that in one case is expecting one very smart or very solid connection, like a plug-in, but there's another part of the architecture that says, oh, we're going to have all of these little loose fitting microservices. Those things probably aren't going to work. Think about it from a hardware point of view. If you expect one strong, big connector that's just there versus maybe a connector that's like a bunch of little wispy wires, those are two very different connectors to deal with. So we can have, in that case, something just doesn't work. You've got one case where you've got a solid plug interface and you're trying to just throw all these wispy little wires into it. Or the other one, you've got something where I guess somehow you're trying to feed all of those little wispy interfaces in. Okay, it's not a perfect analogy. Nevertheless, very different approaches, very different architectures. And if you're not communicating, that's a problem. And that, of course, is the bare bones problem that we run into with this particular anti-pattern. It is lack of communication. It is assumptions. It is that when we come in, and this particular part here is way too common. When we come in with language or labels and say, because we do A, B, and C, these labels, everybody should understand what those are. That happens, as I said, way too often. And it is often a big problem. You want to open a can of worms? Ask everybody on your team, however big or small it is, what does it mean to be an agile team, to use the agile methodology? Heck, what's a sprint? What's a scrum? What's a standup meeting? What is a software architect? What is a senior developer versus a junior developer? Things like that. These are all titles. They're all labels. And they're all going to have various views and perspectives on them and experience with those things so that you can't have a team that comes together and just knows it. You have to lay out what we agree these things mean. And that doesn't mean that any one person in the group says, okay, we're going to do pattern. The Foo architectural pattern. And we all know what it is. Okay, we don't. So we talk about it. Whatever we end up doing, we as a group may call it the Foo architectural pattern, but it may actually not be the same anywhere else. And that's okay, because in this case, we talk about it and we make sure everybody's on the same page. This is what we're doing. This is how we do it. This is what this means. It seems often over architecting or being a little bit too detail, detail oriented or even OCD to have almost a definitions kind of section to our documents or to our discussions where we say this is what we'd mean when we say this, when we say that, when we say the other thing, this is what these words and phrases and approaches mean to us. And we have to make sure that everybody agrees on that. And actually, I guess not even that they don't have to agree on it. They just have to know that that's what we're doing. So at some point it's like, I don't care what you think the Foo architecture should look like. We can all sit down and say, this is what we're doing. We're going to call it that. And it's just a name. It's just a label. So who cares? We find this in interviews all the time. It's amazing how often somebody will say, how do you use or what do you think about this pattern or this anti-pattern or this commonly known software development approach? And you're going to get different answers, not just based on background or experience or years of experience, but all of the above, including what companies they've worked at, what are the coworkers they've been with. All of those are going to have some sort of an impact or maybe even just a nudge on how they view that term, that role, that pattern, that label. So if you try to work with just labels, you're missing a way to communicate. Those are great ways to get people in the ballpark sometimes. But when we're talking about software development, we need to be more than in the same ballpark. We need to be on the same page. We need to make sure that we communicate what we're doing, how we're doing it, and what we plan to do so that everybody understands. And everybody is not just our silo or our little group. We need to have this in a way that all of the members of the solution, from product owners down to testers to deployment specialists, coders, designers, whatever, that they understand it to the level that they need to understand it. That doesn't mean that the CEO of the company needs to understand what this architecture means when it's implemented in Java. But there is going to be some piece of that architecture that is going to be important for the CEO to know for their job, for selling the product or explaining it to others or being another set of eyes to say, hey, are we doing this right? Are we following our own pattern, our own choices properly? So while this thing, this anti-pattern shows up a lot and can go very bad, it's also not that hard to avoid. We just need to make sure that we communicate. And this doesn't mean we necessarily have to be writing stuff up all the time. If you look at the, go back to that agile thing, go with the sprint daily standup kind of approach. If you're having daily meetings, then you may be able to have those daily touch points to be able to just reinforce this is what we're doing. This is how we're doing it. Any questions? No. Okay, great. We're going to keep moving forward so that if there is a misunderstanding, it will hopefully surface sooner and then we can clarify as needed. We can make sure that we straighten things out so we are all back on the same page if we drift away. That is architecture by implication. It's saying, hey, I'm saying we're going to do this by this. I'm just saying a label or a name or a buzzword or something like that. And then hope everybody means that, you know, knows that that what's that mean and they understand how to do it in the same way. If they don't, it's going to be problems. So instead of just saying, hey, we're going to go do X, explain it. Now that may be a challenge because there are situations where people say we need to do this. We need to do microservices because they're cool. Everybody loves them. Okay, what's a microservice? What does that architecture look like? How does that apply to our problem? Ask the questions, get the answers. And sometimes it's just going to be, they'll say, oh, well, you do A, B, and C. Okay. And then what? All right. That's great. That gets us to this point. But now there's then what do we do? How do we extend that? How do we move that into building this entire solution? You don't need all the details, but more often than not, you need more than a couple of pie in the sky, 50,000 foot view types of descriptions. You're going to need to be able to find a way to take that down to ground level from 50,000 feet. And so there needs to be enough communication that everybody understands that journey from the 50,000 foot view to the ground level view. That's going to do it for this anti-pattern. It's when it comes down to it, don't assume, document, communicate, communicate, communicate. And that will help you avoid this particular anti-pattern. But oh no, there are many, many others out there. Communication is not always going to be the solution. Sometimes it may even be the problem. So we're going to keep looking at these, keep plowing ahead through this season, 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. 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.com if you would like more information. Now go out there and have yourself a great one.