Coding Blocks - Software Design Anti-patterns

Episode Date: August 21, 2017

We've discussed design patterns too much. Now it's time for some discussion about anti-patterns as Joe has dark visions about robots, Allen has to take sensitivity training, and Michael picks Arial.

You're listening to Coding Blocks, episode 65. Subscribe to us and leave us a review on iTunes to turn more using your favorite podcast app. And check us out at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at CodingBlocks.net. Follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw.

All right, first up, we got a bit of news. So big thanks for the reviews as always. This time we're appreciating from iTunes, Barkadood, RobertJF, MeagerFindings, WhiskeyCoder, SPSlack, SungMeister, StudentBoy87, Flotmand, WeagerFindings, WhiskeyCoder, SBSlack, SungMeister, StudentBoy87, Flotmand, WeJavaDude, and Naraf.

And on Stitcher, we have WhiskeyCoder, Dance2Die, and CaptainKippers. Thank you very much. Hey, did you hit record on the video? Yep. Okay, cool. Because I forgot it in the last couple times. Did you happen to notice that one of those was said twice?

I think I did previously. Who was it? Was it Dance Today? No. I don't know. Where was it? Whiskey Coater. It was Whiskey Coater.

Yeah. Yes. Thank you very much for doing that. All right. And as always, for the full show notes for this particular episode, you can go up to our website. The most recent should be there at the top, but if not go to www.cuttingblocks.net slash episode 65. And so let's go ahead and get started with a little bit of news here. And the first one is I had promised that I was going to do a video on the specification pattern

because it seemed a little confusing when we were talking about it on the show. And I have done said promised video now. So I'll have a link to the show notes or in the show notes here for that video up on YouTube. It's a little bit long, you know, just stick it on 1.5 X and blow through it. I do have links to GitHub on the video description so that you can see the actual code for the patterns library that I put together, which has got the specification pattern as well as the sample code that I was going through in the video. So both of those are there. So do go check that out when you get a chance. Yeah. In fairness, what are you calling long? I think it's 26 minutes. Is it? I don't know. I call that out only because someone else pointed out the Pluralsight course,

and it's an hour and a half. For the specification pattern? Yes. Okay. For the one pattern. All right. So you can get a real nice preview. So just consider yours is already being played at three times.

That's right. That's awesome. I actually don't even, I haven't seen that other course and mine's, I guess it's sort of brief, but yeah, I mean, 26 minutes is a, is a little amount of time to go through, but you know, hopefully it'll help somebody out and maybe clear the waters a little. Yeah. And, uh, I wanted to talk about my headphones. So, uh, I got new headphones and i'm definitely not the sound spurt uh that alan is but i got the logitech g633 i got some some refurbs for what i thought was a pretty good deal turned out to be just kind of normal darn you amazon but i wanted to mention here because

they have a really cool feature where they have a 35 millimeter jack and a USB. Very nice. You can have both on at the same time. Oh, at the same time. Yes. Amazing. I know. Wait, what would you use that for? And what that means for me, I say what? You'd have both the audio, the three and a half millimeter plus the USB at the same time.

But why would I want that? So for me, working from home and doing a lot of Skyping. Some days a lot of Skyping. I listen to music on my phone. And so normally I used to just have kind of the phone plugged into some earbuds. And when it was Skype time, I would kind of hurry up and take the headphones off, grab my USB headphones and get on the call and tweak the levels and stuff. But now it's so nice to like when the bring, bring, let's talk about something. off grab my usb headphones and you know get on the call and tweak the levels and stuff but now

it's so nice to like when that you know bring bring let's talk about something i just kind of hit answer i've already got the headphones on and what's funny is i thought it would kind of stop the music on the iphone uh but it doesn't so it just kind of keeps going i think it lowers it quite a bit but it's still kind of funny when you know calls to talk about, to have like a talk, and you've got like Disco Inferno in the background. But it does lower it though. So you've got some nice background music while your boss is chewing you out. That's kind of good.

Yeah, exactly. I'm just there staying alive, staying alive while he's, you know. They definitely look like something that you would see in a Tron movie. Oh, you can control the lights too. You can pick the colors. You can do other, they breathe or they change colors or flow. That's really cool. So yeah, definitely go check that out. We'll have a link here in the show notes for that as well. And also I do want to give a tip for that because man, I get hit up a lot on Slack on, Hey, do you, does anybody have any headphone recommendations? And of course I have lots, but I will say this, if you want to go try them out now in ears, you're stuck. If you

want in ears, you're not going to be able to try those out anywhere. Nobody's going to let you do it because they don't want them in your ears because then they can't sell them. Right. But over the ears or on ears, a lot of people think Best Buy and all that. And certainly that's a good place to go. Another place you can go is the Apple store. If there's one near you, they almost always have a set of, or several sets of different types of headphones available. But one that a lot of people don't think about if you're not into playing instruments is a guitar center or I don't know, is Mars music even a thing anymore? Cut by a lot. I think about Sam Ash. Okay. So Sam Ash. So ash so guitar center sam ash go in there like typically they have some really nice headphones for sale that that you know anywhere from seriously 30

bucks up to like 200 but you can try out a bunch of different headphones and one of my favorite sets there is the audio technica m50s uh the m50x specifically you know you can go into those places and try them out and see what they sound like so little tip oh okay i gotta bring this up sorry derail i was listening to the latest reply all it's the one where um like the first part of the episode the guy call like someone calls him on his phone says hey your phones and or your computer's infected let's hop on and you know it's a scam and anyway he ends up going over to india uh to kind of investigate and uh he ends up running into a headphone bar which have you ever heard of a headphone bar no yeah uh i hadn't either apparently there are bars at least in india where um you go

in and you kind of rent headphones and listen to music on your headphones and you can so it's like kind of silent inside right but you've got people walking around and maybe they're listening to one of the same three djs maybe they're like listening to you know something else or maybe they're just hanging out in the quiet i just thought it was like a totally bizarre thing to think about you know this kind of silent room with people still kind of dancing and shouting at each other that is odd i'm going to be looking this up. I'm sure there's videos on YouTube. Yeah, maybe we'll maybe we'll start one. Hey, yeah, there we go.

Kennesaw headphone bar. So what you got up next? I'm just looking at this headphone bar thing. Yeah, he has me more intrigued by these headphones. These G633s, he said. Yep. I paid 70. It looks633s, he said. Yep. I paid 70. It looks like Amazon's got them for 89 today. When I thought I was getting a super deal,

they were around 100 on Amazon. I should have checked out like Camel, Camel, Camel or something. And they're comfortable? They're a little tight on my head, but I just kind of grin and bear it. And I wear them for like six hours. Oh, yeah. It's got some bass. It's got 7.1

too, so surround sound. You said the magic word. He doesn't care about treble. It's all about that bass. Which is so odd that that song has none. It really has none. It's a terrible representation. For a song that's all about it.

All right, so next up, what you got jay-z uh all right um oh so uh book club this is something we've talked about a lot of times in the slack channel on the uh the books channel uh like the ability to basically read a book together and kind of talk about it and i've looked at a couple sites they're definitely if you look for like online book club you'll find a bunch but it's always like oprah book club or somebody else's book club where they kind of you know pick a book and everyone reads it and there's a forum and what i kind of like is would be to have some sort of like location or something where you could kind of have like an existing forum so that somebody can come along you know a year after the fact read and still kind of get involved in like the forum so i didn't know if anything like that existed so i just want to kind of put the call out there i've got a couple suggestions a couple things on twitter to kind of get involved in like the, the forum. So I didn't know if anything like that existed. So I just want to kind of put the call out there.

I've got a couple of suggestions, a couple of things on Twitter to kind of run down that I wanted to look into. So, you know, maybe this is already been answered and I just don't know it, but I just thought it was kind of interesting. And if that's something that you'd be interested in,

just kind of let us know somehow it's something we're definitely talking about. I'd really like doing it. And actually I think that the, the original idea came from dance to die. So I'm also a big reader of his blog. Awesome. Excellent. All right, so my next piece of news,

I just found this out the other day when I was creating the video for the specification pattern because you guys ever notice or have you just completely blocked it out now? Like when you open up Visual Studio, there's usually the recent news or whatever section that's in that window. Like it's almost like when you know that there's something and you've seen it so many times you walk by it. That's usually me. But for whatever reason, this caught my attention the other day, probably because I was in Visual Studio 2017 for Mac.

And I saw this announcement that.NET Core 2.0 was out for Microsoft. So it's actually officially been released, I think, as of yesterday, as aNET Core 2.0 was out for Microsoft. So it's actually officially been released, I think as of yesterday, as a matter of fact. So along with that, and I've got a link to the article on MSDN right now that mentions that. Also ASP.NET Core 2.0 has been released, Entity Framework Core 2.0, and.NET Standard 2.0 has been released. And here's the part about it that I think is interesting is a lot of people have never even heard of.NET Standard. And that's a shame because it's major. This thing has over 32,000 APIs to where what they've tried to do is they've tried to create

like this wrapper, this abstraction around.NET Core and various other pieces so that instead of coding directly to.NET Core, you can code to this.NET standard and it will go across platforms a little bit better. So they've kind of abstracted this thing away so that you're not always stuck working at one level or so deep. You can come up and it'll go across Windows Mobile, it'll go across ASP.NET, it'll go across Windows Desktop. So.NET Standard to me is actually like, it's one of those hidden gems that a lot of people don't know about. So anyways, definitely check this out. But there was one key piece of information I saw in the article that is super exciting because this was not the case previously like if you were coding.NET standard it had to support the various different things now what they said is you can reference the.NET

framework libraries from.NET standard libraries using visual studio 2017 15.3 this feature will help you migrate your.NET framework code to.NET standard or.NET core over time. That's killer because before, if it wasn't implemented in the.NET core or whatever you were targeting, you were just kind of out of luck. Like you couldn't even use the.NET standard thing to wrap it. But now it sounds like you can bring those DLLs along and it'll play nicely with them. So that's a huge step, at least from what I'm reading here. That's a huge step. And you can start coding to.NET standard, which will get you in a position where you can actually start porting across different platforms a little bit better.

So in a more standardized, abstracted way, which is pretty awesome. So pretty exciting stuff. I need to read into it a little bit more but again the link's here so you guys can all check that out and then the last thing the last little bit of news that we have here and hopefully this will be out before the 21st man the solar eclipse is coming up oh that's right that why you had that i didn't want you guys to know what i was talking about right that is the full the the total solar eclipse is happening this coming Monday, the 21st. So, you know, hopefully you've gotten your glasses. If you haven't, man, good luck.

Well, this is only a total solar eclipse for people in a very specific region of the country. Well, no, no, it's all across the country, but in a very specific band across the country. Right. So there's like, I need to, I'll, I'll find a link to the site that I found where somebody, a programmer had written an API for Google maps that shows the band coming across and you can search for a spot on there and it'll show you if you're in the totality zone or not. So it was a good use of the API, uh, really cool stuff. So at any rate, hopefully you got your glasses. If you hadn't like me, then you probably just paid way too much for a bunch of paper glasses that are going to be shipping my way hopefully this week. So that is it for the news.

All right, well, let's get into the meat of our topic tonight, which is all about anti-patterns and some of the big ones that we might face. So we're going to start with abstraction inversion. So I'm going to say the quote simple definition that they have here. This is taken from Wikipedia, and it says, not exposing implemented functionality required by callers of a function, method, or constructor so that the calling code awkwardly re-implements the same functionality in terms of those calls. What?

That's clear as mud, right? In English, please. Yeah, so that was unfortunate. But what I've eventually distilled from this after reading on some other places is that basically what I previously said was a complicated way of just saying you try to implement what should be a simple concept

and you build it on top of complex concepts rather than the other way around. So you're saying that the abstractions are actually making things less clear than easier? So here's an example that can illustrate this really good. Let's say, let's say I ask you to implement two functions. The first function needs to output, needs to print out text to the console. And then the second one needs to print out formatted text to the console. Okay. Now, typically what you would think is,

okay, well, let me write my first method that just prints out whatever it's given and put it out to the console. And then the formatted version is going to do whatever format is necessary and then call the other one. Right. But in this case, picture you did the inverse, and you write the formatted version first, and then you call what should be the simple, the less complex version, i.e. the no formatting version. You write it so that it calls the printed version just with no formatting specification. Does that make sense?

So you're saying that you called the more complex one from the simple one instead of the other way around? In that particular example. Okay. I don't think I got that one. So we're saying there's two, there's like a pretty print,

like a formatted one, and then there's like a kind of a normal one and we're saying rather than calling the pretty print on top of the normal we're having the normal one called the pretty print yes but you said in that particular example so well how would that change maybe you have another example yes so there there are definitely more examples. There was another one that was more physical, but another author was like, he disagreed with it, but it kind of does illustrate the point. But let's just say that this example is in question.

Whereas like, you know, you would use a battery to make electronic equipment, but to use electronic equipment to create a battery would be weird that seems like a circular reference as opposed to now that one doesn't illustrate it for me as well yeah well like i said that one was in that one was in question and i've got a link to an article here but uh another one another example that maybe this one will make more sense to you. I wasn't as crazy about this one and this is specific to Java, but they said like using a vector in Java to implement a fixed size list instead of an array would be an example of the abstraction inversion because

the vector is using an array internally. That makes more sense to me. Okay. So you're kind of doing things backwards is what it array internally. That makes more sense to me. Okay. So you're kind of doing things backwards is what it's saying. Well, now here was my favorite example, though. Okay. And I think we've talked about markup languages, storing things in markup languages before, right?

I know we've definitely had this conversation in professional environments, but the idea here is you serialize your object to XML, then you read it in. Now you have a DOM, right? So you now have program data, right, which is the DOM representing the markup, which is the XML representing the program data, which is the original object to begin with.

Okay. Do you understand? I think I do. It hurts my head. But basically what you're saying is you're using the more complex objects to now build the simpler objects that they're sort of based off of is really what it sounds like, right? Yeah, I think that's what i'm getting the abstraction inversion works well like in the vector thing right like a vector is a is a more full featured version of an array

or not full feature but you know it's a two-way type thing i think a vector is but it can grow right that's the difference versus the fixed size array. So if I remember right, and it's been a while since I messed with Java, but like you said, the vector is based off the array because it can grow. So it's almost like a resizing array, right? So the more complicated thing now they're trying to force it to, to create the simpler version of itself. Okay. Think about it this way. This is, this is my takeaway from this is that normally you would build these simple little building blocks, right? And you're going to piece those

building blocks to create a more complicated thing. Correct? So if we were to talk about a physical structure, right, we're going to create, we're going to lay down a slab. That's going to be the simple thing. And then we're going to take, we're going to have thousands of these little bitty bricks that are each one are rather simple, but we're going to be the simple thing. And then we're going to take, we're going to have thousands of these little bitty bricks that are each one are rather simple, but we're going to piece them together and create a complicated wall and a series of walls, right?

And we're going to keep adding on until eventually we're going to have a roof and a whole structure, right? So we took individually all these simple little things to create one big complex thing, flip that on its head. And that's the abstraction inversion. One huge complex thing to build a simple thing.

You're trying to create something simple. And in order to create that something simple, you're using all the complex stuff. Okay. That makes sense. So instead of using the brick to build a house, you're using a house to build a brick. Yep. Which is why the vector thing is crazy. It's way more complicated, and now it's creating this little tiny array type deal.

Okay, that makes sense. It's a weird one. I'll give you that. Yeah, I'm kind of wondering, how do I know if I'm going down this path? Is there some sort of signal or something that I can use to help me realize when I'm doing this? If you show up on Wikipedia as a subnote on this particular page, Like is there like some sort of signal or something that I can use to help me realize what I'm doing this?

If you show up on Wikipedia as a sub note on this particular, we finally found a real world example. Yeah, I'm sure this episode will be listed in the Wikipedia article for it. Right. That's a good idea. The abstraction inversion. Listen to how they made the explanation more complicated than the reality. Yeah, I don't know. I don't know. Listen to how they made the explanation more complicated than the reality. Yeah.

I don't know. I don't know. Also known as coding, boxing, right? Boxing. That's awesome. Yeah.

I don't know that there'd be anything other than just intuition, right? Like you look at it, you're like, wait a second. Why are you, why are you using this factory of factory of factories to create, you know, this little factory? I don't know.

I've kind of got this weird image of like a robot or a person or something with like all their organs like on the outside and you feel like interact with them by like squeezing the heart and then moving the hand to where you want it rather than just being able to say like, hey, robot, go do a thing. You know, like say you're very much in control of like their internals but i don't know maybe that's just weird yeah that's it's weird and irrelevant a little bizarre well that makes for a nice segue yeah so uh i promise you that the others aren't this weird at least the other ones I've researched.

But this, I had a real tough time with mine. I just didn't like it. I don't really get it. I feel like it's heavily based on stuff that I don't know about. And that makes me instantly disrespected. I never heard of this before, so it must be crap. But the one I looked into was called ambiguous viewpoint which is presenting a model which is uh heavily based on like object-oriented

analysis and design without specifying its viewpoint yeah please do explain all right so first let's start with what a viewpoint is so uh in the every example i looked at uh they were all kind of crappy i you know please if you've got a good example i can look at or a good explanation i can read or something i'd love to see it but everyone i found looks like they basically copy pasted the same text from the same source like back in 1970 and nobody gets it and they all just kind of paste the same one example and then move on to the next one but uh assume you know it's you even viewpoint bro exactly exactly and then no one knows what viewpoint is but there are three viewpoints that i felt like

this made a little bit of sense after talking about domain driven design so much. The first was the business viewpoint. So we've got problems that we're solving from the view of like a customer. This is coming from that the view of our problem domain. So like, you know, your customer service agent, or if you've got like an add to cart method or something like that, that's expressed in terms of the domain, and the language that's used to model your actual business process and that's one viewpoint the next was the specification viewpoint parentheses system and that's more of um we're not quite getting into code land yet you know so if a add to cart was business viewpoint, a specification viewpoint would be more like the website. The applications, the big higher level systems, you know, maybe we're talking about databases and middle tiers that are involved in making those kinds of things work. And then the third viewpoint is implementation.

This is where we're talking about software and design. This is where, you know, we get my cart bean from the user bean and we, you know, do something on it and add some items to our cart objects. So we're really talking about three different kind of levels of abstraction, which we're calling viewpoints for some reason. And we're talking about kind of mixing those. And the best I can come up with from the reading I did is that if we had an object that kind of shotgun all over all three of these kind of layers, so we have a method. I don't even know how you have a method that really involves like something at the system level. how you have a method that really involves like something at the system level but you know you just have things in this in this class uh or these methods that kind of talk to all three layers so we're not keeping our levels of abstraction consistent so you can imagine like having a method add to cart it takes in a customer object great but instead of a product, maybe it takes in a database connection string and a query.

And then at the final level, I don't know, like a bit mask. Or maybe it's writing something to disk as well. Like it's trying to get an access to a thread on a file system or something maybe. Yeah. So you can imagine a class where you've got all these thing three things going on so in order to do any sort of work with this guy you have to know about the business domain so you have to understand the rules you have to know about the various systems in play and what that means and then you also need to know about really low level

details like on how these uh like these things actually interrupt. Okay, that sort of makes sense. And so what they're saying then is this ambiguous viewpoint is when you mix different abstraction layers together, and so it becomes really hard to manage that stuff or really even understand what it's supposed to be doing in the first place, right? Yeah, you're like, I want to add to cart. Why am I talking about what level of SQL Server we're using? in the first place right yeah you're like i want to add the cart like why am i you know why am i

talking about what level of sql server we're using you know it's just we're kind of mixing the the modes of operation but i i think i'm reading a lot more into that than i read in this various slide shows and the you know three little bullet points that i saw uh in this place so i wasn't real uh happy with that kind of understanding that's just kind of what i got to after reading about it but i i think it does kind of align fairly well with just the idea that we're kind of dealing with something in from different levels of abstraction we've missed we've mixed our high and our low together okay i think i'll follow all right good to clear, these are anti-patterns.

Yeah. It's like, hmm, that sounds kind of cool. All right. The singularity. Anything for you, Outlaw? No, I'm thoroughly confused. Thank you. Okay, good. All right. Moving on. I think this one, all right,

so this is the first one that I think maybe we can all feel good about because I think this one's pretty clear. So ironically enough, it's called the big ball of mud. So it's clear as mud. And this is basically a system with no recognizable structure. And we've all worked in these. As a matter of fact, if you haven't, you're probably not far enough along in your career to understand that these are real so basically a software system a ball of mud software system is one that lacks any type of perceivable architecture and this is this is interesting the way that it was stated was this is due to code entropy and basically there the rule of entropy i forget it has something to do with uh thermo something never destroyed or created yeah basically all all become more

complex or yes like kind of fall apart that's exactly organized nothing goes away it just gets more complex so basically what the whole thing is is your complexity grows in the system as modifications are made, unless you try really hard not to do it. And that's really the key here. And that's kind of how software, and it's funny, the nice way of putting this is organically grows, right? Because that makes it sound not so bad.

If it's organic, it's got to be sort of good. You know? All right. Agile. Exactly. So here's the thing. This is where the term spaghetti code typically comes from. And I love the way that he stated this. And there was some sort of something that was referenced in the Wikipedia where they say that this typically happens due to unregulated growth and repeated expedient repair. So basically get it done now. You got

to get it done now. You got to get it done now. And this is typically what happens, right? Because you're always fighting the clock and you're always trying to get things done as quick as possible. And that's how your code ends up in the state that it is. They also say it's typically developed over a long period of time with multiple developers, or you have a group of developers working on small parts of the problem incrementally over time, rather than before you get started on little bits and pieces of it, understanding the overall problem. So as you're moving along, you know, some of you like, oh, well, that's not right. And then, and then you make a hack and then, oh, well, we need to do this. You make another hack, right? And so you just keep repeating that until the complexity grows and you've kind of got this mess left to

maintain. Okay. So how do I know if I'm going down this path? Like I know it after the fact, I can easily see, you know, the problems, but when I'm in the moment. No, I think it's easy to see in the moment, right? Like if you copy and paste a piece of code, instead of thinking about how is this shared, that's almost the first step, right? Like if you copy and paste an entire chunk of code, the first,

this doesn't necessarily have to be about copy and paste. No, no, I'm just saying that's, he said, how do you know that, that you're starting down this path, right?

Like that's one. Another is, you know, you're working along like this incremental thing. You're working along and then all of a sudden, oh, we need to do this. And it's structurally very different than what had been designed up to that point. And instead of actually stepping back and saying, okay, how can I make this thing work properly? You put a bandaid on it, right? You've now gone down that path. You've now said, oh, I think that we can force it in by doing this, right? Or we can trick it by doing this. As soon as you start making those shortcuts, um, decisions, you've pretty much started down that road and it happens, right? Like it totally happens you know

hey we got to ship this product tomorrow but we found this thing that's a problem but it just straight up doesn't fit in the overall architecture and then you're like well i can make it work right it feels like every program or every every software project will eventually become a big ball of mud without continued refactoring and cleanup. You can't... To Joe's question, I don't think you can know it in the moment until you've already gotten

to that point. You got to that point because you weren't cleaning up as you went. Maybe that's how you know. If you're never paying off any of your technical debt, if you're never cleaning up anything, then that's when you know, like, oh, well, we're building a big ball of mud,

and maybe we don't recognize it yet, but we eventually will. Yeah, you may not see it the minute that you're doing it, but as soon as you get some sort of task where it's like, hey, you need to go change this, what should have been a 10 minute deal turned into a two hour deal, you've been down that path, right? And unfortunately, that does happen a lot, right? And in order for it not to happen, you have to have the buy-in of upper management to understand that, hey, you know, if we take these short-term hacks and we keep going down this road, then in the future, it's going to be very time-consuming

to do much of anything, right? And to do it in a way that's not going to be dangerous to the overall outcome of what you're doing. And you've got to somehow sell it to upper management that, hey, if you'll give us the time to do this now, we can build a more stable system that we can expand upon further in the future quicker. We can iterate faster if we take the time now, but that's a lot of times hard to do because the whole purpose is companies are there to make money. And so it's a constant trade-off and it's difficult. And here's the part. Why do they exist? Because they work initially, right? You can keep iterating on something extremely fast.

You can keep plowing away at it and it's working, but there's going to be some sort of inflection point to where the time that it takes to make small changes or even fix things become so difficult and so time consuming and so brittle that you've probably crossed a bridge, right? And now it needs to start thinking about redesign or, or, you know, trying to work towards a better state. So maybe an example would be you create a permission system, right? And initially your permission system, right? And initially your permission system, you're thinking, okay, well, uh, I'll have a set of users and a set of columns on each user record in my table, right? That represent what permissions they'll have. And you know,

you might only have a few basic permissions in the beginning, right? And now, and that works initially, what you're describing. And then you want to evolve it into, you know, over time, you keep adding permissions and adding permissions until eventually this thing grows into, well, now to add in one additional permission, you have to touch 30 different places, right? Like that's the type of thing that you're talking about

where you just kept adding on to it. It worked initially because it was a small set and it was a small, very specialized kind of situation. But then as that thing grew and evolved into something big and your permissions got granular, without refactoring it into something that could handle that situation, it became a nightmare to maintain. Right. And now it's brittle, right? Every time you touch it, you might forget file number 23 or whatever.

So yeah, that's one. Another one that I can think of that we see and we've all seen in our career is we've talked about it. You know, database first kind of sort of is a lot of the time what people look at. And I know the structure and I know how the data needs to live. And now let's put an app around it. When you start accessing code using like queries all throughout your code base, there's no structure now. It's just willy nilly access to the database, right? Hey, go get some data from here and let's cram

it out here and put it in the UI and let's get data from the UI and throw it into the database. And instead of having like a centralized area where things go access that now refactoring becomes a major pain because, you know, if you change a column in a table, instead of there being one place that you may need to go change, you might have 50 places in your app that are all using that. And he might be aliasing it differently or whatever. So things like that are definitely notions where, you know, when you start seeing the same code in multiple different places, I think that's when you know that you've sort of gone down the wrong path. By the way, Joe loves aliases.

If you ever want to have a fun conversation, hit Joe up on Slack. And if you haven't already joined up on Slack so that you could have that conversation with Joe, you should head to www.codingblocks.net slash Slack and learn how to join. Yes, indeed. And then ask Joe all about table aliases. Yeah, I'll let you know. There's certain things I love to get on my soapbox about, and that's what I'm... I have a couple other kind of warning

signs that maybe you could kind of watch out for and I'm not sure if these are legit or not. This is just kind of things I was thinking about while we're talking about it. But if you find yourself control F programming, that's where you like, find one variable that has like a unique looking name and copy and paste it or search for it to see everywhere else that it's called the code base and then you go and kind of like tack on you know your your new section that kind of model after that yep um adding null checks this is what i'm really bad about and also kind of being safe like if um i don't understand how something works but i know there's a bug there i might be tempted to just kind of add the null check to just ignore that thing, because it doesn't really matter in whatever case I'm looking at, like, oh, the user is null here, for some reason, and I'm trying to do something on a user. So let me just add a null check and

just not do that if there's no user, no big deal. But what I'm really saying there is that there's a business process here that's now become misaligned with my code. Right. And I don't have the time or the understanding or the ability to kind of iron that out. And so I'm just going to make a little loophole here and call it done. So that you don't get the null argument exception or null object reference or whatever. Yep. Yeah,

exactly. Or, you know, like it's up a lot with like copy paste if you copy paste stuff from one area to another it doesn't quite work because there's this rule and that rule and so you just kind of delete those parts or tweak them in order to kind of make them not yell but um you know you really gotta wonder why you're doing that but then again you know you're worried about time you're worried about breaking changes because this stuff

is hard to work on and i started thinking about that that. It's like, well, why am I trying to program safely? Because I think this is a big, I'm a big offender here. So is the Jap, the Joe anti-pattern? Is that what you're saying? Yeah, this is one I'm very guilty of. I'm a spaghetti maker. Oh, that really was sick. Yeah, I really don't want that to catch on.

Well, okay, I take that back. This is the Zap. There you go. Zap. Snap it. Oops. There might be some editing to do. No, no editing. It was a pure accident. I want some sensitivity training here pretty soon.

I apologize. Oh, boy. Jeez. Another thing I kind of thought of is like if writing tests, if you think that writing unit tests would be difficult in your code base then you've probably got a big ball of mud yeah so we agree with that yeah i think so if there if there's no slices or no no patterns or no kind of you can't look at it and say hey this is separated from this then you got a big ball of mud right like if everything's just literally all jumbled together and you're like yeah i can't touch any of this

because it's going to break everything on the other end right like it's not just going to break it from here to here it's going to break it from here all the way down over there and then back up yeah you know that's what i'm talking about you mentioned those ad hoc queries that's what kind of got me thinking about it's like if you're able to just kind of reach from from here to anywhere to grab whatever you need in the moment rather than having like an organized flow, that makes testing difficult. And it's also literally, you know, kind of what you think about when you think about like spaghetti and meatballs all kind of jammed together. Yep. Yeah, I'm thinking like if you have methods that are hundreds or thousands of lines long, then you're in that category.

Yep, definitely. Switch case statements. Maybe even classes. Yeah, possibly, right? Those could use refactoring. It depends on what it is, but yeah. I mean, anything that's crazy long. Well, it's probably a class that's trying to do too much, right?

Like that was another one. We weren't going to get to it tonight, but the God object. So that's probably a class that is a God object. Yes. So let's move on to databases as IPC. So this one's kind of simple. The definition they have here is, a database is used as the message queue

for routine inter-process communication in a situation where a lightweight IPC mechanism such as sockets would be more suitable. So, I mean, this is just what you think it would be. It'd be a slow and inefficient way of, you know, trying to tell something else like, oh, you should probably go and process this job or do this thing, right? You write something out to some table, and then you're assuming that something else is watching that in a timely fashion, and then it's going to kick off some job. So it's a popular, it's popular because it's databases are way more widely understood than the alternatives.

Yeah. This reminds me of like chat apps, right? Like where, where if you're just going to write a chat app it'd be really easy to say okay i'm going to have a messaging table and you're going to write to that message and then you're going to send that message across right like as opposed to hey just connect these two sockets and and let the message go across a wire why do you need this intermediate right so yeah that that one's i can totally see why it's done because you're right. It's easy. You understand it. Okay. I'm going to write to the database.

I'm going to query the database and just constantly do that as opposed to, all right, open the socket over here and let's run this. So yeah, cool stuff. Yeah. I don't know though. I kind of like having to, not necessarily a database, but some sort of queue involved in case like say, you know, that message doesn't go through. Like if, you know, like I know Skype will very quickly email email you if you go offline somebody sends you a message and i like that

i want that right so i'm glad it's not a direct uh a direct connection i don't want to lose messages if i lose internet you know it's pretty rare and you know maybe if i'm streaming it's pretty rare i think to have messages that i don't care if they get through or not well but wouldn't the q be an interprocess communication form? It is, I think. And that's, well,

I mean, it could be, I think the key is here. This is databases, IPC, right? So if you're using something like a queue, then you're probably using the correct mechanism,

right? Okay. That's the way I interpreted it. Yeah. Yeah. So if you're pulling, if your code is ever pulling something, then there's a chance that, you know, you are doing this, or if you're polling if your code is ever pulling something then there's a chance that

you know you are doing this or if you're pulling a database a database yeah there you go database yeah specifically because people know how to do insert and select from it's so easy it really is it's easy to abuse and then and then you if you're you're it's a double win if you include that sequel in directly in your code right without a repository or anything oh stop it intermediary uh it hurts well how long do you create your big ball of mud somewhere you got to start somehow alan maybe you could just have layers of mud, right? Like you have some nice clean abstractions, but then you have a layer of mud and then you have some

more abstract. It'd be like a mud pie or something, right? So what about like flavored mud of the week where it's like one week I'm reading about functional programming. I'm excited about that. So you see a bunch of like static classes and then I start reading domain driven design. Yeah, it definitely happens. Yeah, well, I got these aggregate roots all over the place.

But that's some sort of architecture. There's just balls of architecture all over the place. Well, your layers of mud, I thought you were going to go down the lasagna path. I haven't because I think we're going to be talking about that shortly. Not tonight. Oh, yeah. That was another one.

Lasagna code. Cool. This episode is sponsored by Airbrake. Hey, listeners, do you hate spending time checking logs, running ad hoc queries, or searching your emails for clues on production support issues? It's especially bad when the customer tells you about the problem. If so, then you should take a look at airbrake.io. It's a service for alerting and monitoring so you can proactively address issues and spend less time playing catch up. Airbrake supports.NET and all major programming languages and platforms, which you can see on their GitHub page. There's a free trial, which thanks to your feedback, no longer requires a credit card number. So you can check it out risk free at http://getairbrake.com.

All right, next one up is gold plating, which is continuing to work on a task or project well past the point at which extra effort is no longer adding value. And my first thought was like, who the heck has this problem? Am I right? Wait, open source projects maybe? Yeah, maybe. I can see that. Come on. You've never just

refactored something beyond the point where you're like, okay, I really want to clean this up one more time. There's one more thing I want to do here, but is there any value to it? No. Rarely. I don't think I've ever refactored. There's been times...

Alan, are you ready to write the first time? I don't think I've ever read Factor. There's been times. Alan, write the first time. I definitely worked for a large company once where they had little sub-teams. And sometimes sub-teams would kind of push off changes. They would refuse any kind of like, or fight really hard to push off business requirement changes. But they would kind of iterate on their own little corner

or their own little module and just make it kind of super tight, but everyone kind of hated them. And I think it was pretty rare. Don't be that group. I could definitely see to where if you left a developer alone to just say, Hey, go,

go work on this. I could totally see where this would happen. Right. Because you're going to be like, Oh man, this is almost 100% perfect until you're going to keep doing that. But I think that's kind of what I was thinking about. Like, you know, this is almost 100% perfect until you're going to keep doing that. But I think that's kind of what I was thinking about. Like, you know, this again,

this feels like an easy trap to get into when you start thinking about like the non-functionals. Yes. Like if you start, if you start, yeah, you have it, it's perfectly functional, but you keep like trying to clean it up and refactoring it and you're, it's all non-functional kind of thing that you're thinking about. You could get into gold plating or which has ever happened in work has there ever been a situation in a

professional environment where you got all sorts of time to spend all the time you wanted to spend on non-functionals and so like your logging framework is great you know you've got your 12 factor app like everything is like brilliant and amazing and well you know we'll get to the features later we're gonna just keep working on infrastructure like man like they're gonna get a new manager in there and he is gonna kick your butt i'm not thinking about like maybe the app as a whole but like maybe classes within an app or like packages that are delivered separately that you know the overall app might use but like that's where i'm thinking of the gold plating could come in where you start you like oh just overdoing the cleanup on something yeah maybe more than you should you own this little portion of the app and you're like this

is going to be perfect and it is it is beautiful it really is okay so i'm imagining like there's like a you know team meeting right and know, everyone's talking about their problems. They're going through the scrum. And then one team member gets up and they're like, okay, here's our documentation. We can't decide aerial or Helvetica for the docs. What do you think? Well, it's always aerial. There's no question.

I feel like any place I've ever worked, they'd be run out of town on a rail, right? Like everybody's standing there with red bloodshot eyes because they've been working on feature eggs for God knows how long. This dude's like, you know, totally, man. I don't know which font. I can't decide if I like this more if it's five pixels to the left or if it's just three. Yeah. I mean, like I said as i think that this definitely could happen right like if somebody was just given all the time in the world to where you

know they got to work on their little pet project i can totally see this happening the problem is projects i know i totally feel like i'm guilty of this on the on the micro level that i totally yeah i, I think you could, but that's got, yes, I think you could. I, I don't know that I could, I get too bored with a problem, but I think it's a certain, it's a certain type of person. But the problem is like, I think you could, but you'd never be allowed to because you make yourself too important to the team on, on big features, right? Like in places where you work. And I think that's the thing, right? Like if you ever get to the point where this is what you can do, then you might be a little bit worried maybe because

I mean, I have like specific examples in mind where it's like, I just kept refactoring. So I was like, Oh, I should write a test that can handle this situation oh but look that's not exposed i need to clean this up i need to refactor this so i can test that oh let me write five more tests to go after that oh you know what else i could test and then like i started i started falling into this like test rabbit hole so like in the end i feel like it does make the thing in this particular example that i'm thinking of, you know, maybe more robust and solid and, and tested. But from the functionality point of view,

I mean, I passed that a long time ago and everything else I was doing was just gold plating onto what was already functional. Like it already got the job done and I just kept gold plating it. Outlaw, the only person who has ever gotten greater than 100% test coverage. Come on, you guys know you've done this. I'm not the only one here.

I do. Do you really? Well, so side projects like there's a million side projects I've started and I would not gold plate the whole project. Never, but like one little feature. Yes. You know where I'm like, okay, I'm working on say i'm making a website and for some reason even though you know 100 of my users only ever see the front end web page i'm spending 90 of my time in admin right you know where there just isn't as much value is a thing of beauty right and i've worked with project managers too

that would have their kind of like their own things that they just thought were really important and the customer just didn't really care. But for some reason, they kept coming back and talking to you about autocomplete or something else that just really wasn't that important. But I guess that's kind of an example of gold plating. But I just kind of thought of it as almost being the whole project. And I thought about maybe Blizzard video games. They kind of have a long history of like delaying releases by years multiple years in

order to kind of keep polishing and keep polishing but then i mean there's there's always still bug fixes you know years later so yeah there's a difference between polish and just adding unnecessary things right that's i can't i can't i can't help but think that like as he brought up the blizzard example i'm like oh i guess activision is really guilty of gold plating call of duty all these years yeah no kidding man that was interesting oh i can't hate on call of duty though man i haven't played it in two years um all right so the next one i have i this one was kind of interesting too i didn't get stuck with any that were just completely odd, I don't guess.

So this is called the inner platform effect. And I thought it was weird initially. A system so customizable as to become a poor replica of the software development platform. So really what they're saying is typically like software will end up growing into this big thing that already the underlying platform does. So, uh, they were, they called out something like FileZilla, right? The, the Mozilla FTP client that was created at one point to be, to be an FTP client. And, you know,

really what they ended up doing was duplicating what the OS could already do. So like Windows already had FTP built in. Now, granted, you probably did it in some ways better, or more efficiently or whatever. But that was what they're talking about. And it a lot of times, in this case, it wouldn't be as efficient. And so here was an example. And I thought this was ironic, because one of our more popular posts on our site has to do with this very topic, which is entity attribute value tables in SQL Server. And it's a big problem for e commerce, because you start, especially when you talk about relational database systems is how do you store all these properties? Do you keep adding, you know, to what you said earlier, do you just keep adding fields to a table? If you have product a, you could just keep adding more,

more items to it. Well, that becomes hard to maintain. So this whole entity attribute value thing is you have an entity ID, you have an attribute, and then you have a value. So like maybe the color and then the values pink, right? And then you have another one like weight and three pounds. And instead of it being a real table, it's just a bunch of these attributes listed out in row format. And the problem with this is it takes away from the strength of the database. Now to query that and get any kind of real view of the product, you're going to have to do some pivoting or some unioning or whatever.

And it doesn't make a lot of sense. And the only way to really use it is to have an application sitting on top of it. So this was an example of they're trying to redo something differently than what the underlying system already does well for you. So now granted, typically when you're doing an EAV, the reason you're doing it is to address the problem of an admin or other things. It's a different portion of it, but it goes counter to what the underlying system is supposed to be doing for you. Another one that was pretty interesting was overly generic schemas in like XML or JSON. So instead of having a person with a first name and a last name, you might just have object name value, you know, and you try and reuse this thing.

And there might be a type on it called person, but it's the same type thing. You're just trying to make everything overly generic so you can work with it all. But in the end, it becomes incredibly cumbersome to work with because you made it too generic, right? Like you took away the meaning from it to make it something that you could basically loop in your application. So really, that's what they're talking about here. Now, they also do point out there are cases where they've done these things properly and you know it's done properly when the system becomes portable. So in the instance of Java, right, like you have this cross-platform inner system that runs on the OS, but you can put it on Windows, you can put it on Mac, you can put it on Linux, whatever. I would argue now that even.NET Core is one of those same type features where they made this inner system that's now portable. And Docker, to a certain

degree, they're getting to the point to where they can do that stuff cross platform. So it's interesting. It can be a negative. If you're recreating something that the OS already does better for you, then, then it's arguable that maybe you shouldn't even gone down that path in the first place. Yeah. I think about how many applications I built that were basically just uh you know dropbox and excel and by the time you get around to like letting them create their own custom tables like definitely in salesforce too like you can create your own objects and if you build an interface allow them to do that then at some level you are kind of recreating this you know simple

tool is already available and doing a worse job of it i can't believe you didn't mention this example they had here though this is my favorite one where we've all seen these before where it's like windows 3.1 or windows 95 that somebody recreated in html and javascript and css right so you have the entire you know this whole desktop within your browser which is running on your desktop in your browser yeah so it's like you know inception yeah it's it's an interesting one and it makes sense right like that's i don't know the whole the whole thing's odd i don't know that i've ever fully duplicated it but we we've all created things. Like you said, your own, your own Dropbox type thing, right? Like you've created this file upload thing that you can go download from and all that. And,

you know, inevitably we've all probably done a little bit of this. Hmm. I'm trying to think I'm sure I have I just can't think like these giant examples keep coming to mind though and I'm like I definitely haven't written a browser desktop so maybe browser yeah maybe not giant ones but like like he said the the dropbox thing we've all written applications to where you had an upload button and it would upload a file and then somewhere else you'd have some sort of component that would show you a list of the files that you have access to. And then you'd be like, Oh,

well only certain people need to be able to see this. And then you start writing like permission level type stuff on top of it. And it's like, wait a second, the OS already does this garbage. Right. And so it's definitely interesting. Like we've done it in smaller forms,

but we've all probably done it to a certain degree. I know a lot of times when I try to write games, I'll end up starting to write a board game. And two hours into it, I'm like, okay, I'm writing a board game engine that will be reusable across all the games going forward for the rest of my life. And four hours into that,

I realize I'm totally just putting a really crappy interface on top of whatever engine i've already got i'm like why am i why am i doing this you're gold blading it yeah and then i stopped the other day then i need to make it scale to a thousand concurrent players yeah oh no that's that's my job not a thousand men all the's my job. Not a thousand men. All the players. Oh, yeah.

I forgot. A billion. A billion. All right. So let's get into the next one, which is input kludge. So this is simple user input that is not handled. So we've all been there, and we all do our best. We try to properly verify and sanitize our user input and we write tests for

it. But inevitably, as soon as it goes out for testing, someone comes back and they're like, Oh yeah, no, it doesn't work. If I,

if I type this in, it blows up. Or if I enter this in, it blows up. Or, you know, out in the field, you know, some random user enters something. You're like, no, it doesn't work. If I type this in, it blows up. Or if I enter this in, it blows up. Or out in the field, some random user enters something, you're like, oh, why didn't I think of that? So it's difficult for us as the developer to write unit tests to cover these scenarios, but yet somehow it's easy for the users, or at least we perceive it's easy for them because they come back so quickly with like, oh yeah, no, it doesn't work. If I do this,

it totally blows up. But wait a second. How is this an anti-pattern? I feel like this is like not an anti-pattern. This is just the way of things. Yeah. Like seriously, I need a definition as to why this is an anti-pattern, because I feel like this is the way of the world. I mean, why are you arguing with me? This is one of them, Alan.

Just accept it. Does nobody else look at this and go, that's not an anti-pattern. That's just what it is. In fairness, it's also listed as a software bug, which I definitely agree is where it's more heavy on. But yeah, I don't know why the anti-pattern, it's there, man. Why are you hating?

I've seen the Wikipedia, it mentions failing to specify and implement. So you've got to, ideally, I guess we would specify what we accept and what we don't and then stick to it man i still don't like that that's how you like whoever wrote this has never worked with importing spreadsheets because you will find the wackiest stuff it's like how did you get a null column like how did you get a null at the end of a string how did you get a new line there somehow like why is there a column off in space that no one's you know why does that have a space in it

now that's like over on like column you know a 52 or whatever these are real by the way oh yeah yeah well i mean one of the examples that they give here is that which i kind of felt like okay i wonder if this is like the canonical reference for this thing, right? Which was like the buffer overflow is a common example of this anti-pattern that Alan doesn't agree with. It's a software bug. It's a problem is what it is. It's not an anti-pattern. It's a problem. Well, but, okay.

So bugs are a good pattern or an anti-pattern? They're not a pattern. Those are bugs i'm just making the case for input kludge being an anti-pattern if you are creating a pattern of bugs then then that's just another problem right but that's not a pattern or there shouldn't be a pattern what's definitely not a good pattern like i don like this is different. This is just software nightmares. So is a big ball of mud. No, but that's an anti-pattern.

There is no pattern. This is just... This is a bad pattern. It's weird, right? And the reason I guess why I'm like, how is this an anti-pattern? This is very platform or or ui specific right if your ui tools don't give you the ability html is a perfect example of where this is just stupid you have all these input fields and there's no built-in way in html to validate anything right there's nothing on a field that

says this can only be a big integer right there's nothing that you can put on there yeah you can totally tack on javascript frameworks or you can even do some other things around it but you have all these fields but you can't validate them and i and i feel like that's why this this seems like just this isn't fair like i don't know i feel like it's wrong all right i think i think alan has become a php developer overnight and he's just upset about all the sequel injection that he's getting hit with in his forms uh so they listed some ways to test this thing which i found kind of humorous so the first one they said was just mashing on the keyboard just but then they were like well that lacks reproducibility but it was one of the ways that they mentioned here which and this is the part

where it was kind of humorous to me because these all felt like it was the same thing being said over but another one that they listed was monkey testing uh which you know again you're you might think well what is monkey testing well imagine if you handed the keyboard to a monkey monkeys just gonna bang on the keyboard well how's that different than mashing on a keyboard and then the monkeys have nothing on the because the the users i'm used to dealing with like Like a monkey, you'd have to do some funky stuff to get some new lines hidden up in a username field in such a way that you can't tell by looking at the spreadsheet. Like that involves some creative resizing of the cells

to hide that crap. Well, the monkey, in all fairness, wasn't able to copy and paste from an Excel sheet into that, right? That's the big problem is your users are like, I got this spreadsheet over here, copy paste, right? I've got this webpage, copy paste. Yeah, and this is where the last one that they mentioned was fuzz testing, which is kind of like the monkey testing,

except, you know, if we, because there's a, the difference with monkey, with fuzz testing is you're talking about like providing invalid or unexpected input, but then there's this other one where it's like random data, which is what the whole mash on the keyboard and the monkey testing is all about, just randomness, right? And so in that regard, that's why I'm kind of like throwing Fuzz testing into the same category with the other two. You know what? I just had a good idea for a piece of software.

What if you just literally had something that could randomly generate input, like known bad inputs, things that cause headaches all over the place. Look, you're both searching to see if it exists, aren't you? I thought you were coming up with PHP. But no, like if you had like some sort of API that people could call that like just gave them crap in to see if it broke their stuff, like that that would be I think it would get used.

So yeah, burp suite and it is the one that I kind of messed around with a little bit. That's just a free one and that's just one of the options like you like you can like configure it to go to web pages and stuff like it's got all sorts of tools for like navigating like web pages and web apps and stuff and you can actually like just kind of check the fuzz and you can even set the parameters and regexes all sorts of stuff on it and it will literally try to plug in every drop like if you have a drop down you can configure it so it doesn't just select some item it just passes whatever rate of crap in that drop down and a lot of times like code will say like um you know you'll have a combo box or a drop down whatever and it'll have the value and it may not necessarily be a number and you can put single injection stuff kind of in there and people don't really think about it because you're you know not really passing you're expecting that number all the time because that's what you

set out but it doesn't mean that that's what you're getting back from the client so fuzzers like that are like really popular in security tools yeah i was gonna say burp suite is actually an injection tool right like a Like a penetration tool, yeah? Yep. And then I think we've talked about this too, but like Firebase as an example, if you're doing Android development, in Firebase there's the UI application exerciser monkey where it just bangs on your app. Just random inputs, random clicks, random touches, whatever.

Throughout your app. So there's definitely some tools out there. We should totally list that. Wait, did they get it? Burp Suite is $350 a year if you buy it. I think it's a free version though. Yeah, so Firebase is Google? I didn't realize that.

Oh, man. My battery died on my mouse. What's that about? Here we go. All right, cool. I'm going to put Firebase in the notes here because I think that's useful. Unacceptable. Oh, okay.

Go ahead. Well, here. I've already got a link here. I put it. It's there. It's done. Dang it. Yeah, man.

Too fast. All right, Joe. All right. So, first of all, input. Can I get some eyes? Say I if you think input kludge is a anti-pattern or if it's just a problem. It's a kludge. I.

I what? It's a problem or what? Anti-pattern. Well, he said the word I, so it doesn't matter. What does that mean? He agreed to it being an anti-pattern. What do you want? It's a. I just want to know if you guys actually thought it being an anti-pattern. What do you want?

I just want to know if you guys actually thought that was an anti-pattern or if that was just a thing. I think it's a thing, man. What do you think? Come on. You know that's not an anti-pattern. I don't even understand. Come on, man. You know it's just a thing.

It's just a thing. Are you talking to me? Yeah. No, it's totally an anti-pattern because i just talked about it i'm gonna have a chat with wikipedia about this one that's right uh see here uh the next one i got is a interface bloat making an interface so powerful that is extremely difficult to implement and this is similar to the god object that we mentioned earlier, which is like an object you kind of keep tacking stuff on

until it gets bigger and bigger and bigger. There's some carry over there, but this is more specific about making like a pluggable interface that's got so much stuff in it that is basically related to different types of tasks that it's really difficult

and specific and unusable. So you've got a reusable interface for component that's not very reusable. And an example here would be like, if you've got a widget, like you've got a website, you've got some dashboards, and you've got a widget control. And so you say, I've got a widget class, and you can inherit it. And you can make a graph, or you can make a text area, or you can make, you know, like a little export widget, something like that. But as you kind of go along, you know, you start with having a render because everything needs to be displayed. And you have a save in case anybody configures it. And you've

got to restore to get, you know, anything that you've saved back. And then, you know, you add an export. But the way you do that is by adding like an export method that now everything that shares this interface has to implement, and maybe it just returns null or does nothing. export but the way you do that is by adding like an export method that now everything that shares this interface has to implement and maybe it just returns null or does nothing but then it's got uh you know a flip to the right or rotate horizontal and you keep kind of tacking on these abilities now to this common interface that it becomes kind of meaningless and so now widget is just totally generic kind of bag of semi-related functionality. And now a new person comes along and says,

okay, hey, I want to add a new widget. And they click, you know, extend or implement whatever. And they get this list of stuff that now needs to be implemented. And half of it doesn't apply to what they want to do. Like they want to add a pie chart. And they're like, what's export mean here? What does save mean? I know what render means,

because that's all I cared about. But now I've got to implement all this other stuff or I have to like, you know, maybe just have empty methods that do nothing and hope that nobody calls them and that they don't really matter. And so I think it's just a prime violation of the interface segregation principle,

which is the idea of kind of having small interfaces that are targeted for the things that you actually care about. And one kind of example that I remember dealing with is, I tried to implement I list once and C sharp, I had this bright idea of like, I don't know, having something that could be like a list, but like, well, you know, for some reason, I wasn't just using a list for like, I wanted to be able to mimic it, but also do other stuff. And there are tons of methods. I think there's like two dozen or so methods in I list and things like is read only count to add, remove, you know, index of, and knowing me, all I really wanted out of it was like I enumerable, which gives you like count and a way to iterate through it. And,

and maybe add because add is like the one thing I think that's in the list interface that isn't in innumerable. And if you just look at I'm not saying this is bad design, you know, I'm sure it's like that for a reason. But when you go to implement something like that, if you want to make something that's compatible with the the list interface and C sharp, you're going to be implementing a lot of methods. And as far as kind of telling if you're kind of going down this trap, I think if it's like once you get to the point where you're implementing something, so it's either an interface or you're inheriting something and kind of filling in like virtual methods or overrides, and you find yourself doing like little comments like this doesn't matter here or throwing not implemented exceptions or um just defaulting to

like you know basically null object behavior then that's kind of a sign that your interface is doing too much and that you should consider kind of paring that down. So I'm trying to think if I'm ever guilty of this and I'm kind of wondering, so you gave your example about the implementing the I list and I thought like, oh yeah, that's probably like really hilarious if you were to implement your iList and then in your class you're using an iList you're just like masking the functionality over top of it and then I was like oh wait I think I've done something like that if you ever created like a sort of interface that like um like say you've got like an iProduct interface and it's got all sorts of stuff and you keep finding yourself adding abilities to this common interface for things that are specific to certain types of products like let's say you know your amazon and now you've added methods for like um like what's the example like cut in half or reduce

inventory like you know if you i'm sure you've seen systems where like you've got digital products in a database that has inventory what do you you set the inventory to? Zero or one? You know, 99? Negative one? It's just an example where you've got an interface that's more powerful and it's kind of got properties or methods that are just nonsensical

or difficult to implement for specific instances. So I had a thought along these lines and, and I'm wondering, so you tried to implement I list and I'm just trying to think through this problem from the outside, right? So I believe I list is made up of a bunch of other types of interfaces, right?

So it is going to implement I enumerable, probably some other ones. So I guess here's, here's my question with this, right? So you go down this path, maybe you just implemented the wrong interface, right? So I guess the heart of the situation here is, can you have a wrapper interface, like let's call it I list, is that wrong to do implementing a bunch of other interfaces to get a list of everything that you want to be enforced there? So I think it's, it's raising an interesting question, because you can totally do that. You can create an interface that implements

a bunch of other interfaces. You say, Hey, I want this to utilize I dictionary. I want it to use a lot, utilize I enumerable. I want it to utilize whatever else. Is that wrong? I don't know if it is. It's not. And then in, I mean, it's okay if you're building up on things. So iList specifically uses iCollection and iEnumerable. So in your example, you're taking smaller pieces to create a bigger one, which that might be fine. But in the example that Joe's talking about, you just end up with like, you just keep tacking onto one thing and you're never making an I-savable or an I-exportable. Right. You're just like, oh, well, I-widget must

have all these things. Right. And I totally agree with that if you're building it yourself. But I'm just saying from the example that you set out with with doing I-list, I think maybe you just went to too high a level when you were trying to implement, right? Because it's actually made up of two other ones. So it was just a, it was something I wanted to mention because in this case, if you looked at iList and you tried to implement, you'd be like, wait, I don't need all this stuff. Right. But under the covers, it's not doing all this stuff on its own. It's inheriting that or implementing that from other interfaces so they kind of did it right you know what i mean like yeah with third parties you

can't tack an interface on so i couldn't create an interface that only had the methods i cared about and then you know told whatever method the third party method i'm dealing with that only takes the i list i couldn't say hey i, I know you only really need these two. So I made a new interface called I add and remove. And that's what you should take instead, you know, it just doesn't work like that. Like I've got to like succumb to their interface, I can't change it. And I can't even change any sort of, you know, types to apply my own kind of patterns to it. Like I you have to play by the rules. And in this case, you know, I list, there's a dozen different ways to do it. Like just use a list or maybe inherit from it.

But I think just, you know, passing a list is a much better way to go. So I don't know why I even tried that. I just thought it was kind of interesting to see just how much stuff there was that had to be implemented for something that I only use so little of. Well, I mean, this is the example that I was thinking of was not I list, but I dictionary. Yeah. Where if you ever tried to implement I dictionary, there's, there's a ton of methods on that one. And I've definitely had times

where this is, this is where, you know, my, my guilty confession here as it relates to this, where like, I wanted my object to look and act like a dictionary to the rest of the world. Uh, and so that's why I implemented iDictionary, but I wasn't, um, I wasn't recreating the wheel of how an iDictionary would work or anything like that. I just wanted mine to, to be used like a dictionary. And I'm trying to think if I even use a dictionary internally for any of the parts I might have or list as well but so that's where you could get yourself into weird situations where it's like oh well I don't want to support this particular you know operation I don't know if I did that but well one example would be like I've got some a some third party method that takes an I dictionary of, you know,

string and string. And I've want to make that dynamic. So I inherit or I inherit from I dictionary or implement the I dictionary interface. And I create methods actually run out to a database. And whenever you give me a key, and I return the value from database, so it's like a dynamic dictionary, you know, it's new. And whatever I'm passing, you know, whatever third party code is probably just using those indexers, right? It's probably just, you know, using the same two methods that we always use for dictionary. But now because you're doing that, you've got to implement all this other stuff, like get hash code and whatever weirdo stuff that they're not even probably using. And it's because they're taking a bigger interface, they're not applying that

interface segregation principle, they're taking something bigger than they need. And so it leaves you kind of stumbling around trying to like, implement the stuff that doesn't really make sense for your use case. So I do want to come back just a little bit, because probably if you're not familiar with interfaces, and exactly how they work, firstly, I recommend going back to episode one, because we talked about it, which has been a while back now, but I kind of want to tie this up a little bit. So we said that we started with this eye widget and it started with a render call and then a save and then a restore and an export.

And we kept adding stuff to it, right? The way that you would fix this problem is instead of having an eye widget with all those, you'd have an eye widget with a render call and maybe a couple others. And then if at some point you said that you wanted save, instead of tacking that onto I widget as another method, you would probably create an I savable widget or something like that, right? And then that thing would have a save method. And then if at some point you said,

hey, well, we need a restorable thing, then you might create an I restorable widget. And then if at some point you said, Hey, well, we need a restorable thing, then you might create an I restorable widget. And then that way, any widget that you're creating could implement all those interfaces. So if you think about it like this, I have my new PI widget, right? It'd be PI widget colon. And then, you know, I widget comma, I savable widget comma, I restorable widget comma, etc. So I just wanted to at least wrap that up so that you know the anti-pattern is you're tacking too much stuff into this one interface. And the way that you fix that anti-pattern is you create new, as you said, segregated interfaces so that now you just implement the ones that you actually need. And so you're keeping all your code extremely light and just focused.

Well, another way to say this too is that, and I don't know that we've ever gotten into this topic, maybe at a surface level, but if you try to be diligent about preferring composition over inheritance, then you could be setting yourself up to be in a good spot to already be creating the I savable and the I restorable and the I exportable, uh, new interfaces, right? Because then when you want to add that new functionality, you're just going to add that composition into whatever new object you're wanting, right? Versus if you're just adding

it, tacking it on to some base interface and then expecting that everything else is going to like down the line picks it up that uses it is going to like now have to um you know be responsible for implementing it right and especially like that could be especially troubling too if you think about it from the point of view, if you're like a package creator and you have some like core interface and instead of taking the composition route and creating this new, uh, interface that could be added onto other objects, you instead decide, okay, I'm going to take this core interface and I'm going to like add new methods to it that everybody's going to have to implement you might not have access to all the source that's using your package so that you could even update those sources right

so like you could be creating compilation errors for users of your package when they like pull down the latest version so yeah interesting that makes a lot sense. So you're talking about like public API or public type classes. People are using your stuff that you don't have control over anymore. Mm-hmm. And it doesn't have to be public necessarily. It's like outside of your company or outside of your project. It could just be like, hey, I've got this NuGet package here that I've created or whatever this package is, and it's going to be used in these other places,

and I might have other people within the company that are also using that thing, too. Yep. I might not have access to their code. So what we're saying is lots of little interfaces are good. Mwa ha ha ha we've gone full circle

back to episode one. Yep. It's funny. I actually interfaces that do nothing. I had a discussion with somebody today and it's frustrating because there's polarizing views on this stuff we've talked about it before and it drives me crazy if you're doing oh by the book let's call it you're going to have a lot of classes you're going to have a lot of files right if you're doing OO, the not so much OO way, you probably won't have as many, right? Like by that, what I mean is this whole notion of separating your, your interfaces properly, you could end up with five files instead of one, right? If you are doing abstractions properly to

where you have a, you know, a concrete class as they call them, and you're trying to set it up to where you can do testing properly, you're also going to have an interface for that. So that's two files, right? Instead of the one. And in any time I hear somebody argue about, well, you're going to have a bunch of files. I'm like, that's what your ID is for. Right. If, if that's the complaint, then that's a bad complaint. In my opinion, like I do agree that you don't want to get too complex with things, but on the flip side, you know, do it in a way to where your abstractions are meaningful and the number of files shouldn't dictate, at least in my opinion should not dictate your direction for how you code these things i'm curious your opinion

my id has great tools for dealing with files i've got tabs i've got you know right click go to definition i've got a little navigator window to the right where i can scroll up and down and see the files or to the left if i'm working say what or to the left or to the left no i never mess with the defaults what no i'm thinking like he's thinking web storm or something like that visual studio there you go anyway continue uh but i don't have great tools for dealing with big files i've got ctrl f and like the mouse scroll you know that's it so if i need to go from line you know wherever i am now to you know like 10 inches up the tools just suck for that so that's actually a really good point never really thought about it like that but it is definitely a pet peeve of mine like i see a lot of people that you know developers that i that i truly admire but for them they find it i don't know

i guess easier to reason about or whatever where if they'll create like maybe a bunch of small classes small interfaces and they just leave it all in the one file and it bugs me like yeah i can't stand that i'm like no no that that's got to be separate i don't care how small it is for all the reasons that joe just listed i totally agree yep uh it's so much easier for me to deal with in that way but uh yeah yeah i mean there's something to be said for being able to read like top to down so you enter a function and you keep reading, reading, reading, reading until you get there. But who has time to read a 10,000 line function? I don't do that.

I want to zip in into that kind of the areas and I want to use those hopefully good abstractions to help me get there quickly. Yeah, I definitely agree. So anyway, I guess I'm going to get off my little soapbox there, but don't ever let the number of files be anything that dictates why you create something in a proper way. Like that, that argument kind of just sends me a little crazy. Um, all right with that, it's this time for us to first, thank you everybody who has seriously taken the time to remember after listening to us in the car on your long commute,

whatever for, you know, literally when you get where you're going to take the time, get on your computer and write us a little review. It's, it means more than, than, you know, we don't ask for a whole lot. We try to give as much back as we possibly can. And this is the way that if you do want to give back to us, like we appreciate it more than you could possibly know. So if you do remember this, please do head to codingblocks.net slash review. And I think even slash reviews works if you want to pluralize it and, you know, go up there and click on a link and either, you know, leave us one in iTunes or Stitcher.

It is, it is more than, you know, appreciated and we read all of them. Uh, we get emails as well and we appreciate those and thank you for your time and thank you for listening. And, you know, please do if you do, if you'd like to share this with some other people and, you know, make your life easier by helping somebody else code a little bit better for you. So that's, uh, that's all I got. And with that, we head into my favorite portion of the show. Survey says, man, we need to get that ding sound from the show so that we can play it right here. last episode we asked... Okay, I had to word this one.

Okay, so you have four near identical job applicants come in for a job, and they only differ by how they learned to code. Which one do you hire? Your choices are first developer was a six-week boot camper. Developer number two, this does sound like a dating game. Developer number two, a bachelor's degree from a state university. Behind door number three. Yeah. Developer number three, likes to take long walks. Developer number three. Yeah. Developer number three. Likes to take long walks. Developer number three, one year, similar job experience.

And lastly, developer number four is a frequent committer to prestigious open source projects. I don't know why it has to be prestigious, but it is. Popular. Popular. That's what we should have. But we said prestigious. It's too late now. Well,

I've heard about people copying and pasting other people's GitHub projects throwing up on their own page and putting on the resume. Oh, that's a great idea. So like,

I know you should do that. You should do that. I wrote Kafka. I'm going to get a clone of Joe's app. What? You didn't know? That's awesome. All right. So it's my turn to go first, right?

Sure, why not? And I really have no idea on this one. I'm trying to think of what the listeners would say, somebody who was in a hiring position. My guess is they're going to go with the standard bachelor's degree. Bachelor's degree and bachelor's and i'm going to say we're going to put that at 37 we went a roundabout way i think we went through several numbers to get there we might have so 37 bachelor's degree. Yep. All right, Joe.

I was we got one. We got one really good comment about this and I was hoping actually to get a lot more comments because I really want to know where these lines are because I know this is intentionally kind of a tough question, right? Right. And the numbers even hard like you know, if it was two years similar job

experiences that change things significantly, you know, I'm interested in what these lines of distinction are. I said, I'd still like to hear it. Joe looking for a job in HR. Let's talk about our feelings. I'm going to say one year, a similar job experience with 51%. Wow, that's're going all in. Go big or go home.

Yeah, apparently. All right. Go home. So Joe picks 51% one-year job experience. Alan, 37% bachelor's degree. And you're both wrong. No. It was a commanding 67% frequent committer to prestigious open source projects. Really?

That is commanding. All right. Yeah. Wow. That was the one that mattered. So for all the guys listening that have written us over the years and was like, hey, what should I do to get my first job? I think you have the answer now. And Joe gave you a great tip on how to boost up your github

get download copy all the code to a new one get clone joe zach get push michael outlaw that's interesting i mean i that's kind of exciting to me, honestly, that people actually care that much about it. I mean, it does, I will say this, it does show a lot of different skills in one little thing, right? If you know how to, first off, clone the project, you know how to branch it, you know how to change the code, you know how to put it up, put in a pull request, get it approved, like that's a lot of little tiny skills that somebody learns.

Yeah, working with others. That's a lot of little things that you did to get your one or two or 200 lines of code in, right? It's not a small thing. So I like that. I like it that we were wrong, honestly. Yeah, I imagine like I'm trying, like, a prestigious project like Firefox. So you get a resume and it says, like, this person's a frequent committer to Firefox

and you can go and you can even see the communications and the, you know, like the mailing list stuff and that happens in the forums for the development for that and how they decide on making features and cutting tickets and getting things approved.

And yeah, I mean, I think that would be pretty huge. That's excellent. Hey, what was number two, just out of curiosity? I mean, I think that would be pretty huge. That's excellent. Hey, what was number two, just out of curiosity? I mean, you still lost. No, dude, 60-some-odd percent just shocks me anyways. No, Joe had it.

Did he really? Yeah. The one year? I was torn on that one. The only reason I said bachelors was I was thinking some people value the fact that somebody put up the time to finish it, right? Like, because let's be honest, it's kind of a drag trying to get through all of it. And it shows a level of commitment.

And that was the only reason I went with that. Yeah, it was sad. Significant. Yeah, it was really 22%. So bachelors was like 10 or less. Less. Yes. Wow. Wow, that's killer That's exciting man

That really is to me How'd bootcamps do? That was dead last Actually I saw a lot of negative chatter On Slack about it A lot of people just didn't have Great feelings or experiences with, with bootcamp graduates.

And as not, that's not to demean anybody who ever got it done. That's nothing. It was some opinions being thrown around that, you know, I was just kind of watching, but it's important to know how, like how other people kind of view that.

And so if the only thing you've got coming into a job interview is a six week bootcamp, camp then you know it's worth knowing that people value open source contributions and so if you can buck up a little bit on some of those yeah then you're in a better position agreed so for our next survey with all the excitement and hype coming out around the iphone 8 we ask is this the iphone we've always wanted or is it just evolutionary and not revolutionary or is it time to switch to Android? Those are the tough questions we ask. Evolutionary, not revolutionary like the MacBook Pro. Time to switch. Please tell me what phone to buy.

Well, you know what, though? You were talking about last time that one of your reasons for wanting to switch was because they got rid of the headphone jack on it. But there's already a couple of the Android phones that don't have it. I think it was like Motorola and an HTC that don't have it. The next Pixel is rumored to not have the headphone jack. So I think you're going to have that problem no matter which one you go to. Everybody wants Slimmer. And yeah, whatever.

Hashtag not my phone. Right, exactly. Let's start a thing. All right, so let's get into our latest fun here, which is Google Feud. I'm ready. Got a new tab locked and loaded. No, no, you're cheating. No, no, no.

Oh, I can't do it, can I? Yeah, you're just... i can't do it can i yeah you're just i can't type it now all of your previous answers are suspect i've never won one they can't be all right all right so this is this is gonna be an well not easy one i. Why do programmers Google asked a hundred users suddenly appear every time show me suddenly appear

how about make so much money show me why do programmers make so much money? Show me. Why do programmers make so much money? Dang it. Oh, wow. Why do programmers? I have no clue, man.

Stink? Smell bad? Are they hygienically challenged? Geez, Alan. We don not sure we don't we don't and you work at home so what does that say i'm sitting in the same room with you i don't smell anything so we're good uh no okay so here are the top five from my results why do programmers hate windows why Why do programmers use max? Why do programmers use Linux? Why do programmers use abstraction? And lastly, why do programmers use foo? So it's interesting. Mine's mostly the same list, except I don't have the windows thing,

but I do have hate PHP is my last one. Hmm. Huh my last one well when i when i typed in to just see um i inadvertently stumbled on something i didn't expect which is that there's a language called trump script and it's uh not for dummies or losers makes coding great again. Oh, I've heard of this. No floating point numbers, only integers. America never does anything halfway. Oh, man. All numbers must be greater than one million. No import statements allowed.

Oh, my gosh. Oh, man. I do remember this now. Oh, man. I do remember this now. That's amazing. All right, we got another Google feud. Okay, we got one more. One more. And this one is, why are programmers... Stubborn. stubborn show me

stubborn dang it uh Joe um why are programmers so lazy? We asked a hundred people. Google asked a hundred people and the survey says,

why are programmers so lazy? My first answer would have worked. Number one, why are programmers paid so much? Number two, why are programmers so weird number three why are programmers fat hey and number four and five why are programmers arrogant or so arrogant isn't that sad that it's two of the top ones wow Wow. Yeah. Be aware. Be self-aware. Be self-aware. Yeah, if you just are just getting into the profession,

you're going to be paid well, but people are going to think you're weird, fat, and arrogant. Welcome to the club. But what if you're just that good, though? Right. Yeah. Here we go.

You don't have to like it it's the way it is this episode is sponsored by linode linode has 10 data centers around the world with plans starting at five dollars a month for one gigabyte of ram and 20 gigabytes of solid state drive storage and you can go all the way up to 200 gigabytes of RAM and 16 CPU cores for your heavy computing needs. And all this can be done in under a minute. Linode uses hourly building with a monthly cap on plans and add-on services, ensuring you'll never get in over your head. You have full control of your VMs, and so go ahead and add Docker, encrypted disks, VPNs, and more. To get a promotional credit of $20 towards your Linode hosting fees, go to www.codingblocks.net slash Linode

and enter code CodingBlock17 to get started today. It's like your first four months are on us. All right, so let's get this train back on the tracks. All right, so I did have a weird one, and I remember it now. It's the magic push button. So they describe this as a form with no dynamic validation or input assistance, such as dropdowns. All right. So basically what they were getting at in this entire thing was you have this user interface and you have business logic and the two are basically completely disconnected. The only way one gets used, the only time the business logic gets enforced or run

is when you push the button on the form. And so what they're saying is everything in the UI has to be complete before you push the button, and then the business logic can run. And then after that, then it'll come back and do things. So this is where it started making sense is what they're talking about is you ever filled out a huge form on a page and there's just so much garbage. And there's like 10 drop downs. Each of them have 100 items in them. You get to the end of the page and you hit save and then it kind of blows up and it's like, hey, this isn't valid.

And you're like, what? What do you mean it's not valid? I spent 20 minutes filling out this form. So what they're talking about is this magic push button is in a good type of UI, if you choose something in dropdown one, like let's say Ford, right? Ford is the car manufacturer. Okay, well, then probably Impala shouldn't show up in there. A GS 350 shouldn't show up in that car dropdown. It should limit it to what Ford cars are, right? You should

see a Taurus. You should see a Crown Vic. You should see whatever else, right? And so what they're talking about- You picked out some real winners there for Ford too. Mustang. How about that? An F-150, the most popular selling vehicle in the United States. Yeah, I think you got it with the Crown Vic. No, the F-150's it. And the Taurus. Yeah, there we go. Well, the SHO is not a slosh. Anyways, all right, so with that, though, you could see where that would be incredibly frustrating.

And we've all used interfaces like this where you choose something, and it should have driven other options on the form, and it doesn't. And so that's what they're talking about right here with this anti-pattern is there's zero feedback until you push that button. And then by that time there's the feedback is almost useless, right? Cause it's like, well, this isn't an invalid option. Well, how are you as a user supposed to know that only 10 out of these 150 cars in this dropdown are legit based off what you chose in the other one. So that I totally agree. That's a bad user interface. That is an anti pattern. You should somehow hook this thing up to where it can lead your users down a path, right? Yeah, I don't really think this is like a programming thing. This is kind of like a interfacey kind of you know user input like who likes users yeah i mean if you're gonna pick on my input kludge is this an anti-pattern or is this just an awful ui experience it's both so the the input kludge

seems like i i guess the reason why i had a hard time with that one is that's not a pattern that's literally just you have a bunch of fields that have no way to validate properly, right? They validate. They're just, you missed cases, but this is literally a decision to where you're trying to separate your UI logic and your business.

And you're being, you're being like fanatic about it, right? Like only when you click this button, are we going to enforce the business logic because we want to keep the UI completely separated from the business. And that's why I think it's, that's why I can see this as being an anti-pattern because it's, it's almost like a, a strict decision that was made to make sure that we keep these things as, as, you know,

uncoupled as possible or decoupled as possible. That's the only reason why this one sort of makes sense to me as an anti-pattern is because it's not because they couldn't have done things in the UI to make it better. They just wanted to keep this nice clean layer. This is your job and this is your job. So I think it's a pattern, a bad one.

We should have played pattern or thing for all of these guys, I suppose. So what's your vote on this one? Pattern or thing? Thing. Thing. You? Yeah, I think you're a thing. Yeah.

I could follow on both sides of this one. I could see where it's a pattern, but I'd probably lean more towards thing. All right. I just want where it's a pattern, but I'd probably lean more towards thing. All right. Let's talk about software engineering pattern. Well, if you didn't think that input kludge was a

anti-pattern and you're on the fence about the magic push button, let's talk about race hazard, also known as race condition. Okay. So this is the behavior of a system where the output is dependent on a sequence or timing from uncontrollable events. All right.

And it can often happen when processors or threads depend on some shared state. Now, you've probably been there, and if you haven't, you will eventually get there to a race condition problem where these can be difficult to reproduce. Don't look like that. Yeah, this is a thing. Sorry. No, no, no, no, no. You can't.

You're already prejudging. These can be difficult to reproduce, though, since the result is non-deterministic, and it often depends on the relative timing between threads. Yep. I think this one is an anti-pattern because I think a lot of race conditions can be eliminated by doing things the right way, like using promises or registering callbacks or doing those sorts of things. But a lot of times we get away with stuff until it becomes a problem

and we do things kind of in a bad way that relies on assumptions that we're making about the way things work that aren't necessarily true. Which is why it's an anti-pattern. Because even Wikipedia says, necessarily true which is why it's an anti-pattern because even wikipedia says it is therefore better to avoid race conditions by careful software design rather than attempting to fix them afterwards and because while you are trying to fix them afterwards these production problems can often disappear when running in debug mode or additional logging is adding situations like that, which is known as the Heisen bug, which is a bug that disappears or seems to disappear or alter its behavior when one attempts to study it. If adding an alert fixes your bug, then it's probably a race condition

come on get on board get on board i could see where you could fix it with a pattern but i don't see it as an anti-pattern well then if it could be well you're relying on you're relying on behaviors that that isn't true that's kind of been abstracted from you but i mean isn't that the point of abstractions like is like ideally you don't have to think about that stuff you just kind of say like hey get my thing and use it but that's not always you know available at the time and you've made some assumptions about that okay okay that could lure me into the pattern the anti pattern okay okay that was a good argument all right it's no longer a thing all right like uh one kind of um you know like we mentioned like

promises and callbacks but another kind of thing is queuing right like if you like try to make a behavior like like you try to click a link in a navigation or try to do something before it's available, you can also queue it and say, when the application is ready for it, go ahead and run through these actions that the user tried to do or maybe just take the last one or something. I feel like there are good tools for this, but a lot of times they involve

pretty nasty architectural changes. And so sometimes it's just easy to defer and literally run something later which is a nasty solution to the problem but uh it's very effective nasty the first are nasty that was amazing uh so the last one I got here are stovepipe systems

and this is something we've kind of talked about I guess all these there's a lot of overlap but a stovepipe system is a barely maintainable assemblage of ill-related components and stovepipes the reason they call it that or another word for it that I've heard more commonly

is silos is there are systems where features work up and down The reason they call it that, or another word for it that I've heard more commonly is silos, is there are systems where features work up and down. Like every feature is almost like a copy-paste tweak of another feature. And so every time you add some new checkbox or some new section to a website or an application, you almost treat it kind of like it's almost standalone, where it's a part of the system. But it's not reusing common components that other things do. And so you'll find this a lot in times with the comic base, like I mentioned, but it's because we're not there's not proper abstractions, and things aren't sliced up into modules or layers in such a way that I can reuse behaviors.

And so the easiest thing to do then is just cut off a vertical slice that looks sort of like what I want to do. And I just make another one. And, you know, I've got this weird kind of conglomeration of like, you know, silos or stovepipes. And the problem there is that we're reinventing a lot of wheels, especially if we're doing like

a lot of ad hoc database calls, you know, it's example of somewhere that we're doing things when we need them and very specific, you know, it's example of somewhere that we're doing things when we need them, and very specific to our needs, which is kind of nice, right? Because that means that those queries are very specific to what I want to do. And I'm not doing things inefficiently. Or I'm not jumping through hoops that don't matter for me. So there are some benefits. But ultimately, there's some pretty big downsides i think anytime for all these patterns anytime you start copying and pasting and tweaking as like them the your main go-to like here you know you're into uh anti-pattern land that's what i do all the time you know the funny part about

that is what you just said and this happens a lot of times when there's teams working on different sections of code but the tweaking is almost the most dangerous part, right? Because there's this pattern, let's say, that people are familiar with. And then somebody copies and pastes it because they have this new section they need to work in. And they've learned some things since the last code was written. And they're like, oh, well, I can make this a little bit better, right? And so now you don't just have a copy and paste. Now you have this copy and paste and it's slightly different so

it's not working exactly the way the other one did now and so now you end up doing this because then somebody's going to copy and paste maybe that original source and do it slightly differently different in another place and now you've got all these just slight derivations of the same type of code. And it's, it's unfortunate and it happens a lot. I think I've got a real world example for this. Maybe I think, I think this one counts, excuse me. Um,

so way back when with stitcher, if you created your login, there was a certain set of credit criteria that it had for what it expected for the, um, the password, like what, what was acceptable and what wasn't in terms of character length and character class, whatever. If you then went over and like, after you created your credentials, go to the ios app and then try to enter in those same credentials then the um rules for the password were different there so even though one system accepted it and all the validation could have happened in one central

place for like what's considered acceptable for the password. The other application had reinvented what the criteria, what the acceptable criteria was for the password. And even though it was the correct password, it wouldn't accept it. That's frustrating when that happens. That happens in a lot of apps. I think that counts as what you're talking about here,

right? Oh yeah, absolutely. Another example is like if you've got multiple drop downs where you can like say select a user right to perform some sort of action and then somewhere along the line someone comes along and says, you know what? We've got soft bleeds here only show active users

you have to remember or know or search for every place that you've done an ad hoc query to get those users in order to only allow the ones that are active and all it takes is one of those places to allow inactive ones and now you've got this kind of weirdo record that is maybe not showing up and so you go edit a record and there's a blank spot and a drop down that's required you know why is that there um and i so i think that anytime you've got to remember to to do something in more than one spot then you're probably uh you're looking a little stove

pipey and you know the worst thing is this is not an easy problem to fix right like it really isn't because in order to fix this whole you know these silos or these stove pipes, you really got to have some people take a look at the entire app as a whole and say, what's common here, right? What can we, what can we reasonably turn into reusable chunks of, of objects that can be shared or components or whatever? And that's not necessarily necessarily easy stuff i was thinking of all of the ones we've talked about though this would be among one of the easier ones i would i would think because i i interpret this one as uh you get to delete a bunch of code hopefully right you know you're like oh hey i see that this is you reinvented uh how we do password uh verification over here and we have password

verification over here and this is the real business requirement rule so i'm going to delete your method and all calls are just going to use this other one right like that kind of thing yeah so we say this one's the most fun to correct yes it's kind of rewarding too right because when you do it right you can drop them in it might be a little frustrating while you're getting there but the delete key is my favorite key yeah yeah it's it's one of those things it's one of the reasons why i like software development is because you can see things happen right like like when you look at that and you just chop the code base by 25 and it's working and it's working better and more testable and more effective and more

consistent, you feel good about it. Right? Like, yeah, you walk away from it. Like I accomplished something great today. Right? Like I, I not only is this working better, but now a bunch of other developers are going to come in here and benefit from this. And I, I've always enjoyed that whole molding and building aspect of this stuff. So yeah, there are some stuff. So, yeah. There are some benefits, though.

Like, one thing is dependency hell. You can imagine, like, one feature of your site needs an updated version of, like, a JSON library. And so you update it, and it breaks another section of your website that's using a different feature differently. And by having these things in silos, you're insulated from that sort of thing. So you can make changes in one area and not in another which kind of sounds like a good thing but you know it's a double-edged sword because you don't want to have the same library different versions used throughout your application that's just asking for trouble as as lines start kind of getting crossed but it is kind of interesting to have um those kind of vertical up and down

you know feature wise um that flexibility it's like you said to have those kind of vertical up and down, you know, feature wise, that flexibility. It's like you said, they're almost insulated, right? Yep. And you can also make a sweeping vertical changes pretty easily. So if you need to change,

you know, that user dropdown, like you could do whatever you want and it's not really going to affect anything because, you know, it's, it's its own little, own little slice.

All right. Well, you know it's it's its own little own little slice all right well that's going to wrap that up so in our resources we like section we will have a link to the wikipedia article that uh we we pulled some of these anti-patterns from. And you will be happy to know, Alan, that my boy Singleton is not on there. Man, just Google Singleton anti-pattern. No, no, no. Stop hating. 133,000 results on Google. Just saying. It's a pattern.

It's in the book. It's a design pattern. It's your boy. I'm not going to pick on him, but he's out there with anti-pattern written all over him. No.

He just gets picked on a lot. He does. All right. Well, with that, let's get into Alan's favorite portion of the show. It's the tip of the week. I think it might be my second favorite. I really like Google Feud a lot. Google Feud has caught up, huh?

It has. It's up there. And it looks like I'm first this time. And I found something kind of interesting here. And I've yet to try this out. So hopefully it still works. But the tagline is setting a Skype status from the command line. And I've got a little gist here.

And it's bashed. But I've also got a little C-sharp project here. And I imagine there's some other way to do it here. So we'll have some links. But it's like the idea of like setting your command line either dynamically. I mean, sorry, setting your status dynamically or just kind of having some fun with it. So you could do something like, I don't know, if you're a little program that sees how long you've been on a branch. And if you've been on a branch for more than one day, your status could be i'm still working on this freaking branch or uh you know even having uh just the branch that you're in and your your main kind of repository

being a part of your status message is kind of interesting that anyone could like look at your name and skype and just see what you're working on without having to ping you so i just thought it was kind of cool and you could even have like um you know bring in your calendar whatever so now it's showing when you're at lunch or, you know, doctor's appointment or stuff like that. So it's kind of cool. And if you just, you know, take it one, one little malicious step in another direction, you could also have, you know, stuff like it's signing on for you at certain times or auto responding.

That's cool. That's a nice fun one. Mine is only because I don't think we've talked about it before and it's come up and joe i think you've had some real nice experience with this so a lot of times what you'll see if if people have a list of things that they need to push into a stored proc and sql server a lot of times what you'll see is they'll just create this long string that's some sort of character delimited whether it's pipe or comma or something and then they'll parse that out in s that's some sort of character delimited, whether it's pipe or comma or something. And then they'll parse that out in SQL using something like a split function

and turn it into rows, right? So that can work. Performance may not be great, but that's one. But then typically, if you need related data being pushed into a stored proc, right? Like, so maybe you have a user id and then along with that you need to pass in i don't know his name or something right but you have a whole list of them like in a table the way that i've seen it done in the past is you might pass in two extremely long strings that are you know pipe delimited or something and you try and match them up when you get into the proc so there's a a better way to do that, at least with SQL Server. And this might actually be implemented for other RDBMSs using ADO.NET and C Sharp. But you can do what's called passing in

a table valued parameter for SQL Server. And the only downside to this is you have to create, as far as I know, and correct me if I'm wrong, but I think you have to create a user defined table type in SQL Server. So let's say that it was like, you know, user ID, first name, last name, you'd have to set up that special table definition so that SQL Server could be aware of that type. But then you could literally pass an entire data table into SQL server and it could use it just like it was a table valued variable in SQL server. So it's way faster than string parsing and you get the benefit of having related records really in a true table format when you get in there. Yeah.

I feel like we should talk about this common to limited list as an anti-pattern. You want to go over that one real quick? It should totally like a lot of the patterns. Or is it a thing? Well, it might be a thing. I don't know. It depends on the server.

Like, I don't know if like my SQL supports things like this. Cause I don't know that they on the server like I don't know if like my sql supports things like this because I don't know that they necessarily support like uh you know uh user defined type tables or whatnot but I really should probably look into that but anyways I have a link on here for this and if you're using sql server and you find yourself passing in crazy strings you should probably look into this because performance and safety and et cetera, et cetera,

you'll find this to be useful. Yeah. It's shockingly slow or so shockingly surprising to me. I, how slow SQL is it dealing with lists? Like you would think it'd be not a big deal, but I've had so much better experiences with UDTs and just like every other anti-pattern that we kind of talked about,

I should say that I do that one in particular. I've done many, many times and I've done all these patterns a lot. Like we tend to talk about best practices, but I always want to make sure to point out that like I absolutely do all the things I'm advising you not to do. I can't talk to you anymore. Oh, no. Stay out of my God object. That's right. That's right. That's right.

All right. So for my tip of the week, this is for the Mac users. So every time it's time to do your software updates, typically just wait for the little app store thing to chime in and say, hey, you got an update, right? And then you watch it. And then there's that time where it chime in and say, Hey, you got an update, right? And then you, you watch it. And then, and then there's that time where it's like, Oh, well you gotta like download this and reboot. And so then it kind of goes into this like quasi shutdown mode,

gray screen, you watch it download for 30 minutes and then, well, not anymore, but you watch it download for 30 seconds and then, uh, it installs for another, you know, 10 minutes and then reboots and all as well. Right. So nine to five Mac posted this, uh, conversation that are summary of a conversation that happened on Reddit where, uh where the conversation was about using the terminal to do this all from the command line with just the software update command. And in typical Reddit fashion, it exploded into this amazing, everyone trying to one-up it because it started out as, oh, hey, you could do a software update dash L just to see if there's some updates. And then if, hey, you could do a software update dash L just to see if there's some updates. And then if there are, you could do a software update dash I dash A to install them.

And people were like, nah, we got to consolidate these commands, right? So I'll include a link to it. You can see the whole evolution of the commands. But yes, basically the point is you could do all your software updates by the final command, which was, I'm going to say it out loud, but then know that you'll be able to read this article. sudo sh space, or well, let me rephrase that. sudo space sh space minus c, and then in double quotes software update dash IA and reboot. So basically the idea is that you can execute in a whole new shell,

sudo shell, these two commands that are chained together so that if the first one actually has an update and succeeds, then it will reboot. And that is Reddit for the win. Now you can do your software updates from the command line. That's beautiful i gotta say right i can't take you seriously when you pronounce it like that what sudo seriously i'm sudo i'm sudo you sudo yeah sudo sudo all right but i think it

is actually supposed to be sudo right but i always say sudo yeah super user do yeah super user do but it's pseudo yeah okay okay fine i've been shamed is it jiff or good um cheesy hackers choose jiff this is never gonna it's never gonna end uh so today we talked about software design anti-patterns uh we talked about our favorites which ones were things which ones we hated the most and which ones we uh do the most often which ones are things yes yep yeah and so with that be sure to subscribe to us on itunes to learn more using your favorite podcast app uh be sure to leave us a review by visiting www.codingblocks.net slash review. While you're

there, check out our show notes, examples, discussions, and more. Send your feedback questions and rants to the Slack channel, codingblocks.slack.com. And make sure to follow us on Twitter at CodingBlocks. You're heading over to codingblocks.net and you'll find all sorts of social links and

things like YouTube stuff. Need more diet, Dr. Pepper? Tastes like the real Dr. Pepper.