Ep. #951 - SDLC: Deployment

Matt DeCoursey 00:00
And we’re back! Back for another episode of Startup Hustle. Matt DeCoursey here with Matt Watson. Hi, Matt.

Matt Watson 00:06
What’s going on, man?

Matt DeCoursey 00:08
Oh, I found out today I’m getting deployed.

Matt Watson 00:12
You’re out of here.

Matt DeCoursey 00:15
We haven’t gone about deployment. I figured that you’re probably going to tell me that you’re shipping me away somewhere.

Matt Watson 00:21
Where did Garfield always send his buddy?

Matt DeCoursey 00:26
Garfield’s owner or Odie?

Matt Watson 00:28
Odie. He always sends Odie to Abu Dhabi. I think that’s where I’m gonna send you.

Matt DeCoursey 00:32
I don’t know if I’d like it there. But I guess there’s only one way to find out. But we’re going to talk about deployment today. We’re here for episode seven in a series of eight about the software development lifecycle. Today’s episode of Startup Hustle is powered by FullScale.io. Because hiring software developers is difficult, Full Scale can help you build a software team quickly and affordably. And has the platform to help you manage that team. Visit FullScale.io to learn more. So, Matt, we’ve talked about everything we know. We started the series on eight and 18 for those of you that want to go back and start at the beginning of it. And we did an overview about the SDLC, as it is lovingly referred to. We talked about planning, defining requirements, designing, and prototyping software development, which is what we do at FullScale.io. And also testing, but Matt, what’s deployment? Has that been shipping me to Abu Dhabi?

Matt Watson 01:29
Well, deployment is, you know, nothing we always talk about. What’s the definition of done, right? And developers say, well, I wrote the code, I’m done with it. To me, done is when we shipped it when the customer got this thing, and the customer can use it. We got to actually deploy it, then it’s done, you know. And sometimes, that can be the hardest part. And the most overlooked part of it is actually deploying stuff.

Matt DeCoursey 01:58
So what happens during that stage? And, as we mentioned, some things that can go wrong, and there are quite a few here, right? This is the one-yard line. And a lot of people fumble right before they get it into the endzone.

Matt Watson 02:11
So like everything we’ve talked about in this series, depending on the type of app you have, it totally changes how you do deployments, right? Imagine if you were in Russia right now. And your air defense system cannot take out these high missiles that keep getting launched at you. We can change the software. Now we have to figure out how to deploy the software change to recognize those high missiles. How do we do it in such a way at hundreds of sites, geographically distributed all over the place, in a secure way, that we also don’t take down our air defenses while we do it? And we don’t get totally annihilated when we take all of our air defenses offline. Like, that’s where this shit gets really complicated. And it could be like, oh, a five-minute software fix is nearly impossible to deploy. Does that make any sense?

Matt DeCoursey 03:04
Yeah, sure. And, you know, I mean, some of it. So I’m gonna take the seat of the non-tech world. So people know what the fuck you’re talking about. But you have code, and it’s sitting on the left side, and now you have to move it to the right. And you have to move it to the box that’s on the right, so you’re gonna push something from the left side to the right side. Now in order to do that, you have to retain all of the healthy parts of the code that you didn’t change while successfully changing the other parts that you want to do something better, right, or, or fix or whatever the problem is, is sometimes these worlds collide. And you can have everything from overriding to new bugs to things that just didn’t really go the way that they occurred. Now, here and you know, we’re recording this in 2022, in the world of software development has created a lot of tools and stuff to handle this kind of stuff. Now, 15 years ago. This was really like a nerve-wracking situation for developers and for product owners as well because you would oftentimes, in old school ways, just be overriding what was already in there.

Matt Watson 04:24
You know, somebody says, hold my beer, I got this. And then you push code, right, like so back in the VinSolutions days, like nearly 15 years ago. Now, when we were doing that, we didn’t have any of these fancy deployment pipelines with continuous integration and continuous delivery and all the buzzwords and all the things that most developers use these days. We had an extra computer that I literally called Bob because it was Bob, the Builder. And we would check out all the code from the source code repo, we would copy it over that machine, I would log into that machine, I would build it. And then, I would literally copy and paste the files and save them to the production servers. That’s how we did deployments. And if I made any human error, there was any human error, it would all go wrong. And if for whatever reason, something got messed up in production, there was not really a great like, go back version is not really great like, we just screwed everything up. How do we revert it?

Matt DeCoursey 05:27
That’s the nerve-wracking part of that I’m talking about because untying the knot was a challenge. And yeah, now in the world of software development and entrepreneurship, everything has been learned that has created tools and best practices to handle that. Do you want to talk about what some of the common stuff is for that?

Matt Watson 05:51
Yeah, so these days, most people use some sort of CI or CD pipeline. So that’s continuous integration, continuous delivery. So it starts with continuous integration, you know, does like testing making sure all the code compiles, and all the different unit tests and all these different kinds of the testing run. And then, as long as all the testing works, which is automated testing, then it wouldn’t do the deployment part of it. So I would take the code that was in the development environment, then move it to the QA environment, and then eventually take the code that was in QA and move it to production. So you move it up levels, as everything works successfully. And that’s all really important. And honestly, I had a conversation about the same exact topic before a call today because our developers are writing some stuff for AWS lambda, and we have to figure out, okay, how do we deploy that to production and run it? We don’t want him to have access to production. So how does he like to make his code changes, and then you know, he can go click a button somewhere, and his code changes get moved to production in a safe way, and a repeatable way. Because otherwise, he has to like manually run all these weird command line functions. And then he has to log into AWS, which gives him full production access to everything, and he has to go click some buttons in there. And if he doesn’t do any of it the right way, our whole shit goes down, right. And so that’s why having these pipelines and having automation is important. It helps you move much faster and reap and in a repeatable way. So that if anything goes wrong, you also potentially can get back to the previous version and redeploy the previous version. And you’ve got automation to do all of it.
Matt DeCoursey 07:29
Which is why it happened. Sometimes you talk about having to revert back to let for purposes of this episode. We’ll say we’re on version 1.5. And we’re trying to get to version 1.6. And we go to get to 1.69. When Matt talks about the quote, production, he means your live site, your Live software, that is the part that produces whatever it is that you want it to do. And as we mentioned, in prior episodes, you will have different worlds like staging and development and these different things in places where you conduct science experiments, essentially, I mean, I think that’s a fair way to put it because you want to run tests and try things in a way that doesn’t break everything you do. Now you look at it like any software you use, right? They are all big companies. They all have these different environments and worlds and think about all right, so last night, I was trying to order on the DoorDash app, which is maybe the primary way my family survives right now. And there was something goofy with it, and I couldn’t put anything, and I couldn’t. I could select, I could select a pizza. And it would say great out of order. But there was no actual order or checkout or basket or anything. That was likely a problem with them deploying some kind of update to their actual app, that they probably, I’m willing to bet that something the size of DoorDash figured that out pretty quickly. Because there weren’t any new orders coming in. That’ll be the first red flag that a deployment went bad.

Matt Watson 09:19
So go ahead. And that’s why it’s important to have different KPIs that you monitor. Right, right. And so there’s a whole host of monitoring systems that people use, and we’ll talk more about this in our next episode when it comes to the operations of things. But when you’re doing a deployment to your exact point, it’s really important after you do the deployment to check, like, are we still getting traffic? Is it performing the same way? Are we getting more errors? Are we getting more? Are we still getting orders, like just ensuring that everything’s still working?

Matt DeCoursey 09:46
Yeah, and something like DoorDash has a high volume kind of thing. I’m sure that someone noticed pretty quickly that new orders weren’t going out. Now in your software. That might not be the case. Cuz I don’t know how many orders DoorDash does a minute, I’m willing to bet at sizable enough that they noticed the depth and the graph, right?

Matt Watson 10:06
Well, and if you did have a problem, is there an easy way for the customer to even tell you that there was a problem?

Matt DeCoursey 10:11
That was another thing. I couldn’t really do that.

Matt Watson 10:15
I mean, all you can do is go to Twitter and tweet at them and be like, hey, fix your shit.

Matt DeCoursey 10:19
Well, after trying for, like, 10 minutes, I realized there was truly a problem. And then I did successfully make an order because I went back to my old orders, and I just clicked reorder, which took me to check out, which, and my wife’s asking me, she’s like, well, what’s wrong with DoorDash? And I like building software’s heart gel.

Matt Watson 10:39
Yeah. So the problem is, as an early stage startup, for those of you who are listening that are, you know, in an earlier stage, these are the types of things like building deployment pipelines and how we set up our servers on AWS. And are we using Kubernetes? And like, all this, all these topics, you can invest massive amounts of time in them, and potentially way too much time, right. And one thing that developers do and can be very guilty of is spending a lot of time on these kinds of things, trying to over-automate things. When it’s like, hey, we just need to deploy the app and run it because we need to get some customers, we need to make money, we don’t need to build the world’s perfect server environment on AWS. Like, we don’t really give a shit about how that sausage is made. Right? Now, the good news is with Azure and AWS these days, a lot of this stuff can be very simple if they make it really easy to deploy an app. And they automatically provision the servers and do all that kind of stuff. And you can go in there and say, I need it to run on two servers, or three servers or whatever. And they just do it. And it just works. But you’re gonna have some developers like, well, I want to, I want Kubernetes on my resume. So I want to set up my own Kubernetes cluster, and I want to do all this crazy shit. And then, like six weeks go by, and none of it works still, and you still haven’t gotten your stuff deployed. And those are the kind of traps that you can run into. And you always have to balance, like, is it worth putting all that effort into verses like, what is the fastest way to get to market?

Matt DeCoursey 12:05
Well, then, you also talked about not having to over complicate a simple patch or fix. Yeah. So let’s say you deploy something, and 99.9% of everything went well. And there’s one little thing one, one goofy thing, and you know, you’re talking about the CICD stuff. Now does that? Yeah, I’ve heard it. I’ve heard the D and CICD, referred to as delivery and deployment. Is it fair to say those are the same?

Matt Watson 12:34
Um, I think there’s a technical difference there between the two of them or what the difference was?

Matt DeCoursey 12:41
Yeah. So anyway, now you talk about being able to do a quick patch and a fix. And that’s what you want to be able to set yourself up to do? Yeah, otherwise, you’re like, shit, we got 99.9% of it, right? Guests will have to fix that. That little tiny bug that matters in the next sprint. And you don’t want you also don’t want to have to engage like stop 19 New 19 people to fix that one little tiny thing. So how do you go about what’s the difference between like, well, let’s call it a major or a minor fuckup. Because the minor ones like you, if you do it right, you can go in and do a little hot, hotfix, and deploy stuff without needing to like, take the whole enchilada and shove it in the oven.

Matt Watson 13:29
Well, and that you highlight one of the most important reasons for having these deployment pipelines? If we do a deployment and we find some kind of bug, how fast can I do another deployment to fix it? You know, I can get a developer that commits the code change. And you know, he missed a comma, or whatever he did, right? And fix it. But then how do I get that change deployed? How do I get it deployed as fast as possible, so our customers stop having this issue. So my DoorDash order will go through. And having that automation is key, because potentially he commits the change. And then you log into your tools that do these pipelines, and you click one button, and boom, it kicks off the process. Now, for some people, that process still could take 10 minutes, 15 minutes, 20 minutes, but with a lot of cloud stuff these days, it could be seconds. Yeah, definitely minutes very quickly. And that’s what’s important is having the KPIs we mentioned earlier, and being able to rapidly discover that there are problems and knowing that you can rapidly deploy a fix, lets you take more risk. It lets you know, like, hey, if we find a problem, we know we can fix it very, very quickly, which is the total opposite of the days of like, well, we mail CDs to our customers, and if they have a problem, we have to mail them a new CD like we are 20 years past that error. But you can see how something like that would have been a disaster for having software problems. In this day and age. If you can move quickly. You can take more risks because you know you can fix it quickly.

Matt DeCoursey 15:00
And you know, back to the very beginning of this conversation, you know, this is a huge improvement from a decade ago or Honestly, even five years ago, you know, and these, these are, I think, if you’re talking about hiring and building a team, and you know, if you need to find an expert software developer, it doesn’t have to be difficult, especially when you get to FullScale.io, where you can build a software team quickly and affordably use the Full Scale platform to define your technical needs, and then see what available developers, testers and leaders are ready to join your team. FullScale.io. Now, Matt, we’re talking about hiring developers. When you’re doing that, you want to find people that have an understanding of these versioning tools, and you know, everything. How do I move it from here to here? And, you know, one of the things we started doing with the developers at Full Scale is regardless of their level of experience, we have a very, very informative, but still, you know, shortly effective training program that just teaches people because, you know, these things change, I think the one thing that will drive your team, and I’m talking I mean, you use the word team, and a very universal method, your sales team, your support team, your development team, your testing team and your ownership team. One thing that will drive them crazy deployment. Because it’s chaotic. It’s frustrating, it’s bad for your users. Overall, it is a very crazy thing. So we talked about KPIs or key performance indicators. What are some of the ones that would pop out? If you like, what are some common ones that could pop out if you had a bad deployment?

Matt Watson 16:48
So the most important things are going to be like the volume of traffic, right? Like, if I’m Netflix, and I expect, you know, a million people will be streaming after I do a deployment, I still expect it to be, you know, a million or whatever, right? Like, is the amount of traffic the same or all of a sudden, did it go like way down? Then it’s like something must be wrong, because it’s way down, right? And then you’ve got the performance of that. So are the transactions fast? Or are they slow? If you have the right kind of application monitoring tools in place, you can know how fast those transactions are happening. So you mentioned earlier, like adding something to your shopping cart on DoorDash or something right? Like, is it taking one minute or one second? Or is it all of a sudden taking 30 seconds, right? And then you’ve got errors, tracking error rates. So those are kind of the most fundamental things like the volume of traffic, the speed of it, and error rates. Those are like where you would start the basics.

Matt DeCoursey 17:40
Sounds like that would be a good idea to have a deployment checklist.

Matt Watson 17:45
Absolutely. Yep.

Matt DeCoursey 17:47
Let’s talk about that. Now, what, as you’ve mentioned, what are some other things that might be on that checklist?

Matt Watson 17:53
Well, so you’re gonna have. So one thing we haven’t talked about, that we should mention real fast, is that all of this kind of falls into the DevOps category. So that’s a newer kind of buzzword over the last 510 years is having a change or the way a super frickin broad.

Matt DeCoursey 18:08
That’s like saying, I don’t use software.

Matt Watson 18:12
Yeah, yeah, so DevOps, people generally help with anything to do with the deployment side of things. Like at my company, we’ve got somebody that’s been spent the last six weeks, you know, working on how we do deployments, AWS, and trying to automate these pipelines, like we’re talking about improving them. And, you know, that’s, that’s what he’s doing. He’s figuring, okay, how do I script all this stuff? How do I push stuff to AWS? How do I ensure that all the settings in AWS are the right way? None of it has anything to do with writing code, it has to do with deployment has to do with getting the environment all set up the right way. And so all this DevOps stuff is a lot of work. And there are people that enjoy doing that kind of stuff. And then a lot of people that don’t, and people that don’t, yeah, so yeah, so when you talk about doing a deployment, you can absolutely have what I would call sort of like a DevOps checklist, which is gonna be a bunch of different things around testing and making sure that, you know, you have the the SQL database changes that need to be deployed, have been deployed, other dependencies have been done. Have you told everybody about the work? Or about the deployment? Have you trained everybody that needs to know about the deployment? All these sorts of things that need to happen, right? You know, QA, review everything etc, right? Did the CEO sign off on the fact that we’re going to do the deployment on Thursday at whatever time like all that kind of a lot of communication stuff that needs to be done, make sure everybody’s in lockstep on the fact that we’re going to do this deployment? And what could go wrong? And what new, new functionality we’re delivering, like everybody understands what’s happening, right? And then post deployment. Yeah, then you’ve got a whole phase of testing. How do we ensure that the code that we released works so well? Talk about some of the measurement stuff like the KPIs we can use. But then you have like your QA team, your product owner, some of the support team, whatever, you know, logging into the system, making sure it’s still working and everything seems hunky dory. You know, in the old days, you know, 1015 years ago didn’t have those systems. And basically, we would push code at nine o’clock at night and pray that we didn’t get a bunch of phone calls the next morning, like that was our feedback loop. And we’re, there’s so many more tools and technologies today that hopefully you have a lot less of that, you’re still going to have some of that if you push code at 9pm, you have no users, and you have no traffic depending on your type of product. And you have to wait until a bunch of users sign in the next morning. So you’re going to inevitably have some that happens. But the tools and the things that exist today help a lot.

Matt DeCoursey 20:49
So you mentioned talking to the CEO, and so I have a no deployment Friday roll. Like we don’t deploy big things on Friday afternoon.

Matt Watson 21:00
Why not? Yeah, okay.

Matt DeCoursey 21:01
Yeah, cuz it’s like, it’s the worst day to do it. Because what could go wrong, if you mess it up, you’re gonna work over the weekend, too, if you don’t realize you mess it up, then it’s going to be broken the whole weekend. And three, if you do it on Monday, Tuesday or Wednesday, you have a couple of days to fix it, if something comes up. It’s just like, you, like you mentioned that like, kind of like the push and pray mentality. That’s not That’s not a 2022 recommended best practice. But, you know, like, like Matt said, make these things known. And make sure you have the right people around, it’s real easy to test a platform when you have all hands on deck. And there are like, your testers might test different things then like, I don’t know, we tried to tell everyone, you know, like, Hey, we’re doing if there’s a major, like, we’re gonna do a major update on the Full Scale platform this week, and I’ll have a whole lot of people from different departments test it, because there’s too much stuff to test for just regular QA, you can break that into pieces. And, also, it’s like, who uses what it’s very difficult, sometimes to really have a strong grasp on who is using what parts of your platform and how and, and not broken for one person might be horrendously broken for someone else. Alright, so we want you to use the deployment checklist. We talked about the right deployment tools, and continuous integration stuff. You know, not one thing, we didn’t talk about automation, I think everyone’s obsessed with automation. But I want to point out that if you don’t know how to do it manually, it’s kind of difficult to know if the automation is going to do it. Right. Unless it’s like a truly turnkey kind of thing. That’s just like, hey, I do this every time you don’t even need it well.

Matt Watson 22:47
And so that’s the other huge benefit to setting up the automation right now, if you’re like, oh, Patrick’s the only one that knows how to deploy this. That’s a problem. Yes, because nobody else can do it. And if Patrick wins the lottery, well, what are we going to do? Right?

Matt DeCoursey 23:05
So is that the bus rule, if that person gets hit by a bus, or jumps on one and drives away forever?

Matt Watson 23:11
Yeah, where are you? So by setting up that automation helps a lot, because then you have multiple people that can go in and do the deployment. Plus, you’ve you’ve got like all the configuration and stuff in a system and a place where you would put it, instead of it just being like this random set of steps that only one person knows how to do on their laptop, and like how to like, have all that set up the right way, with the right VPN access, or like all this weird things, you might need to do the deployment. By setting it up in a tool that’s designed to do it, it’s like you have one central point, and it’s in the place where it goes. And it makes it a lot easier if you need to make changes to it, or that person leads or any of that, that it’s all set up in a way that logically makes sense.

Matt DeCoursey 23:56
And people can can modify, you know, in some of this stuff, like if you’re really if you have a pretty basic platform, and you’re pretty early you might not need I mean, it’s good to start getting an idea of how you’re going to do stuff later. But much like Matt alluded to earlier, you can make things remarkably complex when they don’t need to be well, so for example, reinvent the wheel.

Matt Watson 24:16
For example, if you’re using Visual Studio, and you’re developing dot net based applications and deploying them to Azure, it can be as simple as literally opening Visual Studio, right-clicking on the project and hitting publish, and it will publish it right to Azure. And that’s it. Now, you don’t have, again, that sort of only doing it from, you know, Patrick’s machine, because only Patrick knows how to download the code and do that. And it’s built from his machine. But if you’re starting out, it can be that simple. You can make it more complicated later. You can set up a build machine that does all of that and everything. But it can be that simple to deploy something to the cloud.

Matt DeCoursey 24:53
Yeah, I agree. And you know, all right, so next on the list. We talked about monitoring KPIs, this is the key ingredient. And you know, if you don’t have, if you haven’t set up, like, if you don’t understand basic key performance indicators, then you need to, cuz this is how you’re going to this is the most likely Well, other than testing it yourself and realizing that it’s bad. These are the things that can really pop out. We talked about everything from logged in user’s time transaction times to page loads. I want to throw another one in there. Keep an eye on things like database load. Yeah. And like server capacity, because sometimes you can make a change and something just starts spinning out of control or doing something, it’s making your server or your database work way too hard or do something, there’s just something funky in there. And what happens is that it can slow down everything. And in some cases, didn’t just show your site.

Matt Watson 25:58
Well, that brings up another kind of topic of this, right? If you do a deployment, and things don’t go well like there’s some kind of problem, the number one thing you have to look for is what changed, what have you changed, you know, and that’s why it’s important to have source control and all that because you can go back to the source control and say, Okay, what code commits were in there, who did the code commits, and all that. But the other thing that’s important when it comes to deployment is trying to do deployments more often with smaller amounts of change. When you ship like 100 new things, chances are a lot higher that one of them won’t work. But then it becomes really complicated to figure out, well, what of the 100 caused the issue? Like we’ve changed so many things that I just don’t know where to start? Where’s the needle in the haystack, right? Where if you just do deployment on a weekly basis, and some people do deployments even on a daily basis, then it makes it a lot easier, as everything worked perfectly yesterday, we made this one change, and it has to be part of this one change. But when you bundle a whole bunch of changes together, it makes it so much harder to figure that out.

Matt DeCoursey 27:01
And while we do wish you a happy deployment, you got to know that things don’t always go. Right. And I mean, that’s part of all of it. And that’s why the very last item, and we mentioned this earlier, is a rollback strategy. Yeah. So how does that work, Matt? Like, I mean, how do we keep that sample so understood?

Matt Watson 27:27
So depending on the pipeline you’re using, you know, so the good thing is, most developers these days deploy everything with Docker containers. So containers, and containerization, have made it a way to basically compile and build all of your code into an asset that you can then deploy to production. Well, the good news is most of these tools make it easier to get like previous versions of that asset and then redeploy it. So you can roll back the versions. Or you could go back and source code and say, Look, I got to pull this different branch or tag and source code, rebuild it again, and redeploy it. But what a lot of companies do when they get really sophisticated is what you would call a blue-green deployment. So they’ll have like the blue deployment on, you know, half the servers, and then they deploy code to the green servers, like the other half of the servers. And then they have to basically run everything in parallel, and then eventually switch. And then if there’s anything wrong, they can immediately go right back to the blue, right, like, like, they flip back and forth between two different deployments. And big sophisticated companies have to do it that way. And at my last company, we’d have an app that ran on 50 servers. And so you can’t just take all 50 down, right, and then turn on 50 new ones. You have to actually do a rolling deployment. So it’s like you take one server down, and switch it to the new code and put it in, and then take another one down, and then put the new one in. So when you get big, you get all sorts of problems and all sorts of complexities. I mean, imagine something like Visa or MasterCard deploying code, right, and not messing up credit card processing. These sorts of things are like big company problems, but they do exist. If you’re a small company, you do not have to worry about these things. You can keep it really simple.

Matt DeCoursey 29:13
Yeah, and that’s, you know, that’s not reinventing the wheel part. If you need to hire software engineers, testers, and true leaders. Let Full Scale help. We have the people on the platform to help you build and manage a team of experts. When you visit FullScale.io. All you need to do is answer a few questions, then let our platform match you up with our fully vetted, highly experienced team of software engineers, testers, and leaders at Full Scale. We specialize in building long-term teams that work only for you to learn more at FullScale.io Well, you know, man, I think we deployed this episode without major errors or bugs. I went through our deployment checklists, and you know, we’re now 30 minutes long, which is kind of our brand standard for a minimum time. As far as KPIs go, I’m gonna have to keep an eye out to see how many people listen to the show. And there you go. I’m not expecting you to talk about reasonable expectations. I do not expect the software deployment episode to perform at the same time, the same kind of performance as something like me who loves this stuff. What do you know, I know. But then there’s a lot of people that don’t, because they aren’t going to know what we’re talking about. And that’s the way it goes. Matt, do you have anything else you want to add? And on the way out of here, before we say this code is fully pushed to the production environment, and in a healthy and safe way.

Matt Watson 30:40
I would say everybody needs some sort of deployment pipeline. These days, it’s not hard to set up, keep it simple, deploy to AWS or Azure, or whatever. Just don’t overcomplicate it, but everybody needs one. Because then, you know, everybody can push code, and you don’t have the one guy or gal that knows how to do it. And it’s important to spend a little bit of time on it. And it takes time. It does take time to set up.

Matt DeCoursey 31:02
Yeah, and I agree, and you look at, I mean, I think that like I said, we wish you all a Happy deployment. I think a good way to keep customers, users, employees, yourself, and everyone happy is to get really good at this part. Because it is true, it’s truly the one-yard line. And there’s nothing more disappointing than when you turn over the ball, throw an interception, fumble or give it over on downs and then mess up the field goal. I mean, these are the sports way. That is a sports version of a crap deployment. Would you agree?

Matt Watson 31:37
Yep, absolutely.

Matt DeCoursey 31:39
All right, man. I’ll see you. We got one more of these one more episodes. It’ll be next week, man. I’ll catch up with you sometime between now and then.

Matt Watson 31:47
I can’t wait. See you then.