The Wolf Ticket Anti-Pattern

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 software architecture patterns and anti-patterns. And we are into the anti-pattern portion of the season. This episode, we're going to look at the wolf ticket anti-pattern. Now, we've talked about this before, and there are a couple different ways people look at it. In this case, I think it's easiest to think about the wolf portion of this anti-pattern, as in a wolf in sheep's clothing. Because a wolf's ticket is, it's essentially where we are acting like we're doing the right things, but we're not really. It's almost a smoke and mirrors kind of thing, but it's not necessarily, actually, and it's not really intentional. This is good intentions. We think we're doing the right thing, we're crossing our T's and dotting our I's, but we're not really. We are trusting a little too much that everything's going to go our way. And so, just to define what's a wolf ticket. In general, the wolf ticket anti-pattern is where we have a standard, but it's really a de facto standard. We have a standard that may be very well defined, but we're not doing anything to hold ourselves to that standard. There is not vetting or a validation or something that ensures that we are compliant with it. It's like getting a stamp of approval without even looking at the thing that's being approved. That would be a wolf ticket. It's a rubber stamp kind of approach to things. So, if you think of a peer-reviewed article, that has, in the scientific world, some sort of a weight to it. It says, hey, this person spent some time thinking about it, other people spent some time thinking about what they did, and this should be a well-thought-out document. However, if the peers of the peer-reviewed portion of it just look at it and say, oh, this was written by smart guy Bob, and they don't read any further, then very quickly you could have stuff that makes absolutely no sense, but has this stamp of approval of being a peer-reviewed article. Standards and software are the same way. We have standards that are sometimes well-defined and easily measured against. Typically, think of like, probably the best examples would be development languages. You either are conforming to the syntax or not, at least the core, and this is where we can get into de facto standards. We've seen this in browsers, web browsers, probably the biggest example in the last few decades. We started with something that was well-defined. We had the World Wide Web Consortium get together and say, here's what HTML looks like and here's how it works, and then people started adding to it. And then people said, oh, well, this is a nice start, but there's some extra things we want to do. And so as people started growing, it didn't get fed back into the standard. So if I grow it and do it one way and you grow it a slightly different way, then we're starting to go down this anti-pattern path because we have something that technically is standards, because it's standards-based. We both started with this, in this case, an HTML standard. However, we drifted from it. And so now we've sort of introduced into the system some other options, but they're not standards. They're things that maybe they're standard for us. Maybe people that work with us see them as a standard, but they don't realize that's not the case. You also see this in a framework or a library sometimes that is built on top of something else. And there will be maybe some features or conveniences that are provided by that library or that framework or that tool that people start to think are standard, and it's not. And a lot of times you can see this in far-reaching and more general types of standards. HTML would be one of them. SQL, for the query language, is the same way because you have a core SQL, but every vendor has added to it. They have their own. They have the core, and that works well. But then they add all this other stuff, and it's really easy to get lost in what is an add-on and what is part of the standard, particularly if you have an evolving standard. If you've got a standard that's changing every few years, and it's growing, but you also have other tools and libraries and frameworks that you're working with, and they are making their changes, then it can be really hard to keep up with what's the standard and what is a vendor-specific or implementation-specific piece of it. Now, in our focus on software architecture for this anti-pattern, the way this shows up is that we essentially say, here's some things that we want to do, and this is how things work. But if we don't have, for example, code reviews and maybe tests, some sort of unit testing or regression testing or something like that, something that validates that what was built actually follows that architecture, there can be problems. There are ways that we can sort of with a wink comply with something without actually complying with it. And this is where the anti-pattern starts to rear its ugly head, because what we end up doing is that we have something that on the surface conforms to what the end is, and we'll say proper or valid, but underneath it really isn't. And it may be like corner cutting or something like that where it was just done to quickly get some code out, or it could be because nobody realized, whoever created or implemented that, they didn't realize that, hey, wait a minute, this isn't exactly the way it's supposed to work. And that could be very much an honest mistake that they just don't quite understand what is intended in that standard. And so this again points to a challenge that we have when we don't have proper communication. And lack of communication or we'll call it fuzzy communication can lead to anti-patterns. If we have assumptions and if we have things that are not fully defined, then that allows gaps. That allows us to have instances where somebody thinks they understand it, but they really don't. And so you'll start seeing all kinds of interesting stuff when you hit this anti-pattern, because as it grows, the challenge is that anybody maintaining it will come in thinking, oh, this conforms to these standards. This is how it works. This is how it should look. And it doesn't. And because people have incorrect assumptions, they can spend a lot of time chasing something down that is completely a red herring, that is completely different from where they need to look. Think about anything broken, any complex piece of machinery that's broken. Let's go with the car. If the car stops moving and you assume it's the engine, you could end up turning the whole thing apart and rebuilding it and still not doing anything, only to find out later that it's not moving because there's no tires on it. It has no wheels or something like that, because you assume the wheels were there. And if you never checked, that could be a problem. Whereas if you didn't have that assumption, that may be one of the things you would check right away is do a quick surface check on everything and say, oh, wait, we don't have tires. Let's get that fixed. Sort of same thing in software. You can, through your assumptions of the standards, say that, oh, this thing must work or this thing must be architected in this certain way, so that if I see an error at this point, then that means this is the code I need to be looking at, which could be incorrect because your assumption of how it works, how it flows may point you to the wrong place. Now, because this is also, although it can be an intentional kind of thing, usually it's going to be unintentional, which means this is an anti-pattern where it's based on we don't know what we don't know. So we go in, whoever the one is that is, or people that are building out this anti-pattern, they're not knowledgeable, they're not cognizant of the fact that, hey, we're doing this wrong. We're not conforming to the standard. So the way to avoid this anti-pattern is to make sure that we do things that confirm for ourselves and for the teams that we are on the right track. And that includes things like code reviews or peer reviews of some sort of whatever's being done. It may not be code itself. It may be some sort of configuration review. It might also be, and what helps it a lot is proper testing. Unit testing helps because you get it down at that core level, but also integration and regression testing so that as things are added, we can validate that they are being added in the right way, that they are being implemented properly. And we want to make sure we do this in a way that brings the whole team in, that they're all on board, that this is the standard, this is the approach we're taking. And when somebody is off, when they don't understand it correctly, or they have a different view, that we make sure everybody agrees and bring everything back into line. It's about all of us being on the same page, all of us moving in the same direction and not having some people because they just don't, they haven't read quite right what the architecture is or the process is, or they just don't have a complete and full understanding of it. They could wander off the path. And this again, this is a challenge in everything. This is why when people build a building, when you're constructing a building, you have all of these checks and balances for your measuring. You know, that old saw of measure twice, cut once. Same thing, if you are building a skyscraper, then you're going to be constantly checking your angles and things like that to make sure that you don't start in a direction and with just very minor variances end up in a very different place. Try to walk a straight line. If you're not constantly adjusting back somehow to know that you're on that straight line, you're going to find that you can easily veer off of it. You may veer back on as well, but you've got to have a check to make sure where you're where you're at currently and adjust accordingly. So that's the wolf ticket anti-pattern. It is a wolf and sheep clothing. It is us thinking or in appearances, we are doing the right thing, but we actually aren't. And again, we may not even know that we're not doing this right. So this is where again, communication helps a lot and interaction with the team is important. Interaction with the team, code reviews, testing, as always, let's make sure that we're on the same page, that we all agree what we're doing and that we're all holding each other accountable to keep doing it in that way that we've decided on. That is how we avoid this anti-pattern. And now we can move on to another anti-pattern. So we're going to wrap this one up and we will come back next time and we will hit it again and keep working through some things we don't want to do when we're dealing with software architecture. 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 dot com if you would like more information. Now go out there and have yourself a great one.