Ep. #920 - Software Development Lifecycle Overview

Matt DeCoursey 00:01
And we’re 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, just ready to do another series with you. It’s been about.

Matt Watson 00:13
Well, the last series was bullshit. That’s what we figured out.

Matt DeCoursey 00:16
Well, yeah, legit or bullshit.

Matt Watson 00:18
It was an NFT. Bullshit NFT series. That’s right. It was the final verdict.

Matt DeCoursey 00:23
It was. It was bullshit. And I think that really played out. Look at the NFT market.

Matt Watson 00:28
Now, you got somebody like Tom Brady who spent $400,000 on a Bored Ape and now wonders why because it’s now worth like 100,000 or something.

Matt DeCoursey 00:35
I think now I think Apes did okay because they paid dividends. Anyway, we’re here to talk about the software development lifecycle. Which is a topic you and I are both familiar with as the owners and founders of Full Scale. And, you know, if you’re looking to build a development team, you should know that today’s episode of Startup Hustle is powered by FullScale.io. Because hiring developers is difficult and 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, now, software founders and entrepreneurs, as well as purveyors of software talent, are in tune with the software development lifecycle. And, you know what, we’re going to do an overview of that today. So there are large, well, the software development lifecycle can be a little different for some people. Because some people embrace this order in this process, some people don’t. We have a recommended sequence of events that will follow in seven episodes. But we’re going to do an overview on the whole thing. So now, when you think about the SDLC, as it is commonly referred to, what comes to mind?

Matt Watson 01:51
You know, a lot of times, it’s all the shit you’re supposed to do. But you just don’t like getting requirements and testing and planning. And like all the things, you know, as developers, I feel like a lot of times, we just grab the hammer and start hammering on shit. And we don’t spend enough time and planning and a lot of the things that we need to do. But I think that’s inevitable, right? We just start writing code and not spending more time doing requirements and all the other things.

Matt DeCoursey 02:21
I think that is commonplace in a lot of businesses. You know, because we’ve talked a lot over the past. Dude, this is almost the 950th episode of Startup Hustle.

Matt Watson 02:32
How about the dam?

Matt DeCoursey 02:34
We definitely didn’t have a framework for planning that for almost five minutes.

Matt Watson 02:38
For the stadium tour, when we get to 1000.

Matt DeCoursey 02:41
I know. Yeah, we got to talk to you about proper prior planning. We got to figure out who’s going to be the super guest for episode 1000. Because I feel like we need one. Now, as you mentioned, there is a recommended sequence in order of operations for the software development lifecycle. But it often doesn’t come that way, though. Because, you know, a lot of people that end up having a software platform have started it not for purposes of commercial viability. And maybe, to solve an internal problem, as you mentioned, you write some code. You do this. You do that. It kind of turns into something. And I think another reason that a lot of people don’t embrace the process is they don’t know it exists.

Matt Watson 03:28
Well, and in a lot of ways, these kinds of processes force you to slow down. But sometimes slowing down is what you need to do to actually speed up, right? Like, I always liken software development to building a house, right? It’s like if you don’t have blueprints if you don’t have an interior designer, and a good architect, a good general contractor, like if you don’t have those people, hiring a bunch of people to like carpenters and stuff are of no value in software development the same way you can hire lots of programmers, lots of software developers, but if you don’t have a really good product, people that understand what the product is supposed to do, and how it’s supposed to work. You don’t have good software architects that can figure out how to do this, you know, make things, so they scale and perform well and do all the things. You don’t have people to test it, you know, train people how to use the product. Well, all these little details are super important. It’s not just about writing code. There’s much more to it than doing it the right way, just like building a house.

Matt DeCoursey 04:25
Yeah, it’s like, like you mentioned, with building a house, you know, the contractor doesn’t show up. And it’s like, hey, what do you want? Well, I’d like to build a house. Okay, we’ll get that taken care of, you know, designing it before. Yeah. Well, and without those plans, and without knowing what you need, it’s also impossible to estimate. Yeah, how much it might cost, how long it might take, what kind of workforce you need, what kind of permits and planning, so let’s Well, let’s first go through as I mentioned, there are seven steps that are, we’re going to say commonly known as I’m just going to whiz through those. And we’ll come back and touch on it. And we’re going to do a separate episode on each one of these. And so look for that. And just like I said, we’re not going to try to there’s too much of this to get into to do in one episode. So as far as the actual steps go, it starts with planning. And then defining requirements, design and prototyping, actual software development, testing, deployment, and then operations and maintenance. And in many cases, these steps are cyclical, and they’re going to just kind of start over and over and over as you add on or build pieces or other stuff that goes with it. And we put that last step in there as operations and maintenance. You know, I think one thing that, you know, for those of you listening, we did a 52-part series on how to start a tech company. And one of the things you know, when I look at operations and maintenance, so many people call Full Scale, and they want to build a development team, and their goal is to build a software platform that people subscribe to. But they ask questions like, when will it be done? And how much and like, when’s it finished? And the answer is never.

Matt Watson 06:10
Because, yeah, one of my favorite quotes was from the social network movie, and I don’t know if Zuckerberg ever said this, but like, there, there’s software’s like fashion, there is no final version. And I don’t know if Zuckerberg really said that in real life, but it was in the movie. And I just always loved that quote because it’s, it’s true about software. There is no final version. And it’s like for those of us who use Gmail for like, five years, and it said beta for like, five years, and then finally, the beta tag off, right? Like, all software is forever changing, you know, look at something like Microsoft Office. I mean, it’s been able to edit documents for like 20 years or whatever. But they still keep making new versions of the damn thing. Because Oh, we have to support the iPad. Now. Now they have like an iPad version, or now they have a web version, it runs in the web browser, and it just continues to change. There is no final version of any of this stuff.

Matt DeCoursey 06:59
Yeah. And if you can’t operate and maintain what you’ve built, and you know, people out, I’ve had people say, Well, if it’s built well, it shouldn’t break, you can build software really well. And it’ll still break because things occur outside of your ability to control it that makes it break, like changes in the Chrome browser, or, you know, Amazon changing something in their server or something like that, that inherently just causes your ship to break. And you have very little to say about it.

Matt Watson 07:28
Here’s an even bigger problem. An even better example. Almost every one of us in our house sometimes doesn’t have electronic devices, right? Think of cameras, you know, cameras, computers, routers, cell phones, Wi-Fi, all these different equipment. How many of those have had their firmware upgraded in the last so many years? How many of them have huge security problems that could be hacked into? Right? Like you hear weird stories about people hacking into people’s security cameras and like getting fed. So like, you can hack into mine and look, my friend, I don’t care. But there are, you know, security vulnerabilities, a huge one that you have to upkeep the software over time. That’s a huge, huge problem. Security.

Matt DeCoursey 08:10
Yeah. Well, so let’s talk for a second about why structure is important when it comes to software development. And why is following a process a key ingredient?

Matt Watson 08:22
I think it’s all about efficiency, right? Like, you know, I manage a software development team every day. And if I don’t give the team, you know, detailed directions and work of what needs to be done, then they just don’t know what to do. Right? They wake up every day, and they don’t know what to work on. Right. So if I don’t give them the requirements, the planning, you know, this is what the product is supposed to do. This is why we’re doing it. You know, here’s a screenshot. This is, you know, the functionality, all that kind of stuff. If I don’t give them those details, they don’t know what to do. And so, if you want to move more efficiently, the more details and direction you can give them, the faster you’ll go.

Matt DeCoursey 09:01
I think you can think of it as well if you’re going to have a team and you look at something like the military, right, and their structure and priority and understanding of what needs to be done, who needs to be doing it, who’s making certain decisions. That doesn’t always mean that the person that’s in charge makes the best decisions, but someone needs to make a lot of decisions, especially when you’re building something from scratch. So what are we going to build first? What do we need to do first? What do we know? It’s like you don’t build a house and the first thing you do is paint the kitchen. There isn’t even a kitchen. So you know, I think when it comes to an understanding, I often compare software developers to carpenters in the regard that they operate, that is when they have a plan when they understand like this is supposed to be 12 feet long and eight feet high. And the boards are 16 inches apart and stuff like that. And that may end when you have an understanding of some certain, you know, product requirements, and you know, even look at things like the appearance of it. So you’ll have brand standards. And you’d be shocked at how much you can slow yourself down or end up with like a really wonky product that has buttons that are eight different colors and stuff like that. So some of its just simple things, it’s like, you know, we’re going to use this color code of green, we’re going to use these kinds of buttons, we’re going to use this, we’re going to use that here’s the toolkit. And now, let’s get moving. Now, one of the things that I think is important, as much like we’ve talked about with business plans, as you’re going to discover when you’re building software or any kind of product like this, you’re gonna get any, depending on who you are, it’s different every time you’re gonna get somewhere down the timeline. And you’re going to realize something big that you hadn’t considered, that you didn’t think about. Or you’re going to get some type of user feedback that’s going to need some kind of agile move or pivot. So I think when it comes to the SDLC, it’s important to know that like it, it’s going to change a little bit along the way as well because that’s just kind of the nature of making things better.

Matt Watson 11:11
Well, the hard part, as well as in the early stages of an early startup, or an early project you’re working on, a lot of times, you’re just trying to make things work, right? And so, you know, one of the challenges I have, you know, at my company today is like, hey, this thing works. But now that we have, like 200 customers that use it, it doesn’t perform well, it doesn’t scale well, like, you know, after synchronizing data from Google, and it takes 10 minutes to do the synchronization. But I got to do it 200 times, like, we have to design this in a different way. Right. And so that’s where some planning upfront comes in so someone who’s really good at software architecture can see ahead and like, hey, if we’re successful, it’s going to be important that we design this in a different way. But the challenge is, if it takes a lot longer to develop it, it’s like, you may never ship the product, and you may never get it released because you spent all this time trying to over architect it. So that’s always the challenge with design and scale. And if you think about building a house, it can be the same thing. Oh, we’re gonna build this platform here. And like just building a platform is no big deal. We just built it. But then you realize later, like, oh, like 1000 people have to stand on this thing. And it needs to support like 1000s of pounds of weight. It’s like, Oh, we didn’t know that. And so they’re there. There are always architectural decisions that are a struggle. And a lot of times, those are always the battle for companies and developers is like, how much do we over architect things? Versus Do we just make this shit work? And get it done? And there is no right answer. It’s always difficult. One of my favorite things, though, about software planning and design is telling the developers what not to do. And I feel like that’s one of the most important things. And if we liken it to building a house, it’s like I’m remodeling my kitchen. And the general contractor forgot to tell the painter that we’re going to tile the wall. So they paint the wall, it’s like we wasted our time painting the damn wall, we’re gonna tile that, right? And software development is the same way. Like a lot of times, you have to tell developers like we’re not going to do this, this and this, don’t waste your time on this, this and this. And that’s one of the biggest things that is always overlooked is telling them what not to do.

Matt DeCoursey 13:19
Yeah, I think, to just kind of add on to that, you know, so many, so many platforms are data-centric. And for example, it’s like deciding on a centralized database structure. So you don’t end up with nine different places where the info is kept. Yeah, and then what happens there is when you have such a big buzzword. Is the term scalable? Well, what I mentioned, where you have data in nine different places means that it might not match or you end up with, like, heavy server stuff, because like you mentioned, like, this doesn’t work for 200 people, but it worked for five, yeah, because it five people that might have been searching an entire database. So you can think of it that for those of you listening that might not be technical, you can think of a database as an Excel sheet. Well, if it’s like 900 columns wide, and you know, 10,000 tall, and you just need to find one thing in one column, but your coding in the way, the way you’ve set it up searches the entire database table, that might actually work when there are five people in there. But when 200 People get in there, it might just overwhelm your server. And these are like simple architecture, things that, you know, and I think it’s normal to expect to have to tune some of that stuff up along the way. And that’s why having some expert people is helpful. Now, you know, finding experts and software developers doesn’t have to be difficult, especially when you visit 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. Go to FullScale.io to learn more. And you know, Matt, that’s we could talk about that for a second. You know, a Full Scale we? Well, we had a, we were coming up on 100 employees and realized that there’s no out-of-the-box product, there’s nothing that we could buy that would really help us manage and run and, and keep our operations efficient. So we had to build, we built our own platform at Full Scale. But we did that after the company was already well, Andre, and right, and some of that has, you talked about this really agile approach? Well, it needed to be able to be used by our employees, by our clients. And then prospective clients, as well as our admin and by nature, were a remote team, well, we were in an office, and then the pandemic made us not in an office. And that’s, you know, so the requirements for what your software might need to do can change dramatically over time. And then also the resources that are available. As you mentioned, the SL, and the SDLC, are different for different people. If you’re a bootstrap startup just trying to get an MVP built, you just need to make sure that shit works.

Matt Watson 16:07
Right? To some degree, some of these problems don’t happen until you get to some degree of success, right? I mean, some of them are fun or fatal mistakes. It’s like, oh, the type of technology we used didn’t work, or we over-engineered something, we never got the product shipped, you know, those are fatal mistakes that just can completely kill you. But then there are other things like the examples out of my company, it’s like, hey, it was fine. Yeah, didn’t perform very well. But it still works, we’re able to make it work, we kind of band-aid it together, nobody knows it’s a problem, or customers don’t know it’s a problem. And we can fix it later. Like, inevitably, there’s always a lot of those things. And you’re just never going to know what they were like when Facebook launched. They didn’t know they were going to have a billion users eventually. And you can’t plan for that. And you just have no idea. And the things that could be a problem, there’s no way you can even foresee some of them, right until you get there. So it’s just an inevitable thing for some of it. I’ve just always fixing shit.

Matt DeCoursey 17:02
So how do you go about preparing for the SDLC? Like, where do you start, just sit down and talk about like, you know, this is the planning phase. Obviously, we’re gonna get into that in the next episode. But when you talk about the whole entire process, like do you take it one step at a time? Or do you get all the way? Obviously, you can’t get to the seventh step and operations and maintenance right away, but you could still put, you could still give some projection or idea of what you might need.

Matt Watson 17:32
I would say anybody who creates software does all of these things to some degree. Whether or not they do them very good or very bad, they’re all over the place. Right? They basically have to do all of these steps to complete the work. But usually, they’re really good at, say, three or four of them. And you know, one or two, they’re average, and one or two they’re really bad at it would be my guess. And every team is going to be different. So, for example, you talked about, from the operations perspective, there may be some products out there where they’re really good at operations. So think about we’re in Kansas City, and most people don’t know this, but there are nuclear missile silos all over the Midwest, dating back to World War II. The same software that runs those today ran them 50 years ago. They’re very much in operations mode. And none of these other steps are happening at all, right? So there’s other software out there that’s like an ATM or whatever it is. It’s like it’s been around forever. There’s not any planning, designing new development, testing deployments, not doing any of that. They’re only doing operations. And then there is software like that. But most software these days, as we said, there’s no final version. And they’re always kind of, you know, evolving through these steps. But some companies are really good at certain pieces. And some companies are just really bad at all. And it’s really impossible to be perfect at all of them.

Matt DeCoursey 18:54
I think you look, and you need to look at what you want to build and determine like two or three most important key ingredients of that. And work on getting those pluses, like make your plan around that I think too many people are trying to build they’re trying to be good at 15 things before they’re good at a couple, and you can really water down your timeline and your resources and just basically run out of them. So like, you look at something like Giga buck, and it’s like okay, it should be able to take an appointment. Like if it doesn’t do that, then that’s like the key ingredients, a booking site. So you should be able to make an appointment, and if you can’t get good at that, then you have no business building something else. It’s like the same thing you use Microsoft Word. For example, if you can’t save your document, that’s a big deal. You know, so you know, these are some of the things that you need to look out for first, but I think you need to try to figure out the pillars of what you’re building and get really good at that because the same way you build a house you put it on a farm foundation. And if the foundation crumbles, the rest of the house is gonna go with it.

Matt Watson 20:05
Well, another good example of this is, for example, here you have like, say, steps like planning and testing. Maybe those steps are not important at all if it’s just an application that’s used internally, like, for example, rocks like we didn’t use to have that customer facing. We only use it internally. So if there’s some kind of issue with it, we can just deal with it, or employees can just deal with it, and we’ll fix it. Now. However, if we’re building software that flies airplanes, testing is pretty damn important because we don’t want the plane to fall out of the sky. Right? So the type of software that you build can also change the importance of some of these things like deployment. Deployment seems like a simple one. But imagine you’re building software that controls missile air defense, and you need to deploy software from missile air defense all over Ukraine or Russia right now or something. Can you imagine the logistics of deploying that software? So different kinds of software have dramatically different circumstances in problems like deploying software, like on-site somewhere like that is dramatically different than having a web application how you deploy or a mobile application? It depends on the type of software.

Matt DeCoursey 21:11
When you talk about deployment and testing. Just recently, there was a crypto platform that got like $200 million worth of crypto stolen from it because they pushed an update. Yeah, that had a software issue in it. And you could literally just take a little snippet of code and just replace that one part of it and just pull money right out of it. And, and that’s an example, where I was testing the issue right there.

Matt Watson 21:37
Testing is more important than anything when it comes to blockchain stuff because of any mistake, and yet people can hack it.

Matt DeCoursey 21:44
So in service of people that do this stuff, there you go, that’s scientific as hell right there. Project management fails most often because there aren’t clear goals. And I think that’s a big thing with what you’re trying to do here, like, first off, define what the goal is. We are trying to build a platform that does this. And does this and does this. And our goal is to be through certain parts of the cycle or certain timelines. And you know, like, Matt, you always say people just want to know, are we ahead or behind?

Matt Watson 22:18
Yes, and what you just mentioned here is that clear goals aren’t necessarily an engineering problem. It’s a product problem, right? It’s like, what do we want the product to be? You know, who, you know, who is our target customer? What are the features of the product? You know, all that kind of stuff, right? The engineers don’t necessarily care, like, just tell us what you want it to do, we’ll do it. But the goals part of it, one of the companies I previously worked at, this was a dramatic problem. Because just from a product perspective, like the owners, the owners of the company could not figure out what we wanted the product to do. Like, who are our competitors? Like, what is clearly what we’re trying to do, and it just freezes the whole company, freezes the engineering team, like an engineering team can’t do anything. Like they don’t know what they want to do. Like, that is the most fatal mistake. From an engineering perspective. It’s just not having goals, like not even knowing what you’re trying to do or accomplish.

Matt DeCoursey 23:13
Yeah, I feel like these goals also need to be fluid. Cuz, you know, I see a lot of nontechnical people trying to set technical goals. And it’s difficult to have an understanding of how quickly certain things are going to be done. And I want to say from a leadership perspective, you call yourself a founder, you’re often going to be like, we need to get this done in two months, but it’s six months’ worth of work. And, you know, the, I mean, Warren Buffett says, nine women don’t have a baby in a month. So you know, there are certain parts of building software, just because you have more people doesn’t mean it’s gonna go faster. In fact, more people often slow things down. So yeah, one of the things in the very beginning phase of a lot of this, I mean, unless you have a high level of expertise, and you have a high level of understanding of the people on your team and what they’re capable of, and how quickly they work. Timelines are going to be very difficult to establish. I mean, they’re hopeful at best when you get to start something brand new.

Matt Watson 24:14
Well, you mentioned goals, and the big thing there is the constant changing of goals. That’s the thing that’s a huge killer is like, Oh, this is the most important thing, and the next week and some other thing, it’s like we never get anything accomplished. Like that is the super killer to software development teams.

Matt DeCoursey 24:30
You’ll get that feedback from a lot of employees at a lot of places that it’s a constant moving target. And now, if you work at a startup, that’s kind of the way it goes on a lot of days. And you know, a lot of times you have to kind of that’s if you talk about you know you’re working on a plan for this for Plan B, or Plan A is wrapping up, but you often find yourself having to pull everything away from Plan B to go do something to plan a, and that’s going to mess with your timelines. It’s going to end, and it confuses people. Pull. There are a lot of people that just want to show up and do what they need. They want to know what they need to do and not have to constantly be changing. People don’t handle change. Well. Yep. All right. So as mentioned, this is our overview of the software development lifecycle. We’re going to do an additional episode about planning, defining requirements, designing, and prototyping the software development in general testing, deployment and operations, and maintenance. And that’s going to make a map that’s going to do you think this is going to be it? So in true fashion, when we did our 52-part series about how to start a tech company, we delivered that two months late.

Matt Watson 25:41
That was on time.

Matt DeCoursey 25:43
I felt. Yeah, you know, we’ve often said that it’s going to take twice as long and maybe cost three times as much. So I look at that we were 10 months, nearly 20% over budget. That’s pretty good. Yeah. And that’s another thing too, I think that’s, you know, one of the things that are not in here is budgeting.

Matt Watson 26:01
Yeah, estimation is like estimating how long it will take to do something. And impossible, it is nearly impossible. And even as a development. So you know, I manage a development team. And sitting here today, it’s really difficult to, even now, estimate things. And part of that is, is it really hard to estimate velocity, like how much work do we get done in a week? Like how do you scientifically measure that? And then when you’re doing planning, somehow measure the planning and know how it’s going to align to how fast you do work, like calculating capacity and velocity are? Yeah, like mythical creatures when it comes to managing a development team. It’s very low.

Matt DeCoursey 26:46
That’s why getting people that know what they’re doing matters. And you know, if you need to hire software engineers, testers, or leaders, Full Scale can help. We have the people and the platform to help you build and manage a team of experts, including product managers, software development managers, and people that are not just coders. Although that is what most of our employees do. When you visit FullScale.io, all you need to do is answer a few questions. And let our platform match you up with our fully vetted, highly experienced team of software engineers, testers, or leaders at Full Scale. We specialize in building long-term teams that work only for you. Learn more when you visit FullScale.io. And, yeah, so almost 300 people work diligently for the success of our clients. Now, it’s a lot of people, it’s a lot of software.

Matt Watson 27:30
Pretty amazing. They get to work on some really cool things. That’s what always impresses me the most is what they work on. And, and honestly, that’s one of my favorite things about software, is just all the different kinds of projects that exist and all the different things you get to work on. And that’s why Estela and the SDLC are so dramatically different from one company to another, right? So, like, at Full Scale, we have a company that like flies, drones, and needs to loan, land drones in the middle of a field somewhere because it tracks like crop growth or something, right, like how the SDLC of that software is dramatically different from some like mobile app versus enterprise software, or whatever, it’s just all so different. That’s part of what makes it fun.

Matt DeCoursey 28:10
Well, where we see the SDLC, really flexed and used is with the bigger box, people that we work with meaning like they have big teams, and there is no other way to plan large scale projects. And then you know, a lot of people or a lot of companies are trying to deliver a final product to their client. And with that, they need to get, you know, so they’re going in and like, you know, we have clients that are doing this or like whether it’s a feature that they’re trying to add or something they’re trying to build or deliver, they really have to lean into the SDLC. And just and really, and really kind of get an idea about, and you know, they will be the first people to tell you that there is nothing exact about the timeline, timelines are impossible, they are really, really difficult. And, you know, also you talk about velocity, it’s like, you know, you can it’s, well how many tickets were completed, that doesn’t really matter, because service work tickets could be like, fix this button. And the next one could be billed six different things that this button does and that those aren’t equal tasks in most cases.

Matt Watson 29:18
And what is more common is that fixing the button seems like a simple thing. Seems trivial. But then it turns into like a three-week project because of some nuanced problem. And nobody can figure out how to do it. And I’ve spent, you know, 40 hours on StackOverflow trying to find the random dude who had this problem before. Like that is the life of a software developer trying to fix needles in a haystack sometimes, and you just can’t account for that when it comes to velocity. It’s just so hard. We dealt with that with work. We’ve been trying to deploy something to AWS for three weeks, and it comes down to a port mapping configuration that we totally overlooked and couldn’t figure out for three weeks, and then we found it fine. After a few minutes of work, I finally solved it. But it took three weeks to find that five-minute fix.

Matt DeCoursey 30:03
It wasn’t five minutes’ worth of work. That was three weeks’ worth of work. Yeah.

Matt Watson 30:07
So frustrating, though. But that’s what we do. It’s just crazy.

Matt DeCoursey 30:10
Yeah. And that’s, you know, there’s knowing where to hit the nail with the hammer. Yes. I mean, that’s so I lean back towards experience. And you know, so many people are trying to build stuff cheap, you’re going to end up with what you paid for, you know, like the average developer Full Scale as seven years of experience, and it shows but, you know, there’s no way you’re never going to find someone that knows how to do everything you need to be done, like, immediately, like that person doesn’t exist. Or if they do, they are rare. They’re like a unicorn. They are almost mythical. So like you mentioned, like, you got to learn how to do stuff. And that’s you talking about stability. And that’s, that’s one of the things that I think is important is gaining some domain knowledge about what you’re doing, and not trying to do it with a rotating cast of people. Because, you know, like, I think that’s a mistake a lot of people make and planning, they’re like, Oh, well, we’ll shrink this team down to two people. And if we need more, we’ll add more. Well, that takes time. And it’s like, you know, having people that really understand where the things are that you know, like someone that understands what has been built and how it’s built can go in and fix it, or support it or change it or explain it with remarkable speed. As you mentioned, taking three weeks to figure out a five-minute thing. If the person that knew that or acquired that knowledge is now gone. That means the next person is going to have to take three weeks to figure it out again. Anyway, these are all things. These are all things that we’re going to talk about in the coming weeks. Matt, I’m gonna let you. I’m gonna let you get it. I’m gonna let you go because I know you’ve got a lot of planning and defining requirements for our next couple of episodes.

Matt Watson 31:51
Absolutely. Thank you.