Coding Blocks - Designing Data-Intensive Applications – Maintainability

Episode Date: December 23, 2019

We dig into what it takes to make a maintainable application as we continue to learn from Designing Data-Intensive Applications, as Allen is a big fan of baby Yoda, Michael's index isn't corrupt, and Joe has some latency issues.

You're listening to Coding Blocks, episode 122. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And codingblocks.net can be typed into your browser where you can find show notes, examples, discussion, and more on the website that it will take you to. Are you sure? I'm tired. I'm sorry.

You sound uncertain. Too many video games. 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 are at the top of the page. And with that, I'm Alan Underwood. I'm Joe Zaks, Beard of Christmas. Pew pew.

I'm Michael Outlaw. This episode is sponsored by educative.io level up your coding skills quickly and efficiently whether you're just starting preparing for an interview or just looking to grow your skill set and about you one of the fastest growing e-commerce companies headquartered in hamburg Germany, that is growing fast and looking for motivated team members like you. Hey there. Today, we're talking about data-intensive applications again, based on the book by a

very similar name, Designing Data-Intensive Applications. And today, we're talking about the third part of how we're going to be kind of qualifying, discussing, kind of scoring applications and methodologies, which is maintainability. The last two episodes were about scalability and reliability, and today is all about maintainability, which is a subject we love very much. Cool. Hey, you did very well with that, seeing as how we had the wrong information in the show notes. So that was nicely done. Yeah, I'm used to getting things wrong and recovering nicely done all right and so we got some stitches here and i'm

getting things right on the fly let's see how this goes uh yeah so let's start with this and sister reviews huge thank you you know we love those reviews so thank you very much for a grab crack crack ladderricio Page, the other, other Jay-Z, which I'm going to have to read this review right now. And hey, what's up, Luke Gergen? Hey, wait. That's the programmatical praggrammer is what he was trying to say. Oh, man. That was really good.

Programtical. It's not was really good. Programtical. It's not programmatical. Programtical. You're right. Programtical pragammerer. Every time I look at it, it's a little different. You notice something new about it every time because I miss the er-er. That's so good.

Oh, by the way, did anybody else read the other Jay-Z? Like, fat dude from Austin Powers? The other Jay-Z. Oh, no. All right. So I got iTunes here, and mine are not quite so hard. So we have CodeStar and Crouching Probe Hidden Canon. Now, we met him at Atlanta Code Camp.

I don't know if you read the review. I did. Of course I did. It was so cool. And I went back, and I couldn't find the image that we posted where he'd won the iPod, the AirPods, and all that kind of stuff. Because I know we had done it somewhere, but I couldn't find it. So at any rate. Wait, no.

Did we post it? No, I thought he took the picture and posted it. Maybe he did. Maybe that's why I couldn't find it it because I was looking in our tweet stream. Well, now you're making me think I've got to go back and look through my photos to see if I have the photo. Yeah, we've got to find it. So, at any rate, yeah, huge thanks to everybody who left us reviews. I mean, there were some really, really good ones in here.

And Luke Gerrigan, super appreciated the one that you threw up there, too. So, yeah, thank you all. And so with that, we have a little bit of news today. And this one is actually near and dear to my heart right now because we've just gone through some pains with this. So I know one of you two know the episode number of I Still Don't Understand Open Source Licensing. Three. Three? Was it really?

It couldn't have been that far back. I was thinking four, but, yeah, it's something like that. No, actually it wasn't either. Or seven. Three was back. I was thinking four, but yeah, it's something like that. Wow. Actually it was neither. Or seven. Three was gift. Uh, get four was a wasp. So seven.

All right. So episode seven is, I don't know. It's been a few years back at any rate. So we talked about the fact that you as a developer really need to be aware of at least the good licenses out there that you can sort of just be like, oh, cool, I can use this. The ones that you probably shouldn't touch at all unless you know what you're getting into. And then there's this one for Stack Overflow that we just found out about recently. And, man, this really stinks because I love Stack Overflow.

I would venture to say you guys. Yeah. I mean, is there another site that we visit more than that during our daily programming? I will never admit to it. Right? Not on the air. So here's the thing, man. This is the part that really bugs me is we were told recently that you can't just use code from there.

Right? And it basically boils down to they use a license and I'll have three links here for us in the show notes. I'll have one directly to their site, which talks about their licensing to which there they then link to the Creative Commons license, which is called the Attribution Sharealike 4.0 International. So CC BY share alike 4.0 international. So CC BY dash SA 4.0. Now here's the thing. The reason this matters is because it's one of those licenses that has gray

areas. So they have this thing in their, in their license. The share alike portion of it is if you remix transform or build upon the material you must distribute your contributions under the same license as the original so that means two things one if you use it and you build anything using that, maybe this is the great, you have to attribute it. You have to not just attribute, you have to share your code and you have to change your license to this same license. And that is the problem. So unless you're potentially willing, like, here's the thing.

This is one of those ones that's not very clear on what build upon the material means, right? That can mean, hey, your code is using that code, so you're buildingflow. So somebody had mentioned that, I guess, like a couple of years ago, Stack Overflow was trying to go through and change everything to MIT, but I guess their community was like, no, I want the attribution and all that kind of stuff. And so it never happened. I wasn't aware of that, but apparently it happened. But one way or the other, we'll have a link to this license. We'll also have a link to the TRD, the TLDR legal site that we've brought up in the past as well. And it's also not hyper clear on some of it. I mean, the point of that site is to be a little bit more brief.

Well, easier to read, right? Like put it in language that we all speak instead of legalese yeah so i mean their their summary of it is that this particular license uh allows you to do what they want with your work as long as they wait the days are messing me up let me start creative commons attribution share alike license in international version four that allows you allows to do what they want with your work as long as they share the work under the same license which means you'd have to re-license your code as the same share alike thing so not even the license it's the sharing it's the share and that's so again this you might not want to share your code right and that's the deal if you're writing – so again, this – You might not want to share your code. Right.

And that's the deal. If you're writing commercial software, chances are you don't want this in there, right? And this is – man, this is where things go crazy and it's frustrating because here's the deal. If it ever went to legal, then there is gray area. And they can fight and say, hey, what is part of this? What did you build upon? What didn't you? And it's really going to depend on how much time and how much money you spend fighting in the legal system to make this happen. So this is where –

You don't want to argue with your legal department. That's their job, and they're going to put you down. It's not often that a lawyer is going to be able to out-code you, and it's not often you're going to be able to out-argue a lawyer. So I generally try to advise just avoiding that. So what I like to say about when it comes to the Stack Overclock after reading up on it, which is still I still can't, I have a hard time believing it, but what I say is

if you do use the code, you should follow the rules, you should do the attribution and you should make your license match the code that you borrow, or you should just not use it. Wink. Can you hear that? okay well here's the problem with the wink thing is there are tools out there that will scan you could actually take your entire code base and you could submit it to these tools and they will scan every single code every single line of code that you have

and then compare it to not just Stack Overflow, but that's going to be one of their major things, right? But blogs on the internet or other sites on the internet. And so you could actually get a list back of, hey, this code looks like that code and you're not using the right attribution or this code's using that code and you really shouldn't unless you want to copy left open source your application, right? So it's, it's,

it's a dangerous road. And again, this pains me because I hate that because I love the spirit of what stack overflow is, which is basically developers helping developers. But that license kicker that comes along with it is, is rough. So be aware.

We used to call those snitches back when I grew up. Even the TLDR, though, for it is still kind of confusing, too, because that quick summary, it's like, well, you have to share the work under the same license, but then when they give you what you can and can't do with it and what you must do with it, their must doesn't talk about like you must, you know, share your code. It just says you have to give credit and include the copyright and state changes. Right.

You know, but okay, what if you don't make changes to it, right? Like if you just used it straight up. Yeah, that's why I was saying the tldr on this one isn't really all that helpful because there should be a bullet point here somewhere that says that you have to share and distribute anything that you actually they say distribute original and modified derivative works derivative works and. And that's, that's where things get gray, right? Like how much of it was derived versus what,

how do you describe derived versus use? And I guarantee you an attorney is going to paint it different depending on which side of the fence they're sitting on. Right. So man, I'll tell you this one, this saddened me quite a bit. So that's why my 2019 resolution is to not Google for coding problems anymore.

But I mean, even with like documentation on microsoft.com came back. Right. As the same problem, which was run through a scanning tool. Right. So again, going back to the whole point of,

you know, the wink, wink, whatever the problem is, is there's code that there are tools out there that will scan the code, whether or not you had attribution links or not. And it'll say, Hey, this code looks awfully similar or exact to that code right there. Or it's an 80% match to that code right there. And it'll find it. And it'll be like, Hey, this, you know, it looks like you

borrowed somebody borrowed quote unquote, somebody's work here. Yeah, and blog posts, all that stuff, if it's not explicitly licensed, it defaults to all rights reserved. So you have to be really code with looking. And a lot of times people can even argue about being influenced by code that you've seen, which is awkward. And I know Elastic is going through a big lawsuit right um like someone who made a security plugin because they said they borrowed some pieces of their code and uh it's it's gonna get nasty and you don't want any part of that if you can avoid it don't don't argue with lawyers and the the key part here is is what you just said is whether or not somebody wins that lawsuit or not you're to spend money fighting it in the court regardless, right? So it's like a lose-lose situation is what it boils down to. And Mike and myself were talking about

this this evening is there's some things that there's kind of just one obvious way to do it. And so that's what's really frustrating is when you see something on Stack Overflow that's like, well, yeah, of course that's how you do it. That's like the only way that you really would do it. And so that's, what's really frustrating is when you see something on stack overflow, that's like, well, yeah, of course that's how you do it. That's like the only way that you really would do it. Um, but you gotta be careful about that stuff. And yeah, I mean, it's a, it's a hairy situation. So, oh man, have you ever, uh, there's like a website, uh, oh geez, I forget what it's called, but, um, but it basically contains like all the different, various combinations of English sentences and words. So you can find anything on this website.

And so I'm wondering, could you do something like that with code where you just kind of generate all the different possible permutations of code and then copyright it? Like all rights preserved and you just blast out every possible combination. Like there you go. So you're like a patent troll at that point? Yeah. I claimed it. Dibs. Dibs on all the code I generated.

Man. So, yeah, that's a little bit longer than we typically do in the news section, but I think that's like a public service announcement for everybody out there. I mean, as developers, we know that we do a lot of searches for problems that we're having. Just be careful and be mindful that copying and pasting code from just about any site may come with some major drawbacks. So be aware of what you're doing. By the way, it's libraryofbabble.info, and we'll have a link to it. I just searched for my name, and it's in there several times.

So be afraid. Nice. It just, it just kills me though, that like Microsoft own documentation came up, fell, fell under that. They're like, okay. I mean, if they're showing you an example of like, this is how you use our library and you can't use that, it's like, well, all hope is lost. Right. Forget it.

We're done. They're the ones who created the language. Why can't we? Yeah. Yeah. It's ridiculous. All right. So I guess moving They're the ones who created the language. Why can't we use it? Yeah, it's ridiculous. Alright, so I guess moving on then, I've mentioned a couple times I'm going to be

speaking in NDC London on January 31st at 1140 AM. So if you were there, I'll be talking about streaming real-time data streaming using Kafka, SQL Server, KSQL,

all that kind of stuff, and I will be showing demos, so if you're interested and you'll be in the area, please do. Kick him in the shins. Don't kick me in the shins. I'm not JT. You kick that dude in the shins. I'll kick back. This took a dark turn. You got to get to those voices like you kick one of us uh you kick back kick the other one you get some giggles

all right so also i want to mention we're doing another book giveaway here so make sure to leave a comment and uh someone will win uh we had a bit of a snafu last episode so if you happen to drop a comment uh then uh you got a book last time oh there was a snafu last episode. So if you happen to drop a comment, then you got a book last time. Oh, there was no snafu. Clerical error. No, this is a Merry Christmas, Happy Holidays. This is, hey,

you guys took the time to go up there and comment on the episode. You all win a book. Yeah, we're a little crazy there. A little drunk on eggnog. So congratulations and enjoy. And if you haven't been able to get a hold of you and you'd love to comment before we uh went ahead and did that then you should get in contact with us

because we're trying to get in contact with you yep man we broke the credit card in the process that's right that's right that's right all right well let's do the thing already let's do that all right so we're talking about maintainability today which is the uh the third tent pole there uh in relation or related to scalability and uh whatever the other one was reliability reliability now we're talking about maintainability which is something we've done a few episodes on and so some of this is going to be kind of a retread but it's also just kind of uh from coming from a perspective of specifically towards data-intensive applications. Yeah.

One of the things that is really interesting, and we probably all know this, anybody that's been doing software for more than a couple years, a majority of the cost in software is maintaining it. Not creating it, not designing it, it's keeping it running after it's been built. Which totally makes sense, right? Nope. Because if you're lucky, you build that thing, let's say it takes you three

months to a year or whatever it takes you to build the initial version, right? If you're lucky, you're still using that same thing for years, right? It kind of makes sense because you're going to keep adding features to it, maintaining it. And then the security patch on the main system is going to get done and it's going to break it, and then you're going to have to keep maintaining it.

Somebody's going to realize you used an example from Microsoft's documentation. You've got to rewrite the whole app. That's right. There's that. But you're not bitter about it. That's the flip side to this. Totally. But this is funny because they also say, hey, coincidentally, Oh, but you're not bitter about it. And that's where, that's the flip side to this. Totally. Um, but this is funny because they also say, Hey, coincidentally, people don't like working on legacy software as they call it, or maintaining code that other people wrote.

I don't know. Do you, do you, do you fall in that camp or do you care? It's either either i think it's like one of three things either you hate working in brownfield or or no i guess i'd just be the two things or you don't care or maybe you like it yeah so three no you like it you love it or you're just me joe you uh there's definitely times where i don't like greenfield so i would say that i probably prefer some sort of legacy just there's some kind of boilerplatey kind of stuff that you have to do for every new project like especially on the front end type work that just it gets really tiring to me so it's like okay i'm doing another new grid i have to go figure out what grid i want to use you know like kind of figuring out those patterns and establishing them for a new project is just really tiring to me you've done it a million times Like some reason I always need to do some sort of new kind of work on it because that stuff is always changing every new web project.

So I'm just tired. I don't want to make another login page. I don't want to create another grid page. There's just some patterns that I'm just kind of over. I hear that. Yeah. I think for me, mine really depends on just the state of the code. Like I've worked on some brownfield projects and I'm like, Hey,

these aren't terrible. Like I don't mind. Like it's easy to reason about and you can, you can make modifications. I'm good with that. I've worked on others where it's like, uh, I got to do what? Like, wait a second. How long is this going to take me? So, yeah, I mean, I think it just, it depends to me on the state of the code you i kind of view it as like it's more of like a what kind of a mental state am i in at the time right because to me like brownfield application typically is more like situations where you don't have to put

you don't have to think as hard about it because like if it's just a bug or something for example like the boilerplate stuff that joe was just talking about is already done for you right you're just like okay let me go in oh uh you know i was supposed to divide not multiply right you know whatever it might be yeah uh but you know for the greenfield like what which is kind of where i think joe is going it's like you got to put more thought to it you know and so sometimes you just feel more energized and refreshed and so you're willing to take on that challenge. Then there's other times where you're just like, I just don't feel like putting up with

that kind of crap today. Let me bang out some bug tickets and be done. Somebody give me a ticket. Frameworks have gotten a lot better so it's not so bad, but there's definitely been times I go to start a new project and I know I'm going to have web services. I was like, okay, well now I have to think about security.

Let me go figure out how to hook up logging. It's just stuff that takes some time, especially when you're not Googling to kind of figure out and work through. But you know what? I think part of what you're describing is part of what happens when you become a more experienced programmer is that you now know about all the stuff you have to worry about. And so you get bogged down with it, right? Like when we were in our younger years, it was like, you know, file a new project, boom, we're good. Nowadays you're like, wait, no, we've got to get security in there.

We've got to do this. We've got to do that. And so you're thinking about all that other stuff that you didn't care about. Oh, you need a web call that can allow you to do this? Hold on, wait a minute. I'm going to set up a shell script. So if you go to this special URL, it'll just execute that shell script and then you can

just give it an arbitrary command that it could do. That way you could just execute it remotely from, you know, do whatever you got to do, right? So you have remote admin access to your system. Yeah. Hey, I just wrote a blog post about that. You did. You actually did. I literally did. We should put that in the show notes

as well. Yeah, we'll have a look at the show notes and don't do it. Yeah, don't do it. Oh, man. Because I'm going to sue you if you do it. All rights reserved. There's no license on this post. I'm going to get you. We got a copy left you.

Yeah, so some of the reasons why people dislike working on legacy systems are because you have to deal with bad code sometimes or it's code that you haven't written. Outdated platforms. I know for a lot of people, that's a big one. You don't want to be working in yesterday's technology. And a lot of times, those applications were made to do things that they weren't designed to do in the first place. We've talked about people using databases as the hammer and everything's a nail. There's situations like that. Or if you're still developing in VB6.

Hey, it's apparently one of the most popular programming languages in the world. VB6 or VB.net? VB.net. You got me. Yeah. But that's not true either. Pre.net. Yeah, I don't know about Tyobi.

Yeah, I don't think it's right. It's a little fishy. Well, I mean, you know, it sounds Yeah, I don't think it's right. It's a little fishy. Well, I mean, you know, it sounds legit. It was on the internet. Right. It's like we compile sources from all across the internet, like Yahoo News, IRC, chat rooms.

Well, Bing just copies Google, so that should be legit. Is that what they do? Yeah. They index the indexer? You don't remember that they got caught doing that? No. At some point, yeah. This has been years ago.

Really? Yeah. Passing it on. Yeah. If something got searched for that they didn't have in their index, people were actually proving that they could go to Google and search for that same weird thing. The results would come back and the same exact stuff would come up in Bing. Yeah.

Well, wait. How does just getting the same results prove it though because you're gonna have different indexing on patterns or whatever right so it was stuff that it was obscure things that they were searching for to find out what was happening dude do you remember what was the name oh we're off track that didn't take long do you remember that that there used to be like a game with Google where you could do a search, and if you only got like a single result back, then you won? Do you remember what that was called? Oh, not that you won. I remember it used to take you to a website.

Like you could say, I'm feeling lucky or something. No, no, no, no, no. But I'm talking about like only a single result would come back. Oh, no. I didn't know that was ever a thing. Yeah, it was a thing for a while. And then like forever and a day, like I'd never been able to do it. And then just recently, like last week or something, I was like on a screen share with a coworker.

And I'm like, yeah, hold on. Let's just search for that. And I'm like, oh, my. One result just came back. I win the internet. You've broken the internet. That is a typo no you win you win you have to be more optimistic that's true all right so with this whole thing about these um legacy

systems what they're saying is we should build applications to minimize the pain during the maintenance phase and this involves using the following three design principles and we'll mention them here but we'll go into depth in a second. So you want to take them, Joe? Yeah, so operability. The idea is to make it so it's easy to keep the system running smoothly. And this is where I'm currently taking the most notes, time to learn the most about.

Simplicity, making it easier for developers to pick up and understand what was creative removing complexity from the system or at least writing really long documentation about it in the wiki just kidding that's nobody likes that no uh evolvability making it easy for developers to extend modify and enhance the system that's probably the thing that simplicity and volvability are kind of the things that we've talked about a lot of times over the years. And I think it's this kind of operability angle that's kind of the new perspective I kind of gained from reading the book because definitely keeping things running is just critical.

If you are dealing with a web application or something that needs to be up 24-7, then that gets to be really important real fast. Yeah, evolvability sounds a lot like the open-close principle. Yeah. Oh, yeah, for sure. Like how easy it is to make changes. And that's the kind of stuff I struggle with the most.

But that's like the constant struggle, right? It really is. I just – DevOps has kind of changed things a lot, like Kubernetes, Docker, CI integration. Every open source project now has like Travis CI or CircleCI and tests and automated deployments and just everything. And all that stuff is all really good and awesome. We all – we're deploying like 100 times a day or whatever. But that only works when you've got good operability and that's kind of been the new slant

that things have been taking and teams have been accomplishing amazing things specifically because of that one new focus yep yeah I mean I kind of interpreted that too as the ability to like like you mentioned Kubernetes I heard that mentioned but even like a lot of the cloud

type services now where like if something does crash it can like automatically respawn or it can automatically scale right you know uh you know the elasticity of it can scale as needed and you know that's what i think of when i think of that operability uh uh you know punch line or ticket there whatever you want to call that bullet point um yeah yeah I think we're at an inflection point for that because we're at a point now where when something crashes and it comes back up I'm like yay oh go thank goodness that was awesome I'm glad that happened

but if something crashes and it doesn't come up I'm annoyed like that should have come back up what the heck so we're kind of at this like this point of changing where kind of our expectations as developers and our expectations as customers is kind of changing from what is expected. You remember back in the day, like 10 years ago, if a site was down, you go to Reddit or something, it was down. You're like, oh, well, I guess I'll just check back tomorrow.

Right. And now it's like, no, refresh, refresh, refresh, refresh. There it is. Well, the tooling has come a long ways, right? And that definitely helps. Do you remember that old video, the website is down? Have we talked about this? No.

No. Oh, my gosh. I'm going to have to put a link to that in. How do you not remember that? Is that when you would call the phone number at the bottom? You'd be like, hey, there's a problem with the website. I can't get it to load. The person would be like, oh, this darn thing. No, this is like an old video that maybe from like the 90s or something but

you know the early 2000s and the the sales guy calls in to to tech support and the uh oh yeah the the you know the admin or the tech support guy he's like playing halo and then yeah he's like oh yeah hold on then he's like, oh yeah, hold on. Let me reboot it. I'll have a link to it. But yeah, it's hilarious. I kind of swore we talked about it before. We might have. We've had a few episodes. One of the good quotes that they had in here that I loved

on this operability is, good operations can overcome bad software, but great software cannot overcome bad operations. And that is so true. If you don't have people and processes in place to make your software run smoothly, it doesn't matter how good your software is, it's still going to suffer. Yeah. If your code's slow, well, fine, here's eight of them. Right. But if you can't get it deployed, you know,

it has to be built on a Bertha's laptop or whatever, and then, and deployed manually or shipped out, whatever, then that's a huge problem. And ultimately it's going to drag you down. Absolutely. We even like the processes to do that,

those deployments, right? Like if, you know, if right? Like if it's automated, then it's really simple to like get to redo it or to get another one, right? But if you have to go through a bunch of hoops and it's like, oh, it takes like, you know, a month to finish configuring the whole thing, like forget it. The more difficult something is, the more it's going to be your precious, right? You know, like you're going to hold that thing dear the more difficult it was to obtain. Yeah, I wish that that wasn't the case. I wish that more people would treat things like that.

Like, hey, man, if I can get that off my plate, then we can do more cool things. Right. But a lot of times I think what you're saying is true. A lot of people hold onto that stuff. Like I have this special knowledge. Oh, I didn't even mean it that way. No, no, no. I just meant like, I meant it from the point of view of like, if it took you, you know, a few months to build, to install and configure and build a server and a system, right. You're going to,

you're going to be inclined to like, you know, guard that thing. Right. Versus if you had something scripted out to that, it can just re deploy an environment. Then you can be like, Oh,

you want to tear it down? Yeah. No worries. Let's just do it. Run it. Right. You're not going to, that one Oh, you want to tear it down? Yeah, no worries. Let's just do it. Run it. You're not going to, that one that took you two months to build. Oh no,

you're not going to want to format that box. You're going to like, every time there's a patch to install, you're going to, you're going to think twice about installing. Is it worth it? Is that? Yeah.

Because you had to go through pain to set that up. Right. That's what I was referring to, but you're referring to like holding on to like tribal knowledge. Yeah. Yeah. Because there are people that do that. And I truly don't understand it.

It's a lot harder to set this up after the VAC too. I have a real bad habit of like kind of being, I call it scrappy or I justify it as being scrappy. Where I'm like, oh, let me just prototype it. Let me just get it going. Let me make sure this is valuable. I'm just doing MVP. And then I'll, you know, make it official and get it legit and building and deploying later and it's so much harder to do it later and every time i do it i always wish i'd done it sooner

but you know what though i think that's the right approach i get it because you you probably took shortcuts to get to the mvp that oh yeah that you wouldn't have? He says it like the Kool-Aid man. Real good ones. Oh, yeah. Some real good shortcuts. I know some good shortcuts. But, I mean, the problem is, though, is until you prove some things out, then you could be spending time on things that don't mean anything.

I mean, dude, you and I both spend a lot of time on certificates and mapping things up through SAS settings and whatever else, and you would have never spent that time up front if you hadn't thought it was a valuable thing, right? Because that's true. You would have given up because it takes so long to get that stuff right that it's like, whatever. And it's just miserable.

It is miserable. It's not fun work. It's like the least fun thing I can think about. Yeah. But so like this operability thing, they say operation teams are vital, vital for making software run properly, which absolutely is the case. Right.

And it shouldn't be developers doing it. Um, and the responsibilities include several things here. So monitoring and restoring services, if the system goes into a bad state, right. Uh, right. That only works if you have things hooked in to be able to monitor

that stuff, right? Like, I don't know that we've talked about it on this podcast a lot, but I would say that that's probably one of the things that a lot of developers overlook when they're developing applications is how do I ship information out of this thing so that it can be monitored in its running state? You know what I mean? So you mean like heartbeats or are we talking about logging anything, anything like something that can output to something else that can monitor it? Right. Um, that's almost always an afterthought. Like when something goes completely sideways on you at, know 6 a.m one morning and you're like oh yeah i probably need to have something in here to make sure it's still

alive uh have i mentioned that i love spring now have we gotten there yet i know i've uh i've crapped on it a bunch of times but uh just thinking about just kind of the java world some things are kind of standard like we were talking about monitoring and restoring. You know, maybe when I was doing more.NET-y or, you know, just like C Sharp or Ruby or ColdFusion or other stuff I've worked in. I always kind of did monitoring and restoring just kind of more manually. But with like Java and Spring has such a rich tradition of doing exactly this with things like they've got the like JMX kind of protocols and standards for doing exactly this with things like um they've got the like jmx um kind of protocols and standards for doing just this and so it's so common for java applications to just support this stuff and you know it's paying the button you have to it's got a learning curve it's so nice

to be able to think about this stuff after the fact and be able to pop it in there pretty easily right just turn it on basically because it's there it's built into the framework more or less yeah i'm sure that dot net's got some stuff for that i just i don't know like i like if i had a Right, just turn it on basically because it's built into the framework more or less. Yeah, I'm sure that.NET's got some stuff for that. I just don't know. If I had a C-sharp app and I wanted to easily report CPU and just also custom metrics about it, I guess I would have to do some Googling. Maybe there's some easy ways to do that. But I know instantly how to do that in the Java world and just you know, just kind of configure that stuff and set that up.

And then on the other side, I know how to hook it into like tools like Grafana or whatever. But when that, that would also depend though on like what your ultimate outcome was. Like if you wanted it, if the destination was cloud watch, for example, you know, maybe in the case of spring, you know, they might already have some kind of integration available to patch into that. I don't know. But, you know, I'm thinking have some kind of integration available to patch into that. I don't know. But, you know, I'm thinking in front of like a.NET world, you know, you're going to have

to like know that that's a destination that you're going to want and either, you know, you know, write some kind of abstraction around it. Hopefully you don't write directly to it, you know, but you know what I'm saying? Like so that you could have, okay, this is an event that should be logged every now and then, go send this thing to this destination. Yeah, I think what Joe's saying, though, is in the Java world, they have a protocol for it, right? And I'm not aware of one in the C Sharp world. I'm sure there is something for it, but it is interesting

when you think about some things like that. Yeah, you can kind of configure stuff after facts you can say like hey i care about knowing how many of these beans there are you know like like how many of these things like you can kind of um get that logic outside your application it's just got really nice hooks for kind of where to plug in and configure that stuff and it's a pain in the butt i mean you're probably gonna be writing xml or kind of annotating stuff or it's not fun for sure, but it's just cool that it's got this like 10 years of stuff that you can Google about it. And it's been pretty much the same for all that time, which is pretty nice. It is funny because that's sort of the polarizing problem for us has always been between Java and

.NET is Java. What you're saying is the inverse of what we typically complain about in the Java world. Java, there's like 20 different ways to skin a cat, right? And that's always been the frustration is you want to go start a new Java app? Well, what are you going to use? Good luck. You're going to spend a week trying to figure out which one you want to settle on. .NET, there's no choice.

You just file a new project and you're kind of done. You have a few choices along the way, but you're going. But in Java, they do have a lot of well-established things like what you're talking about with the JMX and even things like aspects, right? Like they're sort of first class citizens and things like Spring, whereas in the dot net world, you have to go find something like PoSharp or some other add-in that you're going to be paying for to do that. So it's kind of interesting, but at least along this line of the monitoring and storing, that is something that you really need to think about. Like, what does it mean to monitor your thing? What could go wrong that you need to know and be alerted on if something goes wrong? All right.

The nice thing about hooking into a standard is that other tools understand that standard. And so they know how to do things like set up notifications and monitoring around that without you having to go and custom build that side of things too. You can just kind of plug in. I was like, oh, I can see where maybe there's already an integration for Java and the CloudWatch API that you don't have to do much of anything on your end. It's weird. The closest thing I can think of at C Sharp would be loggers. And then having different syncs. I was thinking of performance profilers. Yeah, that's more close to what JMX is.

Yeah, so it's weird yeah i don't i don't know there are performance profilers but you know you would typically use them like while you're still in development right in debug mode or something you know phase of of it not after you've published well i mean i want you deployed it then windows has its own profiling yeah we need to research this i think it's something that we should know about. Yeah, let us know in the comments and you might win a book. So continuing on with the responsibilities of the operations team, and obviously this is going to be a limp. We're going to say every responsibility ever and we're not going to miss anything.

But tracking down the problems was the next one they had there yeah that's a skill that that people will have to have i mean hey us as developers have had problems tracking down problems yeah i was i was gonna say like isn't this one just pretty much everybody yeah like if you have a job tracking down the problems i dig ditches guess what you have to do you have to track down the problem oh we hit a hit a pipe. There's a rock. Right. Well, I guess we'll dig around it.

Uh, uh, yeah, I'm going to, you gotta get good at estimating that too. Ha ha. Good luck. Yeah.

No estimate. That doesn't work. All right. So, uh, the next one they have is keeping system updated and patched, which again goes back to what I, what I was describing before.

If you know, you're going to be reluctant to install updates and patches if it was a pain to build in the first place, right? Oh, yeah. If the reproducibility of that system is difficult, then you're going to be very hesitant to install something. I guess what I'm trying to say is you're not going to be an early adopter of every Microsoft Patch Tuesday. Right.

You might wait a patch, which is bad. I mean, think about this. You're talking about a production system. We all three, I think all three of us got hit with this. I know you and I did. There was an update that hit our systems recently that busted Chrome. Yeah, me too. Yeah, it hit all of us.

And you spend hours trying to figure out what the issue is and then get it running. And that's on a developer machine, right? That's what people that are pretty good at figuring this stuff out, just imagine you have something like that hit your production environment. I don't know if you've heard our point before, but we track down problems. Oh, no, that's why we had the problem, because we're not the ops team. We're the dev team. But yeah, I mean, imagine that.

You've got something that is mission critical for your company running out there, and now you have patches coming in once a month that are pretty major patches to your systems. And that's why we switched to Internet Explorer. For a minute, anyway. IE 8 will live on. Just keeping inventory of what you've got in your organization can be really tough, just in your application, but also

just local dev machines and all that stuff when you're talking about vulnerabilities. That's a big problem. Yeah, it's not easy. Alright, so next is keeping track of how systems impact each other. That one's interesting. Yeah, that's like a whole can of worms.

Oh, my God. I mean, you talk about dependencies in code. Just even trying to track that's difficult. But now you start talking about interdependencies between systems. I mean, think about all the stuff that happens between systems. You have networks. You have routes, router switches um subnets all kinds of somebody can flip one number on a subnet and jack up your entire infrastructure right so that might

have happened a time or two yep yeah there's dependencies too uh between them where these two things talk together but uh this one doesn't support this type of interface or it doesn't support TLS3 or you have to wait until this one supports the other one. It's just a pain in the butt, especially if you're dealing with a lot of services and then another library for interacting with that service. There's going to be some lag time between that service updating and then that third party.

Well, again, keep in mind, this is from the ops team, right? So it could be a matter of, hey, we have our database system and we have a primary database and a backup database. But our backup database is not the same level of hardware and software as the primary because we only need it for emergency purposes. And we need to install patches. I don't know if you heard about the keeping updated and patched, but we need to install patches on that primary, which means we need to fail everybody over to the secondary. And now we need to understand the ramifications of that

because now everybody's performance is going to be impacted. So we're going to have to do this patch during a limited, during a special window of time when we know that need or how many hits it's going to have to do this patch during a limited, you know, during a special window of time when we know that, you know, uh, need, or, you know,

how many hits it's going to be getting requests. It's going to be taking in will be less, right? Like, I mean, you would hope that you don't live in that kind of world, but I guarantee you there's that kind of world out there. It exists all over the place.

There's no doubt. I mean, that, that was the best one I could come up with off the top of my head. Cause like really what I was thinking of in my mind were like, um, sands where you might have like, uh,

like some, some set of discs that is for like more high speed reads versus another file system that might be, you know, yeah, it might be more archival type purposes. So it's a little bit slower IOPS or fewer IOPS, slower reads,

but yet, you know, everything's there right um yeah all right you know can we take a second to talk about when you run npm install now and like you start actually kind of scanning through the stuff as it's installing and it's like hey i'm looking for a job contact me at blah or don't use this package anymore you see they're like the stuff that people put into like the the output of the packages you install i've never noticed that oh man uh do it do an npm install and

like actually look at some of the crap that comes out it's it's scary you're thinking like oh that's right i forgot that there's real people like doing this stuff and they have all sort of weird things going on i see packages go by it's like hey i'm looking for a new maintainer because i hate this okay and it's not one that you're explicitly looking for a new maintainer because I hate this. I'm like, oh, okay. And it's not one that you're explicitly asking for anyway. It's a package of a package of a package. Right. It's a sub-dependency of some other sub-dependency.

Yeah, I just put in, like, arbitrary code so it can open up a reverse shell. And then that way I can, when you install my package, I get access to your system. And some of the packages, even ones I have, because I've got a ton of just open source stuff that's, you know, I can't even call it open source stuff. It's just projects I've done over the years that just happen to still be online. And if you try to rebuild them or GitHub will send me a notification everyone's just like, hey, you know, you have like seven security vulnerabilities

on that. And you're like, oh crap, I don't even remember what that project does anymore. I'm not touching that. You install it. And yeah, at the end it's like, hey, you've got like seven criticals eight highs and three mediums good luck man i didn't see that i guess yeah you're not you're not doing good at your operability pieces there yeah bad ops team joe bad you know they have uh there's companies out there that will actually scan your repositories and look for problems and notify you. Someone will actually update the packages for you to create pull requests.

I mean, that's good. All right. It's exhausting. So next is anticipating and planning for future problems. So the scale and capacity. That's not a fun job either. No, that's really hard. And it's easy to just say, oh, just auto scale. But auto scaling is not easy for lots of things. There's very few services that do it well. And even as we covered in the last episode, though, right? Sometimes you might not

start out with auto scaling. You might start out for simplicity purpose, like, you know, get the MVP out there, right? Which might mean you just, you know, have one database or one instance of your web app, you know, or whatever that doesn't auto-scale initially. Yeah, there was actually somebody I'm looking right now who had written a question. So I believe it was nico he was basically ah doggone it hold on there was somebody i'll find the name in a minute but they had asked a question like hey we were talking about slas and slos on the previous one and they were like hey are there any tools out there to help you figure out what they should be and i'm like i don't think so because you don't really know what they are until you the best i could come up with if you're trying to figure out what your uptime and availability and all that kind of stuff would be is you'd have to take your system run a bunch of low performance

things against it, do something like take the Chaos Monkey thing from Netflix and try and destroy things and see how well it does, right? Like, and measure that somehow. Skywalker is null. Skywalker is null. How do you set the initial SLA, SLO was his question. Oh, you did write back. Okay.

Yeah, don't look. Don't look. That's my tip of the week. Oh, okay. I'm not going to. So stick around. I have an answer for that. Okay, cool.

So we won't go into that any further right now because I ruined something. Well, Joe writes in. No, I'm just kidding. Well, I'll tell you. Okay, I'll just tell you. No, no, no, no, no, no, no. I'm just making a joke. I'm just making a joke. Stop it. Tip of the week. I Googled.. No, I'm just kidding. Well, I'll tell you. Okay. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no do want to bring this up, though, because when you start working in distributed systems, do not underestimate how difficult that actually is. I don't think you can underestimate how difficult it is. You can't even fathom how difficult it is. Because when you start thinking about, like we've talked about Kubernetes and the fact that you can scale up and do all kinds of stuff, right? Where do you store all that configuration? If you store it in code, then things can respond to it and do your infrastructure. If you're storing it in databases, how do you know when those things change? If you're storing it in config files or in some other system, like the thing is, you really kind of have to get a plan together. If you start going

into distributed data systems, you really need to think about how you are going to store and manage and update and distribute those configurations as they change. And the answer is doing stuff manually. Then it's kind of like we talked about with DevOps-y type stuff. It's just, it's a world of pain.

So all of this stuff, it's all about automating. Yeah. But I feel like we'd be doing a disservice if we didn't mention names like Chef or Puppet, though, right? Ansible is one of them. They have Helm. It doesn't have to always be about Docker or Kubernetes, though.

When we talk about configuration management, so if you're not familiar with those kind of systems, you could have the configuration of, say, like a Linux environment, you know, all as configuration. And then using those tools, it could like spin up a new environment for you and patch it up to whatever levels you have specified in your configuration file. Yeah. And I mean, if we're talking about so a couple other ones to throw out there, if you're working in AWS, you probably want to look at things like CloudFormation with their templates. If you're working in Azure, I think it's ARM templates. Which one's, isn't there like a Terraform?

Terraform is one that goes, it's, they call it cloud agnostic. It's for all of them. You write things in Terraform and you can have it deploy things in Azure, AWS, Google Cloud, whatever. So be aware that configuration management, if you do start getting into more distributed, more auto-scaling, elastic-type setups, you're going to have to put some thought into it. But note now, we're talking about this from a developer point of view, right? This is operations, right? Yeah, this is operations.

And one of the things you mentioned was committing that to your repo, right? But if you're the ops team... You might if it's configuration. It depends on how you do it, right? I don't know. You know a lot of ops people that use Git? I don't know, Joe. I've seen them sometimes.

Joe, do you use Git? You'll see people have multiple profiles, and you can kind of change maybe the profile that you use via one environment variable to swap the whole thing. Are you referring to the 12-factor app type of situation? Is that what you're referring to? Not specifically. I've seen it before where someone will have a dev profile

and a staging profile and a live profile, and then the environment variable will set all three. I don't like that. I think, well, I did like that back when the DevOps pipeline tools weren't so mature. But wait, how did that

go back to Git? Oh, because you would check all the profiles in. So, like, you imagine you have a web.dig.local, web.dig.staging, web. or whatever, and then you can just transform that uses an environment variable to know which one to swap in. Yeah, I know.

Like, if they were, like, for example, if they were, like, you know, a Linux user profile. Yes. Right? Okay. Or even in ASP.NET. And then you could source, like, whichever one you wanted, depending on, you know, what environment you wanted to be in. Yeah, or even changing connection strings or credentials or whatever.

That's what I was thinking. Like when you'd have a file like connectionstrings.config that would only exist in staging and production or whatever. Okay. Yeah. Of course, now we should mention that you should not be checking credentials into your source code anymore. Please do not. Yeah, ever. Ever.

Because your local Git history could also go up there, right? So even if you didn't think you'd put it up remote, when you push those changes, if you'd ever committed them, they'll be there. Yeah, no, we strongly advocate for you write them down on a post-it note and stick it to the bottom of your keyboard. Yes. Because nobody's going to look for it there. Or under your desk, either place. All right. Yeah, and you've got to keep that forever because unless you hook up the email server on the tools you're using, which, you know, which involves another password that you've forgotten.

Yeah. All right. So here's a here's one that you hope to never be involved with doing complicated maintenance tasks like migrating from one platform to another. Those are rough. Yeah. I mean, even as developers, we've seen some of that pain. Maintaining security is another one. So like the patches and stuff that they were talking about earlier, anything like that that comes in? It doesn't even necessarily have to be patch related though too. Just to not confuse with with a bullet point that was already made it could be something that's like uh you know hey we want to use a different um we want to change

out the what i'm trying to say so like for your tls connections right and you have like here are the different and what's the word one dot two versions no. No, no, no, no, no, no. The handshake agreements, like the different protocols that you could use for... Oh, dang it. TLSSL. I can't even, I can't think now. Yeah, I don't know. Whatever. Ciphers?

No, that's what's going on underneath them. But yeah, I mean, dude, it could even be something like, hey, we want to lock down some of these Active Directory groups, right? It could be anything. Like, hey, we saw that we had a lot of active directory groups, right? It could be anything. Like, hey, we saw that we had a lot of users on this system that shouldn't have access to the system. We're going to start trimming that down.

And if you do that, you can break a bunch of stuff. And ideally, all your services should be talking over encryption, over encrypted channels. All your data should be stored and encrypted at rest. And even with the services communicating to each other, you should be stored and encrypted at rest and even with the services communicating to each other you should be rolling those keys and whatnot uh as you know as is appropriate for whatever you're doing like if you're not storing customer data then maybe that's not as important to you so you need a silent level but if you're if you've got a secure setup then

it's a real beast to maintain the cipher suites suites was what I was trying to think of. I did say that. Yeah, trying to set that. When you're trying to order the encryption algorithms to what you want to use as your primaries versus what order and preferential treatment you want to list them at. You want the strongest to weakest, right? Yeah. And then eventually it will be a downgrade attack. So what encryption algorithms do you use and they're like oh well we've got a hundred thousand servers running tons of different

packages tons of different services the third-party services like what are they all communicating over what like you know some someone says like uh hey blowfish three is out don't use it it's terrible it's broken it's like well crap uh even figuring out which services are using that or have that available is a nightmare if you don't keep on top of your inventory. Yep. Yeah, I would just answer the best ones. That's the right answer. We do the worst ones, too, but we also have the best ones. Well, I mean, we prefer the best ones.

Right. Yeah. But if you need to downgrade it, then fine. So the next thing they had here was making processes and operations predictable for stability. And that's a key one, right? Like making sure those things run in a way that you can expect them to run. Keeping knowledge of systems in the business, even as people come and go that one's important um i think they even pointed out how you do that at some point i don't remember exactly what they

said um but yeah uh yeah i think automating is the best because any sort of manual processes or stuff like that they're all just vulnerability like holes waiting to happen for somebody to trip in. Yep. I mean, they kind of said to that end, it was like, you know, a good ops team, you make things easy for them. So it goes back to that reproducibility,

you know, like anything that you can like automate or script, then, you know, make it easy on everybody. Like don't make people focus on that one little thing that could be easily automated over and over. Let them focus on the high-value activities is what they wrote. Yep. And this is where they say this is where data systems start coming into play.

So all those things that we talked about above, they're basically possible because of data systems. So the data system will give you the visibility into the running systems, right? The monitoring that we talked about. They support automation and integration. This one's key, man. I know we've all written software that does bad things here, but avoid dependencies on specific machines. You ever coded something where it was like, oh, it's looking for this host, or it's looking for that IP,

or it's looking for this specific drive or something like that? Like when you do that kind of stuff, you make it very hard for an operations team to maintain that stuff. Like you said, if you have to do a patch on something so you need to swap over to another one, that might be way more work than what you ever thought it would be. You know, this is actually interesting when the two,

because if we're talking about it strictly from an ops perspective, right, I've actually seen customer environments where, okay. So like your initial reaction might be like, um, one version of this might be like, okay, Hey, use the DNS name.

You mentioned the IP address. That's why I was going with that. So use the DNS name, not the IP address. But I've actually seen customer environments where they're like, no, no, no. We don't want to rely on the DNS server. So you go by IP address, right? Wow. Right.

So, I mean, and depending on the need, you're like, okay, I mean. I get it. Maybe in a particular environment, you could see where that was coming down. Like, you know, if it was like real-time sports, for example, you know, and you might not want to rely on DNS just because if you did lose DNS for a moment, you don't want to lose your ability while you're live on air, right, to be able to show what happened half a second ago. But what if that one machine with that one specific IP address goes down? Right. Or, yeah, you might have something in front of that IP address that's masking that there might be five things handling that IP address, but then that one thing goes down. Yeah.

Yeah. There's no perfect solution, right? There really isn't. It's a case by case. It really is. And we might like to fool ourselves and say that, like, no, no, no, we could write a book called, you know, well, I would say Clean Architecture, but that title's already taken. But whatever, you know, and claim like this is the way you should do everything, but really

it's going to vary. There's always going to be extreme environments that are going to be like, well, that's not going to work for us. Remember in 2015, we were talking about Toll Factor App for the first time and we saw that they were recommending environment variables.

And we're like, why wouldn't you just use a file? It's so much more easy to keep it checked in. And now, after some user experience, and of course going through that section, just realizing how powerful it is to be able to have different settings per environment, which seems totally common now. But at the time, I remember just being like, what, why?

The face he made. So the next thing they have here for data systems is documenting easy to understand operational models. So basically if you do this, then this will happen, right? Like those, it's almost like stories for the operations teams. The next one, giving good default behavior with the ability to override that behavior, which I think is key. That's super important for

everybody ever dealing with these types of systems. I like defaulting to local development. So make it easy for developers to get up with one command and then have any other specific stuff for production or staging or those environments be that have that configured outside in the build process or deployment process. It's so hard though.

It's so hard. You can try your best to make things as easy for like local development and then not realize that you baked in some difficult dependency. Like typically database is the one that comes to mind the most databases are a pain. Yeah. They're necessary, but really hard to work around. The next one that they have here is self healing when possible,

but somebody can actually intervene and manually control it if necessary. And again, they allow you to monitor for predictable behavior, right? So these data systems are super important in the operations. Do you think they were thinking of like the Tesla autopilot when they wrote that? Predictability? The ability for manual. None of this halfsy stuff.

Yeah, the ability to like manually take over. This episode is sponsored by educative.io. Yeah, the ability to jump right in and learn as quickly as possible without needing to set up and configure your local environment. The courses are full of interactive exercises and playgrounds that are not only super visual, but more importantly, they're engaging. And the text-based courses allow you to easily skim the course back and forth like a book so there's no need to scrub through hours of video just to get the parts that you really want to focus in on yeah and just when you thought that it couldn't get any better they've now introduced subscriptions so check this out for a limited time they're offering 50 off their new subscription price and with that once you subscribe at that price you're locked in to that subscription price. And with that, once you subscribe at that price, you're locked in to that subscription price for as long as you remain a subscriber. So it's basically like you can head to educative.io slash coding box and get 20% off any single course, or you can subscribe and you're

essentially getting 50% off of every course. And I want to mention again, we talked about a little bit on the show here, but Grok and the System Design Interview has been one of the favorite courses I've ever taken just of all time. It's been really great. And it really goes hand in hand with a lot of things that we have been talking about lately with the book. So I definitely recommend you check that one out if you're looking for somebody to get

started. Yep. So start your learning today by going to educative.io slash coding blocks. That's educative.io, E-D-U-C-A-T-I-V-E dot I-O slash coding blocks and get 20% off any course. Hey there, Joe here again, still, still here. And I'm going to ask you right now to please leave us review because we love it. We need it.

We feed on it. We require it for warmth. It keeps us going in the cold heart of winter. And I would really appreciate it. And we try to make it easy for you because if you go to the website, www.codingbox.net slash review, we will try and give you a couple of links. We know we do. Weodingblocks.net slash review. We will try and give you a couple links. No, we do.

We don't try. We do give you a couple links that make it easy to drop some reviews for us. And, you know, we love those five stars. And a big thank you to everyone who has left us a review. We really appreciate it. And the names are amazing. So keep it coming, please. All right.

So with that, we will head into my favorite portion of the show survey says all right so uh all right back in episode 119 uh we asked how often do you replace your computer? And your choices, your choices were, I forgot how good some of these were. Hold on. Your choices were every few years, my guilt needs me. Or after every Apple announcement. Or I upgrade it until I no longer can and can't stand the weight or never. And this four 86 is still rocking doom.

Or lastly, every time my company gives me a new computer when I change jobs. All right. So, um, I think maybe Joe went first last time last time right maybe you always say that so okay then joe goes first joe wants to go first oh i wasn't paying attention um oh um i think uh this 486 is still rocking doom and i think it's at 38 wow all right big baller i think i

i think people are going to say every time my company gives me a new computer when i change jobs uh we'll go there and i'm going to stay at a nice safe 30 30%. All right. So, we have Joe saying never at 38%, and Alan saying when his company gives him a new computer at 30%. Yep. 38% and 30%. All right.

You both lose. Really? What? Yep. Please tell me it's not after every Apple announcement. Of course. I'm going to lose. No, it's not. No. Okay.

No. Do you not know our community? I do. Obviously, their guild needs them. Really? Have you not seen the gaming channel? Oh, that's amazing. What was the percentage?

So every few years, 40% of the vote. Wow, that's really good. All right. Yeah. I was actually really surprised about that one. I didn't anticipate that one. I didn't either. It was my favorite answer.

Yeah, same. From the funny's point of view, I thought it was my favorite answer. The Apple announcement one was just be like, I was going to be heartbroken, you know, because then I'd be like, oh man, there's a lot of people, you know, putting themselves in some unnecessary debt. Then if that's the case. So what was number two and three then? Uh, uh, well, okay.

So number two was I upgraded until I no longer can. Okay. And, and can, can't stand the weight. Um, and number three was every time my company gives me a new computer. Wow. So the two top hitters were people that are all over it. I like it. Yeah.

Yeah. I like it. I'm still waiting for my guild invite, people. Right? Well, I mean, I don't know. They've seen us play, so maybe that's why we're not getting it. It's true. All right.

So, do you want another survey, or would you like a joke? A joke, then survey. Survey. No, that was a joke. That was a joke. Get out of here. What? All right.

So, last time we had a joke from Mike RG and he supplied me with another one. You ready for this one? We are. And you guys, especially since you have your London talk coming up, you're going to appreciate this one. Why did the PowerPoint presentation cross the road? To get to the other slide. Very good. Wow.

Boom. Did you know that one already? No. I was just trying to think of what's in a slide deck. Slide. To get to the other slide. There you go. Yeah.

Very nice. Very nice. I win. I win. All right. Well, in the spirit of the rise of Skywalker and Baby Yoda. Man, I love me some Baby Yoda. Do you?

The Mandalorian. I could watch that little thing. I want one. I want a Baby Yoda. Yeah? I do. A little Baby Yoda? I do. If you haven't seen The Mandalorian. I don't know, man. I want a baby Yoda. Yeah? I do. A little baby Yoda? I do.

If you haven't seen The Mandalorian. I don't know, man. Have you seen the way they eat? I don't know that I want to do that. Dude, I love that little thing. He's a cutie. I'll give you that. I don't know that I want to have to clean up after him.

I need him. Joe, have you not seen this baby Yoda? No, I'm still watching reruns of the Star Trek cartoon. Dude, come on. All right. I will say this, though. I am enjoying The Mandaluns of the Star Trek cartoon. Dude, come on. All right. I will say this, though. I am enjoying The Mandalorian. I am, too.

I like it a lot. If you haven't seen it, if you haven't subscribed for Disney+, like, yeah, I'm enjoying it. Now's a good time to do that seven-day free trial if you haven't and you don't want to because I think most of the episodes are – how many more are coming? I don't know how many more are coming, but there's a... There's like six of them out now. Yeah. All right. So with that in mind, we ask, which sci-fi series is best?

And your choices are Star Trek. Damn it, Jim. I'm a doctor, not a doc. Okay, fine. Or Star Trek. Damn it, Jim. I'm a doctor, not a doc. Okay, fine. Or Star Wars, Han shot first. Or you can just write in Rick and Morty in the comments section to win the book. Somebody trying to skew the results. Turn off that additional comment field.

Right, right, right. Well, now I'm curious that you got me thinking like, let's see, IMDB, The Mandalorian, because now I'm curious to see just how many more are there. That's a spoiler. Is it? Can we just go ahead and say that Yoda is not the name of the race? Wait, I didn't say it was the name of the race. I said it was Baby Yoda. It was Baby Yoda. This is Yoda Jr., man.

Everybody calls him Baby Yoda. Yeah, it looks like there's going to be eight episodes to the first season, and six of them have already aired. Yeah, so don't do it this episode. Go get your seven-day free trial on the next episode. Also, I totally am the person. Because when this episode drops,

you would be good. Number seven would be out, right? And number eight will come a few days after. Oh, that's right. You'd be able to see it within the same week. Okay, so you're good. It'll get you a free seven-day trial. All right.

Yeah, but excitingly, it looks like they've already got season two in the works. Ooh, I like it. Yeah. This episode is sponsored by about you. About you is one of the fastest growing e-commerce companies in Europe headquartered in Hamburg, Germany.

The online fashion store is currently live in 10 European markets with more than 8 million app installs and 15 million active users on its platform, which handles more than 300 million API calls per day. In 2018, About You reached a company valuation of more than $1 billion US, moving up to the exclusive circle of European unicorns. This could only be achieved by the excellent work of About You's tech teams. One third of their employees are developers and come from over 40 different nations, which truly enriches the teamwork of the company. What they all have in common is that they are highly driven by the passion to develop the best product on the market.

About You also has an award-winning organizational move model that allows developers to switch teams, ensuring constant learning and developer fulfillment. About You has built its software in-house with leading technologies such as Laravel, Node.js, and TypeScript on the server side, Vue.js and React on the client side, and Flutter for mobile applications. Besides a variety of free drinks and fresh fruits, About You offers free language courses and helps new employees in the relocation process if they move from abroad. Moreover, developers get free tickets to About You's own organized conference, Code.Talks, one of the biggest tech conferences in Europe. The conference that has taken place in Hamburg is visited by more than 1,500 developers. Furthermore, About You offers a

well-structured onboarding process with a buddy system and provides access to e-learning tools such as LaraCast and Egghead.io. When starting at About You, you have the choice between different hardware setups as well, for example, MacBook or Windows Notebook, and the kind of IDE you want to work with. About You is growing fast and is constantly hunting for new and motivated team members. About You currently has positions available for full stack, front end, and dart or flutter developers, a quality assurance engineer, and a project manager, as well as other exciting leadership positions. Does this sound good to you?

Apply now at aboutyou.com slash job. Again, that's aboutyou.com slash job to apply now. They're looking forward to hearing from you. All right, so we're back now. And in this last little section here, we're going to talk about simplicity and managing complexity. So we've all seen it. As projects grow, they tend to be way more complicated. Right.

And this does a few things or a couple of things that really aren't that good. One, it slows down the development because it takes a lot longer to make changes. We've all been there. And this is also something that we've talked about, I think, maybe in the anti-patterns episodes or whatever. It turns into what's called a big ball of mud. Basically, it's so complex that you can't make changes because you don't know what the ramifications of those things are, and it's so hard to follow that they call it a big ball of mud.

Yep, that was – I don't remember which episode. But it was the Software Designs Anti-Pattern, episode 65. 65, very nice. Yeah, I'll have a link toPattern Episode 65. 65. Very nice. Yeah. I'll have a link to that in the show notes. Cool. So now we've got a little section titled, You Might Have a Complex Indicator If.

Here's your sign. Remember that guy? Jeff Foxworthy. That'd be a redneck if. Yep. No. Yeah. No, Jeff Foxworthy was,

You Might Be a Redneck If. Yeah, that's what he, you might be a redneck if. Yeah, that's what he was. Here's Your Sign was Bill Ingvall. Oh my gosh, I think you're right. No, no, no, no, no. Yes. Jeff Foxworthy was both of them. Here's Your Sign.

Here's Your Sign was, yeah, okay. Here's Your Sign. We all go to the internets. Bill Ingvall. Allah does not forget a reference. Stupid people, Here's Your Sign. I'll go to the internets. Bill Ingalls. Allah does not forget a reference. Stupid people, here's your sign. I'll be doggone. Okay, so you mixed the metaphors.

I did. But that's fine. They both were on the Blue Collar Comedy Tour, so you're allowed that. I'm just saying, one of us might have a better index than the other. I think your index is not corrupted. That is true. I can't say better because I am an agent of chaos. I weave it.

I sew it. So, yeah, like one of the – there's a couple of these things that are pretty interesting, the indicators of complexity the explosion of your state space tight coupling which we've talked about in the past spaghetti of dependencies is another one that you see a lot of times and but you know when you hit all these right like it's pretty obvious to you and you're like that's weird we're storing the person and the order and the order history now in session memory crap or spaghetti if we go to update something and it breaks like five of the things you can't update so it's just easier just not update yep okay but can we can we time out for a moment i don't want to rush through these some

because some of these it's like okay there are tools out there like spaghetti of dependencies you know here it's called but we've talked about it a few times related to like, uh, independent and as well as we covered it in the clean architecture series related to, um, the, the zone of pain versus the zone of uselessness. You know, they're like, Oh yeah, that was cool. There, there were, there were different tools out there for charting those kinds of things. And, you know, like visualize it in, in uncle Bob actually gives you an algorithm on how to to calculate it right so i can see tight coupling and spaghetti of dependencies falling into that but explosion of state space like what what what do you mean when you say that like are you just talking about like you require a lot of memory uh to be able to keep things in state at the time like i i think that's basically I think it's just that, what you just said.

And I think it's what Joe said as well, is as you go on, because things get more and more complex, you just start storing a ton more in data structures in your application. I think that's what they're referring to there. Yeah, I don't forget what the book actually said about it. That's all, They just had a bullet point on it. It wasn't anything massive. The next...

Inconsistent coding standard naming terminology. You can get a plug-in to help with this, but it kind of masks the problem a little bit. I think because the coding naming terminology... I guess you can't really fix the terminology but you can fix the naming standards so like how you case things and that

certainly looks better but terminology is a big problem if you don't have that ubiquitous language that we've talked about many times and that's a big problem someone's referring to orders and someone else is referring to invoices and they're both kind of similar notions which are not quite the same I had the same exact thought whenever I read that one, was this goes back to domain-driven design and ubiquitous language. If you're not using the same terms between developers and departments

and whomever else, the business people, then that's a big, big problem. It's all connected. Yep. If you find yourself hacking in performance improvements, you might have an indicator of complexity. We've all seen that. If you've got code to handle, one-off edge cases sprinkled throughout your code.

These are indicators of complexity. And so we're not saying that these are necessarily wrong, but by saying they're indicators of complexity, it means that your project is kind of by definition is harder to maintain. It might be worth it. Yeah, I can give an example of this. I mean, we've all worked on a project in the past where there were different payment systems, and you'd see these kind of things sprinkled all throughout.

If PayPal, then do this. If a credit card, do this. If pay by some other service, then do this. That, you might be thinking if you're listening to this and you haven't done a lot of development and abstractions, you're probably thinking, well, that's how I do it. You know, if this and this, but the problem is that code starts getting everywhere throughout your application, right? Because at the time that somebody placed the order, then you had those things. Now, when you

go to fulfill the order and you have to charge those things, you're going to have those same if-else statements everywhere, right? So it just starts creeping throughout your code base. And the proper way to handle that is to abstract it. So you're going to have something like an IPayment, and then you'll have a PayPal that implements IPayment. You'll have a credit card that implements IPayment. So that's basically what they're talking about here is when you start seeing all these edge cases sprinkled out in switch statements and if else's and whatever, it gets really complicated and you really start introducing bugs because you knew to update these three places over here, but you didn't know that it also grown feelers and crawlers out to these other three

places, right? So that's the biggest problem with it. Yeah. And even that's hard, you know, something to say, just segment off the business needs and kind of uh abstract around those requirements and fill in what you need but there's a couple problems with that like sometimes the business requirements are radically different for different payments processes or how they do refunds or like you have to do things out of kind of different orders and so it can be kind of hard to hide that stuff and alternatively sometimes you can have a great abstraction and have two different providers and then be like 75%, 80% the same. And so by breaking them out like that,

now you've got these duplicated codes that have these things in common that you've got to maintain in two different spots. Well, maybe not. So depending on how you break it out, it can be awkward. Right. Well, that's what I was going to say. It depends on your language, right? But if you had like a base class that had the 80% that would have been duplicated and then the 20% in each one of the other ones, that's a better thing. But, I mean, the thing is all languages operate a little bit different.

So, depending on your language of choice. But that's the key though. If you find yourself putting a bunch of business logic sprinkled throughout main code, then you probably haven't abstracted it enough to make it to where it's reusable in other places.

Yeah, do your best. And there's a greater chance of introducing bugs if you've ever been scared to change code because you think you might break something and you're not really sure how to test it or how to tell if you broke something. And that's an indicator of complexity. And a lack of unit test. There's that. Although unit tests can also be a source of complexity.

Sometimes you need to change something and you realize you just broke a bunch of tests. But we've talked about ways for mitigating that and also that just being a sign of your tests being brittle and testing the wrong things. Yeah. I mean, I can give an example of where one time this whole thing of a greater risk of introducing bugs is I was given something to where, you know, they wanted to be able to do, like, refunds in the system, automating refunds. And the problem was I did that stuff and I knew what I was doing, but I didn't realize that there were these consequences of doing it that messed with some transaction tables that I wasn't even aware of that existed. And so I introduced a bug into the

system that was super hard to track down all because i had no idea what was happening behind the scenes on those and it was it was hard to find i had some uh serialization code with a bunch of tests around it because it was custom serialization and then we changed uh the naming conventions for all the fields and then changed the all the insta guids for uh for keys man those tests got ruined and when you're looking at like 70 tests failing and you look at it and it looks like it's just this big string diff it's not real clear to see like which part you know it makes it tempting to just say well i'll just copy the result of the actual paste it into the expected which totally defeats the point of the test there right but it could be

really difficult sometimes based on those tests. And it's not necessarily anything that was wrong. But when you're comparing in the, like the test runner, like these 60 line, 60 character strings and, you know, 30% of it's changed and all the field names are different. It's just like, I mean, it's just rough. I've had cases like that too, where it's like, you know, does it feel like I'm testing the wrong thing? And anytime I have find myself in a situation where I need to run it in order to see what

the output is. And then that's what I want to like, okay, this is the output that should be like the expect of, of a unit test. And I was like, Hey, wait a minute. Yeah. I'm doing this backwards. Well, cause I've had like two different things that have come to mind that are like that one was like oh gosh actually three one was in the case of like serializing objects and it was like okay well uh you know it was said is like yeah i could handwrite it, you know, as to what the, I expect the serialized version to look like, or I could just go ahead and run it and see what it

is. And then like that, you know, if I visually say like, I look at it and be like, yep, that's the, that's the thing. So I'm gonna put that and expect, but then it's like, well, anytime anyone would add or change a property on it, then the serialization would change. And then, and eventually I was like, man, am I really testing the right thing here? Cause you know, I ended up dropping the test in the end. But another example that comes to mind is like, uh, code generators. So, you know, you want to have, you want to test the output of your code generator and so you write the code even if you handwrite it to match but then it's like okay now i've decided to update what the output of the code generator should look like you're like well those tests are just broken and then another example the last

example that comes to mind is like encryption like if you want to test encryption and you're like oh yeah well how do how do i even know what the out the expected output should be by hand right right it's it's something inherently done by a computer program so well i mean yeah i guess technically you could do the math if you wanted to but do you want to right yeah right so it Right, so it's like, yeah, I don't know. I guess I'm just going to run at this one time and I'll be okay with it. Yeah, happy and pleased. Maybe.

Yeah, I will say with the serialization, you're totally right. In those cases, it's because I was basically serializing an object and seeing what it was. And if you add a property, it does break it. And so the problem is there, I've coupled my serialization mechanism you know mechanism and logic to my to my objects there and so i was i should have had a separation there but i will say also those tests were some of the most valuable tests in the

project because there were all sorts of times when someone would update a regex or something small and like oh you just broke uh situations where there were like triple nested you know whatever and so it was kind of nice to say like oh we actually broke something and we had like real oh, you just broke situations where there were triple nested whatever. And so it was kind of nice to be able to say, oh, we actually broke something and we had real-world use cases. So in that essence, they were doubling as integration tests, which was useful, but more brittle. That's interesting. And they weren't explicitly marked as integration tests.

Because you guys are talking about basically an object hash. And that's something similar to that but i mean okay so i'm talking about the thing i had was like a custom a custom json serializer and the deal was i couldn't just serialize the json because i also had to do some transformation so things like maybe arrays weren't supported or whenever i saw this type of array i had to transform into that type of array so i had to do some other kind of stuff and it wasn't really um it wasn't uh it was like there were rules around it so there weren't like specific names i was looking for anything there were just kind of patterns where i would strip everything that had a named of type and if it was uh square brackets and it would convert to

curly brackets or whatever so it just had a custom format that i had to match and yeah it was just so much easier to use like real objects in order to test the serialization. And I shouldn't have done that. I should have totally separated those. So I'm going to go rewrite those 70 tests. Yeah, that would have been a lot harder, though. I mean, I think I know what you're talking about. Like, JSON.net, depending on how data comes in, requires objects versus arrays.

Or you have to add additional properties it's sort of a mess yeah and sometimes like if you've got like some classes and you need to kind of get them to match out to it like json format the the format that the thing you need to pass to the json 2 will just have it's like a slightly different structure and then what json will will uh will do so you end up writing custom serializers and just so much easier to associate that with the class yeah i think in my case would have been for those in hindsight in my case related to the uh, we'll do. So you end up writing custom serializers and just so much easier to associate that with the class. Yeah. I think in my case, it would have been for those in hindsight, in my case related to the serialization when it was like,

I should, I should have just used a mock object that was local to the test instead of some class that was being used outside elsewhere. And then I would have avoided the problem. Oh yeah. That's a good point. You know? Yeah.

Because then like if you're changing the mock, then you know, you're going to be running those tests and be aware. But what happened in my case is that, you know, people weren't aware of the tests and would have the habit of not running all of the tests. And so they wouldn't know it until it got merged in. And then it's like, oh. You broke the build. You broke the build. And they'd be like why didn't you touch that i'm like well i know what the problem is it's real easy to fix

here it is and then you know after like the third time it's like this is stupid yeah i don't want to keep doing this just delete this thing because i don't feel like i'm testing what i wanted to what i really should have been testing what i wanted to test or like what i need to test yeah i don't know all right so tangent aside yep so let's move on to uh where are we at uh blah blah it was x out it's that one oh so uh reducing complexity improves maintainability of software agreed yep for this reason alone we should strive to make our systems simpler to understand. Now, does simpler – okay, so less complex or simpler. Yes.

In your mind, do you also – does size play into that in your mind? Yeah. No. Because it does for me, right? I mean, and this is consistent with everything that we learned from clean architecture or clean code. Size of what? Size of methods? Yes.

All of it. Size of classes? Yes. Size of library? Size of class? Size of function? All of it. It doesn't.

Oh, man. all of it it doesn't oh man so here's the reason why i say no is because by splitting up things into more methods you are adding more code and c-sharp for instance right because you'll have more lines just for method definitions and that kind of stuff so it's not necessarily as longer is is worse for me it's just did you introduce the right level of abstraction? Did you break up your methods properly? That, to me, easier to follow. Like, you know, we talked about the magazine flow or whatever. I mean, let's just put numbers to it.

In my mind, a three-line method is far easier to grok than a 300-line method. Absolutely. All right? Absolutely. So we agree on the extremes. Now, where do we meet in the middle? Where is that middle? How many methods?

So I guess this is where I'm going. Just say the one method. Let's say that those 300 lines are critical, though. Okay? 300 lines are critical though. Okay. So is it easier and simpler to maintain if you take those 300 lines and turn them into 10 methods? Right. So that'd be 30 lines a piece versus the one method with 300 lines. Yeah. The 10 methods with the 30 lines each is going to more than likely be easier to understand if it's broken out properly.

I get, that's what I'm getting at is I don't necessarily think the length of it determines whether it's complex. It's whether or not you had a bunch of what we call a cyclomatic complexity. If you have a bunch of nested if-elses within a method, super hard to follow. If you break those out into well-named methods that identify what it is. And those names are what's key. The name.

Because if you have 10 lines of code, sure, it might, you know, maybe those 10 lines aren't that hard to understand if you take the time to read it. Versus one line where the method is super clear what it's returning or what it's doing then it's way easier to understand yes so but that's why i say the length isn't as important to me as a well thought out um implementation of whatever it is that has to happen because like let's like i said man to me i i mean i feel confident. Joe's on my side here. Yeah, if I look at a 10-line method and I see a new variable declared, I know it's not used outside the scope of those 10 lines.

If I've got like a 40-line method, even if it's well thought out and organized, still there's always some question over like, am I done with this variable? Was it only used for that one line? Does it come back into play later on? To me, it's just easier to kind of focus on little pieces. I completely agree. Smaller methods, MoBeta, good names on those methods better. But what I'm saying though, is there are some things that require a decent amount of complexity for whatever it is. And so just because a file is 400 lines long, a class, let's say, is 400 lines long,

doesn't mean that it's necessarily hard to follow, right? Yeah, if it's just doing one thing, right? If the methods were broken up and named properly and it's all put together in a well way. So I guess that's what I'm saying. Okay, maybe we should put it this way. Maybe we should say that complexity tends to follow larger size. I could probably get behind that. Whether that be method, whether that be class, or whether that be library or application. The larger the thing is, it tends to be – or maybe I should say it the other way. The more complex the thing is, it's probably going to be larger. The inverse could also be true, though.

The more abstractions you have, the more difficult it can be to reason about as well. Well, there's a joke about that there, right? Yeah, the hammer. That's the factory. No, no, no. Oh, gosh, how's it go? We need another abstraction? Oh, my gosh.

Yeah, I don't know, but I guess that's what I'm getting at. I remember even our buddy Will, who was on the show with us a few episodes back, I remember him changing his status on his Skype or his messaging profile or something. It was hilarious. It was something along the lines of abstraction for abstraction sake is insanity or something. I don't remember what it was, but it was somewhere along those lines. And it's because if you have a bunch of useless abstractions, it makes it really hard to follow the logic of what's happening. Right. So

I don't know that that's why I'm saying Like, I'm sort of sitting on the fence here. I think well-written code and well-defined, well-named things goes a long ways towards simplifying that for other developers following. and I actually capped these things. Reducing complexity in your code does not mean that you're reducing the functionality in the end user software, right? That's super key because a lot of people think, oh, well, if we have to tear this out, then the user is going to lose something. No, you can write good code that accomplishes the same end result.

All right, and there's also the notion of accidental complexity, which is something that's not inherent in the problem that the software solves, but arises only for the implementation. So this is a stuff where basically, I don't know, it's a good example here, but basically where the implementation details are a sticking point.

If you've ever had somebody ask you to do something, a project manager ask you to do something, and you start talking about coding constructs or why something can't be running in 32-bit or 64-bit or something, there could be these technical reasons that are far removed from the ask that end up just becoming a problem. And so sometimes that's something you should have dealt with, and sometimes it's just a fact. It's like a law of nature. It becoming a problem. And so sometimes that's something you should have dealt with,

and sometimes it's just a fact. It's like a law of nature. It's a problem. Well, I think that would go back to your payment. We've talked about payment examples before, right? So the software, like accepting a payment, it's not inherent to that problem. But if you write that software specific to a

particular gateway right uh you know be it a credit card processor or if it was specific to amazon payments or google payments or or paypal or whatever right and now you're like asked to hey we need to add in support for a second or third gateway. You're like, oh, but everything is specific to the one. That's the accidental complexity. Yeah, and another one that I think of is in SQL, in databases. Like if you just have a select where you're trying to do like a filter, but you realize that it's not going to work because that table is too large and you end up doing a bunch of select and attempt tables and a bunch of sub filtering only to do some CTEs to write that

simple query to make it perform faster. That's complexity because of the implementation, because you're having to deal with a performance issue there as opposed to just the simple, hey, select from here where this equals this. You know what I wow okay so that's a different that's definitely a different way of thinking about it then so the accidental complexity is you know it was an implementation detail and and that could be a problem like like it wasn't uh normalized or maybe it was too normalized right maybe it was set up for fast transactional rights and so reads are more complicated because you now have to do things. So that's the thing, right? Like what we're talking about here applies to all kinds of different things.

But the key is the complexity wasn't the business problem. The complexity was what you had to do to just even make the thing happen. Okay. So then we're kind of getting ahead of ourselves then, but, or maybe, but how to remove accidental complexity, right? So in the, in the case of like my payment gateway example, you could hide that by, or not hide it, but you could remove that accidental complexity by having an abstraction so that you, your code isn't intimately aware of the details of one specific payment gateway. And instead, you know, you're hiding that implementation detail behind a facade. Yep. And in talking about the payment things,

like people that haven't dealt with those, there's a lot of things that go on behind the scenes that you never know. Like if you've ever gone to a gas pump and it says, Hey, don't use your debit card here because this is going to put a hundred dollar hold on your debit card. Right? Like a lot, a lot of places will say something like that. I've never seen that. Oh, really? They actually say it on the pumps. As a matter of fact, a lot of places, if you book a hotel now, they'll actually tell you not to use a debit card there because they'll hold the funds on your debit card and your bank account for the entire hotel thing too, right? So the reason I'm saying this is if you've never looked at a payment system and all three of us are pretty hyper aware of this stuff is there's things called authorizations that

happen on a credit card, right? So that's what we're talking about is you go to a gas pump and you go in there and you say, hey, it doesn't know how much gas you're going to get. So it doesn't know if you're getting 30, 50, 60, 100. So it's going to place an authorization hold for a hundred bucks on your thing. So if it's on a debit card, it's hooking into your bank account, right? If you're paying with PayPal, PayPal had no notion of an authorization, right? So what you do, and we've talked about this in the past, is you use a pattern called a facade pattern. So you might, for your payment system, say, hey, I need to have this authorized function. So for a credit card, it would go hook into the gateway and actually call the authorized.

For PayPal, it would probably just do a return void or do nothing because it doesn't need to. But hiding that behind that abstraction allows you to do whatever you need with basically any payment system out there. With PayPal, though, it was actually more complicated than that. PayPal. You could do authorizations, but it wouldn't do – it's not like it was going to hold it. It wouldn't lock it. Right.

Yeah. It would just check to see if they had it. Yeah, they have money in the account right now. Right. But it wasn't like a hold on the account. It was sort of useless because you could authorize it. They could spend that money five seconds later and you'd be left holding the bag. Yeah.

Yeah. Now, who knows if it's still that way? That's the way it was when we were dealing with it. But at any rate, yeah, I wanted to point that out because having a concrete example of that might help. All right. So the abstractions also allow you to reduce duplication as the abstraction can allow for more reuse among other implementations. Yep. So what Joe had talked about earlier, like you have this 80% of code that's the same

between all three of them, put that in a base class and then have subclasses off that that just do the various little specific pieces they need to. So some examples of good abstractions are programming languages they abstract away from your ram your ram registers your cpu your chipsets when was the last time any of us had to think about doing any of that kind of stuff with c-sharp or java or anything you don't right software development is just a constant evolution of more abstractions on top of abstractions on top of abstractions. It's turtles all the way down. It really is. And it's all about making those little, little things easier over and

over and over again until next thing you know, you're slinging together big data intensive systems. Well, that's what's funny. So the next one they said that was an example of a good abstraction is the SQL language itself. It's an abstraction over complex memory and data structures. And as you get into, so I know Joe and I have been dipping our toes into this world quite a bit. As you get into big data systems, the one thing that seems to be constant is the sequel language. Like everybody wants to build tools that use sequel. Like everybody you look at. So there's things like Presto DB out there. There's drill,

there's hive, there's all kinds of things. And they all have a sequel plugin type thing to our sequel, like syntax that you can use. Yes. It it's because it makes sense to us. It's, it's sort of, it sort of reads like you don't care.

English. Yeah. You don't care how, how the data is stored on disk. You're just saying like, look, I want all of the data where the first name is Bart and the last name is Simpson. It's easy to reason. Yeah. Return that.

Exactly. Yeah, exactly. It's easy to reason. So, um, yeah, SQL is an abstraction that I think when we were reading this book in one of the earlier chapters, they say it was started in the 70s or something, and it's just turned into what everybody is sort of latched onto for reading and understanding data. So, killer good abstraction, basically. And then they actually say, and this is kind of the funny part, and it makes a lot of sense, finding good abstractions is really hard, really hard to do. And they basically said that that's become apparent with these distributed systems because

they haven't found the patterns that have emerged yet to make these abstractions work across systems, right? Here's something, though, that – this is why I say, like, when I said that the programming or software development is just abstractions built on top of abstractions on top of abstractions. Because, like, we need to have some lessons learned, right? Oh, yeah. Like, even imagine the knowledge that you had today, right? And Doc comes up to you and he's like, Marty, I need you to go back to 1955, right? And so you hop on the DeLorean and you go, right? Now packed with all of the knowledge that you know today, right? Imagine the influence that you could have if you got stuck there and you're like,

well, I'm going to make the best of it, right? And you still want to do software development, right? And so you wanted to try to like, hey, yeah, that's great, but this is the way it could be, right? But you still wouldn't be able to skip. You wouldn't be able to skip from 1955 technology to 2019 technology because everybody would still need to have you know have to go through those lessons learned of of you know building the the first abstraction of going from like card readers to like okay let's manipulate the registers uh with with binary or whatever or assembly language right versus okay well that was cool let's go to c now instead or okay that's cool but you know i kind of like to think in terms of you know like

what if i could have like an object that could maintain its own state and manage you know and you just keep building on top of that until eventually you're talking about something like react or or even better than that you're talking about something like react or or even better than that you're talking about cloud computing right right like you'd still have to go through all those steps yeah it's layers right it's layers of things that have happened over the years and it's it's not easy you can't build a seven layer cake with just the top layer i mean we we all do it every day in our writing of code, right? Like, I know, Joe, you said you do it.

I do it too, right? Like, I'll write something out, get it to work, and then I'm like, all right, refactor, refactor, refactor. Yes. Right? Yes. Yes. That's a great example.

That's extracting those patterns. That's finding those abstractions that you need so that the thing makes sense and it's no longer just one big blob of thought that somehow worked yeah tdd yeah is what you're describing yeah there's one change i would make though what's that okay back in 1970 when the they're determining a sequel which by the way i just found out and maybe i learned this before but i don't know before you say it joe i don't know if you've heard this alan but he has a few

little gripes with sequel he's not a fan here it comes yeah we're ready lay it on us but there's only one thing that i would mention what because everything else all my other grips with sequel are all things that should have been taken care of after after the fact and uh you know anyway we won't go there the one thing i would just kind of whisper into the IBM people's ears, I would say, you know, if you put the from clause first, then when you do the select tools in the future would be able to help you autocomplete the columns that are there. I agree with that. It is annoying that you have to put the from after it just to get what you need in the top. So if you want autocomplete, you've got to go write the from and then go back up a line.

Yeah. Well, I mean, I guess I'm not going to be the only one that writes their queries like this where you're like, select star from table and then go back and change the star. Yeah, I do too, but I hate that. That's how every sane person does it nowadays because you need that.

And you got to write the where clause before any sort of update or delete. Yeah, because you need it in there. And then you put a begin tram around it first anyway. Nope. I was thinking the same. Oh, God, you guys. Well, I don't modify data in production. Thank you.

Yeah, that was my answer too, sure. guys. Well, I don't modify data in production. Thank you. Yeah, that was my answer, too. Sure. Right. Yeah. Yeah. No cowboy coding here. Right. So the next thing is evolvability.

And this is the last little bit is making changes easier. So it's very, very likely that your system will need to undergo some changes as time moves on, right? Business needs change, user needs change, whatever it is. Things are going to change and your system has to modify with it. I mean, look at how Facebook has evolved from 2007 to 2019. MySQL, MySQL and PHP back in the day. Yeah, which is still PHP and MySQL for a lot of things, but it's

scaled a little bit different now, right? Is it still PHP? I didn't think it was anymore. I believe it is PHP. Isn't it? Isn't it index.php? It's a compiled PHP. Okay. I believe they still stuck with it. Yeah. I want to say D language too is supposed to be. Hack is

the name of the language that compiles to PHP. Okay. All right. Hold on. I'm going to find that out. You go on. All right. So this is where some things like Agile has come into play to allow us to be able to adopt these changes quicker, right?

But with that, there came some tools and some methods that have grown out of it. And let's ignore the fact that agile was supposed to be a, an idea to follow instead of a bunch of certifications, because that drives me crazy now. But really what came out over things like test driven development that grew from the need to be able to agile, to be agile, be agile in software development. Refactoring is another one. And the book even says that they are focusing on how to be agile within a large data system. And one of the examples they gave, which I don't think we went into in depth because really you need the book to get the full appreciation of it, was like what they went through when they were trying to change the home timeline for a Twitter account. Like they went through several iterations because it's a way harder problem than

what you would think. Um, you know, for users that have 20 million followers versus users that have five, right? Holy mackerel. Some people have too much time on their hands what are you talking about so so the short answer is to your facebook question does facebook still use php is yes but this i just put a link to cora with the guy who has the accepted you know the top answer and it's just like man you wrote a lot for what started as a one-word answer. Yeah. So, when I interviewed Facebook a couple years ago, I was like, so, you guys still doing PHP? Just asking.

And the answer I got back from the interviewer was like, well, I mean, React, GraphQL. It's just like a long list of all the cool things they're doing. I'm like, wait, you didn't answer my question. I like how you asked that. But it would have been so much better if you said for a friend. I'm just asking. Yeah. And I don't want to sound like a hater.

I'm trying to be less of a hater of things that I don't understand because frequently it turns out i'm wrong turns out it's amazing so like i've had to retract everything i've ever said about uh bad about java and jvm i even had to get a tattoo removed recently we won't go into that but yeah actually mine is opened it wasn't java that you retracted it was kotlin it's it's what java compiles to that you're happy with now right yeah but now i'm i'm appreciating the java ecosystem a lot more and so all the things that used to frustrate me like i'm finding strength in them but but they still do create a ton of work for you to do i'm more curious about this tattoo

the one that he we said he had to get but i know he owes us a visual studio i think he's saying that he got it now it's no no i i got it and i removed yeah yeah i think that's what he's trying to say i think that the the world is still asking for joe to get that oh i texted somebody the pictures now i don't know i'm worried they've leaked. All right. So, so this is how easy you can modify a data system is closely linked to how simple it is. We all know that to be true.

We've all been there and they decided in this book, rather than calling it agile or agility, they're going to refer to it as evolvability, which I mean, I guess they wanted to be a little bit different so yeah yeah I like it and we've talked

a lot about evolvability like the whole clean architecture clean code a lot of stuff we've done is kind of focused on that so we're not going to spend too much time here or anymore let's just cap it we like all right fine then be that way all right so or, or anymore. Let's just cap it. We like, all right,

fine. Then be that way. All right. So, uh, then as he alluded to, we will have some links to, uh,

the resource and the resources we like section for this episode. And with that, we will head into Alan's favorite portion of the show. It's the tip of the week. Yeah, this really is my favorite part of the show. It's the tip of the week. Yeah, this really is my favorite part of the show, except for today. Because for some reason, I don't guess I've done anything useful in a couple weeks because I was really struggling here. And I don't know if I've used this one before or not, but I went ahead and put Fluent D in as my tip of the week. Because if you've never heard of it, it's really kind of cool.

So basically, its sole purpose in existence was to move really log data from one place to another. And it's sort of evolved into this just simple tool for moving any kind of data from one place to another. So there is a whole ton of plugins that you can get to say, hey, connect to a SQL data source or connect to a log source or connect to whatever. Like pick your flavor and then now send that somewhere else. But the cool part is, and this is what's really neat about it, and the reason why I wanted to share it as the tip of the week is, you can, let's say that you're going to send Apache logs, and you want to send them to multiple places. The cool part is you can have an input, a source, that is pointing at Apache logs,

and you can have multiple matching destinations to where you could ship that stuff to a file system. You could ship it out to the console. You could ship it to file system. You could ship it out to the console. You could ship it to a database. You could ship it to Splunk. You ship it up to AWS S3. Like you can truly have it route these things wherever you want, multiple places,

one place, whatever. And it is a really nice way of being able to move information from one spot to another. And the last reason I want to point it out is this is what Kubernetes uses behind the scenes in order to basically combine and or gather all the logs from all running pods or containers and put them into a centralized available location in a Kubernetes cluster.

And that's why you can use things like Prometheus and Grafana to then visualize all the things that are happening in your cluster. And it's truly a thing of beauty when you see it. So if you haven't heard of Fluentd, I would check it out. It's really nice. It's cool, and it's simple. It's written in Ruby, so you can go hack the heck out of it and make it do whatever you want. So pretty neat stuff.

All right. So let's talk about unit testing. So do you guys, when you unit test, what's your preference for how many asserts that you would have in your, in your code? One. One. Joe? I don't mind multiple. I'm fine with multiple.

All right. Well, just know two thirds of this podcast doesn't like you. Yeah, I know. I know. No. Okay. So. It's not my fault that I'm you. Yeah, I know. No. Okay. It's not my fault that I'm lazy. Well, sometimes you find yourself

in a situation, though, where you're like, but I think I really need two asserts here. But like, what do you do, right? I don't know how long this has existed, but apparently it's been around for at least since 2017, because that's when the documentation was last edited. But if you use in unit, for example,

you can have multiple asserts. So you could do assert dot multiple and then pass in a delegate function to where you can have multiple assert statements. And what it'll do is it'll execute all of them and verify that, you know, it'll, if, if, if you had multiple, let's say you had three asserts in without multiple dot,

uh, without assert dot multiple, then what would happen is if the first assault, um, assault, if the first assert failed, then the execution would automatically stop there. And the first error is the one the execution would automatically stop there.

And the first error is the one that would be thrown back to you. Right. And so then you're like, okay, let me refactor. And then now the second one fails. You're like, oh, if only I known I would have done both of them at the same time. And then you fix the second one and then you run it again. And then, oh, the third one breaks too. And you're like, oh my, right. Well, what assert.multiple will do is it'll

execute all of them and it'll report back the collection. So like if all three failed in that example, then you'll know all three failed. With their errors. Right. With their various errors. So if you do find yourself in a situation where you might need to assert two things, right, or more, God help you, then, you know, you have this way to do it. And like I said, I didn't know that that was a thing, and I stumbled across it, and I was like, oh, man, this is amazing. That really is nice. Yeah, it has its place.

And then I thought I'd share this because like maybe, uh, just, I never realized it. You know, I never knew, realized this was a thing. And Joe, maybe I already talked with Alan about it, so I can't, I can't question him on it, but I don't know if you've ever realized this, but it turns out that, uh, where constraints on your C sharp methods are way cooler than what I realized. So the wares will set you free, man. Those constraints add features. So just so everyone is on the same page, if you have a method that takes in a generic,

right, then on the method signature, you could have, you know, like where T colon class, for example, meaning that it has to be a type of class, right? Not a struct, not a primitive. Or you could say like where T colon new, meaning that whatever method is being passed in has to have a public constructor, right? That's my favorite one. So what I didn't realize is that, let's say you have a list, right? And you write a method that takes in a list of T and you add a constraint to it, right? Like where T colon class, meaning you don't want primitives. This method isn't going to work on a list of primitives. It's only going to work on a list of classes. What I never realized is that IntelliSense is smart enough to know that if you

have a list of integers, it won't even show you that method. Let's say it was an extension method, for example. IntelliSense will not even show you that extension method. I didn't realize that was a thing, that it was that smart to do that. And I was like, oh, this is so cool. So it's using those

constraints in your IntelliSense. Yeah, so if you have a list of, if you write an extension method for a list that where T colon class, and then you have, and later in your code, you have a list of integers, that extension method

doesn't show up in the IntelliSense when you do the dot. That is beautiful. So awesome. Visual Studio is awesome. It's amazing. Yep. That's why I would have gotten a tattoo. I wouldn't have felt bad about it.

All right. Time for my tip. And this was in reference to Luke Skywalker is not null. Although the last movie, anyway, Star Trek, forever. So, Luke Skywalker is not null. Asked us basically for a baseline for determining what a good SLO and SLAs were

for an application. And, of course, the real answer is it depends. But it kind of got me thinking, like, maybe there is some sort of baseline we can find for web applications specifically because i know we've all heard stats around like if a page takes more than x seconds then people start dropping off and we've seen some numbers around that before so i i did a little bit of googling from that angle and i found an article that somebody put together that does aggregate a bunch of user interface operations from like a user kind of focused perspective.

And it does give some basic numbers. So basically, you know, we all know UI response times should be as fast as possible. But now this web page actually gives a couple of numbers and references for that. So application launch should take less than 10 seconds. A response to any user action, like if you click a button or something, less than one second. And then that's pretty high there. But just knowing those two alone, there's a whole lot more. This starts giving you a kind of a baseline of the kinds of numbers that you can start coming up with. And it goes on to say specifically with the responsive user action,

0.2 seconds feels like instantaneous. So if you want your user to feel like they got an instantaneous response and you don't want them to tap over and over again, then 0.2 seconds is your goal for those kind of actions. Generating a report, less than 30 seconds. So this article here, this page I found, goes on with, I don't know, probably 30 different numbers that just kind of establish good baselines for normal usability.

So if you exceed these bounds, then it's going to be your users might be expecting different things based on other applications that they're using. So if you're looking for a baseline for where to start and adapt for a web application, then this is not a bad place to start. So in regards to the question that Skywalker is now asked, he was basically saying, hey, are there any tools out there to help you determine what your SLAs and SLOs should be? And so what you're saying is these numbers on this page are probably a good place to start for, you know, how you're trying to please your audience more or less.

Yeah. And it's definitely customer focused. So, you know, like in a perfect world, like you would figure out things that are like KPIs that are specific to you. So like, you know, Twitter example, like how many tweets per second, how many homepages per second, how many active users per second. Those are more kind of focused around the load parameters than the actual SLOs and SLAs. But you could kind of derive some SLOs and SLAs after that.

Like how long does it take to post a tweet? How long does it take to – or how long should it take to post a tweet? But ultimately, you do kind of have to start out with some sort of guess. But I think there's some links and some references for how they came to these numbers. So if you want to know, like, how long should it take for an alert to last on screen? Well, there's a reference here that says it should be visible in less than 10 seconds and not exceed showing for 60 seconds. So now you can start kind of using this as a template and going from there to kind of come up with some SLOs and SLAs. And by all means, adjust.

So you could start with these numbers. And if they don't make sense for you, if there's some ones you don't like or don't make sense specific to your business that might make more sense to uh to add like login time maybe is something that matters like you want the login form to take less than one second i don't know but the key is we don't still know of any tools that help you determine these slas ands, but figures like this are a good starting point to figure that stuff out. Oh, no, sure. The tool would be Excel, and you punch these in. Yeah.

Unfortunately, I'm hyper-familiar with that of late. I mean, I know tools for measuring, like things like Grafana is kind of the prime example. It's like you've got a million dashboards. You can plug in something, and understanding them is another thing. But from there, figuring like whether it's the 99th

percentile for the mean, like that's a whole another story. And I don't know any tools for that. So this is specifically for just getting those kind of initial targets to start with. Right. Cool. And that's about it. So that was it for my tip so uh just to kind of wrap things up this episode was all about maintainability from the perspective of distributed system and we talked about the ways you can increase your maintainability by increasing operated operat, operability, and reducing complexity.

Too much eggnog. And also this kind of concludes the three ways we talked about how the setup we're doing in order to kind of talk about distributed systems in the future episodes. So everything we're going to be looking at and talking about from now on, we're going to focus on these kind of three tentpoles of scalability, reliability, and maintainability. Oh, go ahead. Nope. I was just going to add, like, you get to pick two. Yeah. Actually, I think the tradeoffs are a lot more nuanced.

And we're going to be talking in future episodes about some really cool systems and some really cool ways of doing things that kind of have fun with these parameters and the tradeoffs they make and why. It's all about those tradeoffs, right? Yep. All right. Well, with that, be sure to subscribe to us on iTunes, Spotify, Stitcher, or more using your favorite podcast app in case if a friend happened to share an episode with you or point you in the direction or you're listening on their device. And, uh, as Joe mentioned earlier,

if you haven't already, if you would leave us a review, we would be forever grateful. Uh, you can find some helpful links at www.codingblocks.net slash review. Hey, and also I'm constantly surprised by the number of people that have no idea what a podcast is or how to get it.

So, you know, help a friend out, tell them what they're missing. And so while podcast is or how to get it. So, you know, help a friend out, tell them what they're missing. And so while you're up at coding blocks.net, check out our show notes, examples,

discussions, and more. And, and, and, and, and, and, and we have a latency and response time issue.

Uh, hold on. I'm sorry. Just let me try it one more time. And, and it worked earlier. Hold on. I'm trying to automate me try it one more time. It worked earlier. Hold on. I'm trying to automate the outro here. And send your feedback questions and rants to the Slack channel. And make sure to follow us on

Twitter at codingblocks or head over to codingblocks.net where you can find all our social links at the top of the... I feel like Max Headroom is on the mic right now. Do you remember Max Headroom? I do. And I believe that our system is not operating in a predictable fashion. We'll get there, though. We got there. The first step is just to automate, and we can adjust from there.

It doesn't matter. We got scalability. Yes, we're going to scale this.