Ep. #941 - SDLC: Software Development

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:05
What’s going on, man?

Matt DeCoursey 00:07
I’m just trying to follow a process. And, you know, I find that the more and more I do this show with you, the more and more I learn about that process. I’m talking about the software development process associated with the software development lifecycle process. How about that?

Matt Watson 00:27
I’m ready to get some shit done this week. Let’s write some code and let’s get some shit done.

Matt DeCoursey 00:33
Are you ready? You’re gonna write code here during the show?

Matt Watson 00:36
Yes, we’re going to commit some code, check it in, do some pull requests. We’re gonna get it all done.

Matt DeCoursey 00:42
I have a better set of advice for you. You should know that today’s episode of Startup Hustle is powered by FullScale.io. Because hiring software developers is difficult, almost so different. It’s difficult and Full Scale can help you build a software team quickly and affordably. And has the platform to help you manage the team. Visit FullScale.io to learn more about Full Scale. We can do the code for you.

Matt Watson 01:11
It’s an amazing team we have, you know, of almost 300 software developers.

Matt DeCoursey 01:19
You know, it was awesome not to get off topic here. But today was outreach day at Full Scale, which is a company holiday that we’ve created. And we encourage and set up volunteer efforts across the Philippines where most of our employees are. We had, oh my god, there are so many people out doing amazing stuff that think it’s important to leave a good footprint. And, you know, do something great in the community around and, you know, we’ve always felt that way about Full Scale and being global citizens. Dude, we donated solar panels to schools that are off-the-grid and have power issues, coastal cleanup, tree planning, do we even adopt the eagle?

Matt Watson 02:02
Wow, everything. Community service that was done. A lot of work. Insane.

Matt DeCoursey 02:09
Sometimes giving away stuff is a lot of work, you know, but we did it. We did it. And do we get to name the eagle? Yeah, yeah, I suggested Watson. There we go. We’ll see. Probably gonna put that out too. But anyway, back to the show. And I was just so proud. I felt like I needed to share that. So this episode is actually coming out on September 16. But outreach day was August 26. You can go to the Startup Hustle chat on Facebook, I posted about 50 pictures of everyone doing stuff. Cheers to our team at Full Scale. All right, Matt. So here we are in the fifth of eight episodes and series about the software development lifecycle. We talked on August 19. We talked just an overview about what the whole thing was a 26. We talked about planning nine to talk about defining requirements. Last week, we talked about design and prototyping. And now it’s time to talk about software development. I think this is probably everyone’s favorite part of the entire process. Do you agree?

Matt Watson 03:13
Well, but I think it goes with the previous three episodes, the amount of work that needs to be done, before you get to this step. And this step can only be successful. If the last three steps were done really well. Or if you’ve got somebody who’s like a super ninja that can do all of that shit at the exact same time, which is like a unicorn.

Matt DeCoursey 03:34
That person would have to have a remarkably strong grasp on a lot of stuff. And what you call the I mean, it almost has to be like the founder.

Matt Watson 03:44
It’s what you call the next developer. That’s why they’re a 10x developer. Is it? Is that a fence then? Okay, I can do it all.

Matt DeCoursey 03:52
Surprised is that kind of like a five tool player in baseball, like the guy that can hit, throw, cat like run? Power, average all of it.

Matt Watson 04:02
And hit grand slams on demand? Yeah. I like it.

Matt DeCoursey 04:05
So now what happens in the development stage of this process?

Matt Watson 04:10
Well, it’s time to get to work, right? It’s time to write code. Now maybe you did some coding and the design and prototype phasing right. But it could have been different, people. So depending on the organization, you might have some developers that are doing architecture work and prototyping and some you know POC proof of concept work. And then now maybe it’s time to bring in the rest of the team and say, you know, what, we’ve done a little research, we understand kind of what we’re doing, we’ve got some proof of concept, but now we got to flush this thing out, we got to really build the whole project. And I mean, like, you know, back to the example of building a house, it’s kind of like, hey, the architects have done all the designs, we’ve got all the blueprints, blueprints, it’s time to get to work.

Matt DeCoursey 04:54
What about just the general setup? You know, like, I think that’s something that can be overlooked. And you know, we talked about defining requirements, designing and prototyping. But one of the things that I think a lot of people don’t either think about or take into consideration, especially when it comes to the product roadmap and stuff is that like, there’s a lot for if you haven’t, if you have something new, you have a lot of shit to set up. I mean, there’s servers and you’ve got repositories, you got to get people on the same page. You know, there’s something to be said about that. Now, if you’ve got an existing project, and you’re moving forward on something new, then that is probably a lot more stable. But it’s sometimes that framing and plumbing of a project that can slow it down, and you know, I mean, it can take a little bit, they can take a couple days or something, hopefully not longer than that to get things moving.

Matt Watson 05:47
Well, for sure, it’s different if you’re like, hey, we already have this product, and we’re just doing a new project, we’re adding a new feature to it, right. Versus like, it’s totally Greenfield, we have nothing. And we’re starting from the ground up. And the reason it’s harder is to your point, it’s like, hey, we don’t have a code repository, we don’t know how to deploy this thing. We have no security model, we users have no way to log in, we have no way to say what they have access to we like we don’t have a database, we don’t have Microsoft Azure or AWS setup, we were missing all the plumbing, all the infrastructure, all the groundwork, it’s all gone, we have none of it. And so yeah, it’s a lot more work to figure all that out. But sometimes that’s also when it’s a lot of fun. Because a lot of developers honestly don’t get to do that they usually join something that already exists. And they’re working within that kind of sandbox or playground, that is kind of defined what they can or can’t do. And it’s actually kind of fun to be able to do something from the ground up. But it’s pretty rare.

Matt DeCoursey 06:46
Some developers are lost or in that process, too, though, there are definitely people that get that side of software more than others. And there are some people that and you know what, I think if you’re managing or running a team, ask the people working, are you comfortable doing this?

Matt Watson 07:05
It’s kind of a pain in the ass, if I can be honest with you, because we already have all this stuff set up, you’re like, hey, I just need to go create this new page. And you know, there’s some input fields, and I write some database queries and submit some data, you know, do whatever it does. And like, oh, to do authentication, I just add one line of code, and it handles all the security for me, and like, all this stuff just works. And it’s like, just magic maybe? Versus if you’re starting from scratch, like, yeah, none of that exists. You know, it’s a whole different world.

Matt DeCoursey 07:35
How do you know when you’re ready to like, write code and see stuff?

Matt Watson 07:41
Well, so as you start, if you talk about kicking off a new project, forgetting, you know, if it’s a brand new app, or an existing app you’re working on, the first thing you have to do is start with some basic planning, right. And we’ve talked a lot about planning at a high level, and we’ve talked about design at a high level and but if this is where the rubber meets the road, and it’s a different kind of planning, right, this is like, okay, we’re in JIRA, and or whatever the tool is, pick your tool, and it’s okay, we got to figure out like the story points and all the detail. We’re like, the really low level planning. So we had a great episode about high level planning. First thing you have to do when it comes to software development now is getting into the low-level planning, how do I translate those requirements? How are we actually going to do this and who’s going to do the work? And, you know, the Bozo that gave me the requirements and design didn’t understand how any of this shit works. And now I gotta go, like, tell them that whatever crazy design they have isn’t actually going to work, and may have to redesign the whole damn thing. That’s like the first step.

Matt DeCoursey 08:43
So now, this is typically also where you’re going to begin to run into the first quote, real problems of building software is the actual software development. Part of the process. And there’s a lot of stuff that can go on. And you know, I found a, I found a list that was published on Forbes that was related to this. So I’ll give them credit for this. But it really said it said, well, so you know, this is where you’re gonna. Okay, integration issues.

Matt Watson 09:18
I think we should talk through every one of these points a little bit, because it’s actually a really good list.

Matt DeCoursey 09:22
Yes, I know. Yeah. Yeah. And normally, we just steal your list and don’t give you credit. So congratulations, Forbes. Thanks for the list. But yeah, immigration issues are a great example.

Matt Watson 09:32
So the company I work at right now we’re doing integrations with Google AdWords and Google API and all this stuff. And it’s pretty, pretty straightforward and, and not too hard to work with. But I’ve had other projects before I had a project back in my VinSolutions days. It was some finance, like a credit application approval thing. And they were using some weird ass technology that required this weird ass encryption and all this stuff. We were like three months trying to figure out how to integrate with this thing. It was a total disaster. And luckily today most integrations are more standardized. People just use JSON API like rest, like pretty simple stuff to work with. But sometimes integration issues that seem simple, but can turn into a total nightmare. You just never know.

Matt DeCoursey 10:23
Yeah, I think that anytime you have to integrate something with something else, I think it also is very difficult to predict how long that’s going to take.

Matt Watson 10:32
Yeah, and sometimes it could be like, oh, we need to integrate with this thing. It seems easy. But it’s like, hey, we need to call that API like 10,000 times a minute. And it’s really slow. And that’s not gonna work, like we were, they just won’t let you, we have to figure out how to do this in a batch, like, how do we take all 10,000 of these things and make one call? And we’re like, oh, well, our interface doesn’t allow that. I like listening in at work. And that’s, that’s the problem you run into, right? Like you’re in design, planning, you know, the executive team has this great idea. And we’re just going to integrate with this partner, okay, all sounds great. But then you get to the development phase, and the engineers start really digging in, and immediately they find problems like this or like this, this is not actually going to work. And it’s inevitable. That’s what happens.

Matt DeCoursey 11:18
Next, on the last communication breakdowns.

Matt Watson 11:22
And I just gave you an example of one, right? It’s all about communication around planning, and getting the product team and executive team to communicate with the engineers about what we are doing? How’s it supposed to work? Why are we doing this, the requirements, getting them to understand all the details of all of it? Because if the littlest things you don’t communicate, make all the difference, right? Like you may work on a project, we didn’t tell the engineers like, what users can log into the system have access to this thing, right? And then you dump that on them at the last minute, like, oh, shit, and I have to go back and rework all these things because of security, because no sort of security was implemented or whatever. Like, whatever it is, communication is really key. And that’s the thing we’ve always talked about on this podcast that’s so much about software development, is communication. That’s why we have stand up meetings every day. That’s why you’re white right. That’s why you are planning. It’s all about communication.

Matt DeCoursey 12:16
I quote you on that a lot. Yeah, I do. And I don’t make a habit of quoting you all the time, Matt. But that’s one of those hall of fame quotes. All right, next on the list is one of my favorite mess ups that occurs. And I say favorite, like, I see it a lot. It’s actually not a favorite. And I wish that people were better about this, but unrealistic or mismanaged timelines, and you heard me on the first item in the list, talking about how you never know how long it’s going to take to integrate. I think that unrealistic timelines cause a whole lot of problems in any project. Because I mean, it’s one thing to be able to have an ambitious target. It’s another one to be completely unrealistic with it.

Matt Watson 13:04
All right. I’m gonna get on my soapbox for a minute. This shouldn’t happen to me this week. I get dumped on my lap Monday, that we have this important project that needs to be done in September. By the way, it’s the last week of August, like, oh, we have to have this done in September. And I’m like, How did I not know about this? If I’m in charge of product and engineering, I should know about all this stuff. And I asked him, how long have you guys been working on this? They’re like, since April, like you’ve been talking about and planning this thing since April. And you told me the last week of August that I need to have the engineering team build this next week, are you kidding me? But uh, but that’s what happens all the time. It happens all the time, that you get these crazy, like, I always blame the sales team for all this shit. The sales team always goes in. Shell sells a bunch of shit because they don’t have to deliver any of it. And then they dump it on the engineering team. And we have to miraculously, like, move mountains to get these deals done. Back to education being important.

Matt DeCoursey 14:02
Well, I think this occurs when non-technical people set the timeline. Right. They don’t really know how long it’s gonna take. Yep, it becomes helpful to just, yeah, just because you want something done? Well, you have some people that always sit down, it should take two weeks, like two weeks. Show that two weeks. All right, next on the list, this is a good one feature overload.

Matt Watson 14:25
Well, there’s two, there’s two parts that I’m part of that is, you know, giving the team too much shit to do in general. But feature overload. Also, to me, it’s just complexity, like just making things too complicated. Like think about Twitter and like, you can’t edit a tweet, you can’t schedule a tweet in the future. Like you can’t post, you know, a tweet with more than one message or whatever, right? Like if you add all those features, all of a sudden, it gets way more complicated, right versus making it really simple. And so the complexity of the features and functionality that you build is important and we’ve talked a lot about this in the past about Gigabook, right? Like, scheduling sounds easy until you try and handle 50 different scenarios with all these levers and switches and options and things and workflow and events and all these things are going to happen. And it just gets so complicated that maybe you never get the project done because you made it too complicated.

Matt DeCoursey 15:16
Yeah, that’s not uncommon at all. And that goes hand in hand with the next item on the list, which is underestimating the task at hand. And that’s kind of back to a timeline issue, or I think that in this particular regard, some things are far more complex, and some developers are ready to handle or understand.

Matt Watson 15:37
And that comes back to the skill level of the developers to write something that can be really simple and trivial. For one software developer can be the most complicated thing another developer has ever worked on their entire life, right. And that’s why it’s Full Scale. We mostly hire senior developers, right? Because senior developers usually can take those complicated tasks, and they can figure them out. But imagine back to how we always talk about Tom Brady and the interns, right? Imagine giving them the most complicated project to the intern who is never going to get the shit done. Versus having Tom Brady just take it and throw it down the field don’t? Spike.

Matt DeCoursey 16:12
That’s the new name of my band.

Matt Watson 16:15
That’s what we should name the eagle.

Matt DeCoursey 16:17
Tom, Tom Brady, and the interns are just named Tom Brady.

Matt Watson 16:20
Tom Brady.

Matt DeCoursey 16:22
Anything, I’m gonna name him Patrick Mahomes.

Matt Watson 16:24
All right. My homies.

Matt DeCoursey 16:25
Not necessarily but no, but Tom Brady, and the interns is a great name for a band. I’m gonna put that out there. Yeah, yeah. So all right. When you know, another thing that breaks down a lot during the software development process is the people that are requesting something be built, don’t add an adequately defined, explain or demonstrate why, like the why of the outcome. And I just tell you right now that people have a much easier time building something for you, and they understand why it’s important. And it’s kind of all like, what it does. It goes a little beyond why it’s you know, if I understand the utility of something, I think it makes it easier to build it rather than just trying to follow step by step instructions to create something that you have no clue what it should be doing.

Matt Watson 17:24
You know, I think a good example of this would be for me to go tell my wife tonight that we’re going out tonight. And if I don’t tell her like, why we’re going out and where we’re going, the way she dresses and plans for the night would be totally dramatically different. Right? Like, what she would wear if it takes three hours to get ready is five minutes. And why the details about why we’re doing this where we’re going, like what we’re trying to accomplish is so important, and I think that’s a good example of like, how long is it going to take us to prepare for what we’re going to do tonight? Like it’s just a little detail that makes a big difference.

Matt DeCoursey 18:00
Well, I want to take you longer to prepare.

Matt Watson 18:02
In five minutes I’m ready. It doesn’t matter.

Matt DeCoursey 18:04
Yeah. My wife gets so mad at me about that. It must be easy being a guy. I like it. Can you quit focusing on me and keep getting ready and this will go much faster. That doesn’t land well either, either. Okay, so you know one thing we haven’t really talked about at all during this whole series is the whole process or any of that quality assurance underestimating the importance of QA now look, I’m this is my soapbox. Keep developers developing, testers testing, designers designing, writers writing, keep sales people selling. Do this stuff at your business, which by the way is hard. It’s fucking hard. Like, I feel like I spend most of my day trying to do that. Get back in your lane. You shouldn’t be messing with that. Don’t worry about that. That’s a tomorrow issue we’re worried about today. Why are you even doing that at all? But yeah, but the QA? So people will say to me, this is one of the red flags that shit people say to me, that makes me think you have no clue what you’re doing. Well, shouldn’t the developer be quality testing it himself?

Matt Watson 19:24
You know? Yes. But it’s yeah, it’s different than anything else in life where you asked your kids to clean the room and they just don’t clean it quite the same way that you would do and you would walk in and immediately see like seven things I didn’t do, right. They should test their own stuff. And they do, but they just don’t do it to the same level as having a third party perspective come in and who’s, who has never seen it before. Be like, Okay, I’m gonna break this thing. And the good news is we have a whole episode about this next week.

Matt DeCoursey 19:55
Yeah, and that’s a big one. Okay, the next in line feature creep off is well known as scope creep.

Matt Watson 20:02
You know, it’s like we’re trying to . . .

Matt DeCoursey 20:05
Do that again.

Matt Watson 20:08
Yeah, I’m trying to launch this thing next week, and you keep coming in every damn day with another idea, and more shit that has to be done this week. But I’m trying to ship it next week, like, stop, let’s just let’s get this shit done and out the door. Instead of changing shit nonstop. It’s inevitable. It’s what happens.

Matt DeCoursey 20:25
Gotta eat the elephant one bite at a time. All right? How about defining the target audience that your software will be used by? This is an overlooked one. And once again, like this list from Forbes, we’re kind of just looking for our own stuff. And we found this and I was like, This is great. It’s, yeah, they nailed it. So you know, not defining your target audience, like who’s going to use this?

Matt Watson 20:53
Well, just think about it. When you’re building software, I couldn’t be building software for like my three year old on an iPad, or in my case at my company, a 65 year old plumber? No, totally, totally different. That’s the thing with software, who the target user is can be very different. If they’re have is it mobile? Is it? Are they sitting on a desktop? You know, all of it, it all matters, you know, just from age and generation and level, you know, how good are they using technology and all of that, like, it’s, you need to understand it.

Matt DeCoursey 21:30
Now. There’s one more item on this. There’s one more item on this list. And I think it’s more related to more like the overall thing you talk about, they say under estimating the demand. Now this is more of a business side of things. And actually, yeah, it actually leads to it actually leads to well, but it can also just lead to the I think it’s a business thing in general, like, and this is why a lot of you can talk about undressing the demand for a feature for a whole lot of different things. But, you know, like I said, that’s the only item on this list that is a little out of the lane, in my opinion. But when I hear underestimating the demand, I think it means for your software platform in general. And you know, that’s the number one reason that startups fail other than running out of money, which is kind of the obvious reason for all of them.

Matt Watson 22:26
But that’s an important topic. It’s an important topic because it it we’ve talked about this, I think in other episodes, planning of scale, like performance, and scalability is potentially where you’re running this right under estimating the demand, like are we going to launch this thing, or we’re going to have 10 users are million users. And the problem is if you plan for a million, and you spend like a whole bunch of extra time, but then you only get 10, you like wasted a bunch of time. But if you don’t plan, you know, at least some of like, hey, we could have like millions of users. And we need to keep that in mind, how would we rapidly figure out how to support that. It’s just something you have to keep in mind?

Matt DeCoursey 23:06
No, I agree. You know, if you’re looking to find expert software developers, it doesn’t have to be difficult, especially when you visit FullScale.io where you can build a software team quickly and affordably you can use the Full Scale platform to define your technical needs. And then see what developers, testers and leaders are ready to join your team visit FullScale.io to learn more. Alright, so yeah, I mean, that’s a big thing, like having a reliable software team is crucial. I mean, obviously, we’d like to talk to you if you’re trying to build one once again. FullScale.io. But now, what are some tips, and I’ll give a few on hiring people in highly technical positions.

Matt Watson 23:44
Hiring software developers is hard. Let’s be honest, right now Full Scale, we’ve hired a lot of them, but we only hire two or 3% of the ones that apply for a job. Right? And, yeah, it’s really hard. And, you know, you sit down with somebody, and they tell you, Oh, I’ve written dotnet code for 10 years, I’ve done this, and I’ve done that, and whatever. But at the end of the day, when you hire them, and it’s actually time for them to start writing code, and reading requirements and figure out how to architect things, it’s really hard to know if they’re going to be good at or not, it’s just really, really, really hard to hire software developers. And that’s, that’s one of the great things about working with somebody like Full Scale, right, is they do a good job of hiring people and vetting them and have employed have people that have worked on other projects, and you have a better idea, you know, from they’ve had this employee for a while. So they have a good idea that they’re, they’re good at what they do. And, you know, if it’s a 30 day commit, so if they don’t work out, it’s like, you know, what, for whatever reason, this just wasn’t the right kind of project for them. And that’s the other thing to talk about here. Right if you have some developers that they love working with one particular programming language or they like working with databases, or they like doing front end work or they like just doing architecture work. They just love to write diagrams and Visio and The oldest architecture work, but they don’t actually like to write code, you get people that love to do just different things. And that’s part of the problem, too, is just lining up the personalities to the right type of work you have to do.

Matt DeCoursey 25:11
Yeah, and that’s, you know, when it comes, I think that there’s the passion thing, you know, some people are, are very, some people are very passionate about what technology and software development and what they do. And then I think, you know, it’s like you mentioned, like lining people up for that kind of stuff. Just ask them. What do you want to do? You know, there you have this dividing line that many developers put in their own resume and say, Hey, I’m a front end developer, I’m a back end developer, don’t hire someone that says, I’m a front end developer expecting them to do a bunch of back end tasks and like it, or maybe even do it? Well, I mean, there’s a lot of these folks define what they’re doing, you know, Full Scale we’ve created about, we have about four dozen certifications that we use to that we use to to gauge someone’s technical skill, but that’s only part of the overall picture, you know, with that you want to look at experience? And do they have direct experience related to what you’re trying to hire them to? Do you think so? You know, like, do they have industry experience? Once again? Are they passionate about communication skills? Do they want to be a leader or be on a team? And that’s a question we asked her in interviews, because someone that doesn’t want to lead a team, don’t put them in charge of a team, you know, and there’s other things, it’s just like, your attitude towards things like because there’s a lot of feedback, and a lot of communication. And there’s a you know, as a developer needs to have some thick skin in some regards, the same way that like a graphic designer would, you know, it’s about creating for the, it’s about hiring people that create the things that you need, and want, not necessarily what they need and want. And, and some people get real hard about that feedback, they get upset about it?

Matt Watson 27:06
Well, the problem is, when you go to hire somebody, you’re never going to find somebody that has the exact skill set that you want, it’d be like, asking somebody like, what do they want a future spouse, and they, you know, rattle off these 25 things of the perfect spouse and like, you’re not going to get 90% of them, right. And hiring people the same way, you’re not going to find somebody who has the exact experience with the exact industry. And they did this exact database and this exact front end framework and all this, with this exact cloud provider, like it’s not going to happen, what you’ve got to do is find somebody that has mostly, you know, the right kind of like, hey, they’ve done a lot of front end development, develop experience with Angular and view, maybe I’m using some other framework, and they can learn it, I, you know, I talked to them, they seem bright, I’ll give them a couple of weeks, I’ll give them a month, they’ll get up to speed, they’ll figure it out. Because you’re just never going to find the right exact person. And there’s going to be some on the job training. It’s just, it’s just part of the deal. Now, if you only want to hire somebody for one month to do a project, then yeah, I guess you got to find the exact right person. But if it’s a position that’s going to be around for a long time, there’s gonna be some on the job training, and you’re just gonna have to accept that.

Matt DeCoursey 28:16
Yeah, and I agree with you as well. So all right, next topic. What do you do when you discover new requirements, like in the middle of the trap?

Matt Watson 28:27
You know, this is why agile development exists, right, if you’ve got to do some work. And every every week or two continue to adjust based on the work that has been done, the new findings, versus the old style of this was more Waterfield Waterfall development, right, you’d write all these requirements and all these detailed specs, you hand it off to the engineering team, you tell them good luck, and like a six months from now, bring it back to us, right. Versus now it’s more agile, it’s like every couple of weeks, we’re making slight adjustments to the direction that we’re going. And in software development, it’s inevitable. I mean, I’m remodeling my house today. And we’re, it’s so different, like, they’re going to install the base molding trim around the bottom of the room, but then realize they put the cabinet too close to the wall that the base moldings not gonna fit, like you couldn’t open the drawer, like it’s software development the same way you run the same kind of shit every single day of like, whatever the designs were, you figure out like, it’s just, we’re just not exactly going to work that way. And we’re going to have to make some changes. And sometimes those changes could be no big deal, not going to add any time at all. Or it could be like weeks, there’s like weeks of work that were just added all of a sudden. And that’s why you have to go into this kind of knowing that it’s sort of controlled chaos. That’s just software development. And it always like we always joke, it takes twice as long as you think it’s gonna take and it costs twice as much money as it’s going to take because it’s just part of the deal.

Matt DeCoursey 29:53
I think with this kind of stuff, you really need to ask yourself, is this a vital right pillar or change, it’s really easy to, like want to, you know, like, think about pin the tail on the donkey, you know you ever played that game? And it’s just like, you want to just keep panning things on blindly and kind of aiming for a solution or like, do we need to do this now? Because you’re kind of like Matt was talking about, there’s a lot of things in this process that have downhill effects that are going to affect other things that you’re wanting to do that can affect other parts of your timeline. And you know, the real question, and I’ve made this mistake before is I think you just gotta ask yourself, like, are we over building this? And if you aren’t, now, look, there’s oftentimes things come up and you’re like, wow, okay, we didn’t think of that. And I think you’re pretty much guaranteed to have that situation. If you’re doing something new. I’m, I would be I don’t know, if I would be if someone told me that they built something complex, and that they didn’t run the anticipated everything ahead of time. I’d wonder if they’re telling me the truth?

Matt Watson 31:04
Well, we talked about this a lot. And I feel like one of the most important things is learning to say no, it’s learning when to draw the line of like, you know what, this is good enough, the product is good enough. The design the requirements, like we built a good product, let’s ship it, instead of just continuing to change things make it more complicated, and over and over and over. And honestly, one of my favorite things that always stuck with me once you know, so and so it’s like, oh, we have to do XY and Z. It’s like, so what, what if we don’t? What’s going to happen? What is the worst thing that will happen? Do we lose that customer? Okay, well, what about the other 99% of our customers that they don’t need this thing anyways? Right. And that’s why we always talk about products like Twitter or something, it’s really simple. It only does one thing. They didn’t try and do 1000 different things, they tried to focus on one thing. And that feature creep, and complexity, as we talked about earlier, is usually what kills products, they become so complicated, and full of all this shit that nobody even cares about, except like one customer, or one executive that had this crazy idea that the you know, the vast 80% of your customers don’t care about this anyways. And you have to learn to draw a line somewhere and say, no,

Matt DeCoursey 32:18
no, I agree. I agree. And these are disruptive things much like someone quitting or not being able to deliver on time. So like, you know, this is a big topic, because there’s been so much news and so much news and headlines, especially in 2022, the great resignation all these people are changing jobs and are quiet. Quitting is the word I’ve heard now.

Matt Watson 32:48
Yeah, well, I think you need to. It’s what quiet quitting was the word I heard recently. What does that mean? I don’t know, people that just don’t know that they’re not happy. And then all of a sudden, they’re just, they just kind of bail. They just just all of a sudden disappear. They don’t they don’t complain about anything. They just all of a sudden they’re gone.

Matt DeCoursey 33:03
Okay. I think that’s always been the thing quietly. Yeah. So, you know, I think if you’re going to use, if you want to prepare for disruptions, or you need, well, that’s where some like mild documentation or like the understand, like, you just need, you need to assume that that’s probably going to happen, and how are you going to handle it? And I think that that’s, by sitting down and having a little bit of a contingency plan for what happens and not having one person that is the only person that has the keys to the castle in certain places. And, you know, that’s what many people refer to as the bus rule. Like, if this person got hit by a bus or won the lottery, how are we Yeah, or how would we deal with it? Because that comes up. And, you know, that’s, that’s something that’s bound to happen.

Matt Watson 33:59
And, you know, I mean, it really is, it is a huge problem. And I have been, in this case, many times, where you have somebody really bright on the team, they’re like the architect, you know, visionary of this thing. And we’ve got this complicated product, and they’re the person that understands how it all works. They’ve been here for five years and know where all the bodies are buried, they get an amazing amount of work done. Like if we lost that person, we would be screwed. And everybody has one of those people, but you have to understand those risks, and you have to figure out how to transfer that knowledge to other people because it’s inevitable that they’re gonna win the lottery or retire or something’s gonna happen eventually.

Matt DeCoursey 34:40
Yeah, I mean, I think the one thing that there’s only one thing I can promise you will occur and that’s the things will change. Yeah. Yeah, I mean, it’s pretty simple. So look, if you need to hire software engineers, testers, and leaders, Full Scale can 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. Learn more at FullScale.io. Well, Matt, we’re here at the end of an episode that’s about software development. And I think we laid a lot of stuff out, you know, thanks to Forbes for giving us a great list. I mean, we’re working on our own and found that one, it was like, wow, what else would we have to say? I guess that would make me ask, what did we leave out here?

Matt Watson 35:36
Well, what I love about this episode is we didn’t try and get overly technical in the weeds about writing code and how to get and do pull requests and all that stuff. That’s a whole nother level of software development. And we didn’t get into those technical weeds, I liked that we stayed above that. So that if you’re an entrepreneur, or business owner, or whatever, listening to this, you can better understand just the common pitfalls of software development and the complexities of it. And I hope you can appreciate those. But yeah, there’s a lot of detail in the weeds like actually writing code and how people do that workflow and the process of the engineering, but I like that we’re keeping that higher level.

Matt DeCoursey 36:13
Yeah, I agree. And, you know, there’s, if we had this as one of those topics, it’s so overly broad. Yeah, I mean, we could probably have a whole separate podcast about it. I mean, like, literally, like, that’s all we talked about. And there’s, I think that sharing the common pitfalls is probably more beneficial to everyone listening than anything else. And some regards, just for your own sanity of knowing that, oh, I’m not the only one having this problem. But that said, enough people have had the issues ahead of you, that you can prepare a little bit for that and have a little bit of understanding that, you know, hey, they are called common problems for a reason. So, you know, there’s, there’s ways to be prepared, or maybe lower your own frustration and anxiety level. I think that, you know, a lot of I think, especially for the non technical if you’re trying to lead a team, or in that regard, I think that knowing that, that that list of things that we went through earlier, you know, and we’re talking integration issues, communication problems, poorly mismanaged timelines, feature overload. Also, scope creep, you know, these are similar things under estimating what you might be able to pull off without explaining the why. Getting good QA, which we’ll talk about soon. And, you know, knowing your target audience and who you’re building something for, if you’re overlooking or I don’t know, you’re probably gonna go through all that. If you haven’t already. It’s probably on the way.

Matt Watson 37:51
To me, it’s all about communication. So much of all those things that that list, it all comes back down to communication, communicating, why are we doing this, who’s potentially going to use it problems we could have. But one of my favorite things that we didn’t mention, when you’re running a software development team, is also telling them what we’re not going to do. We’re not going to do these things. You need to stay in these, you know, guardrails because from my experience, a lot of developers sometimes give them a requirement like hey, I need you to go build this thing. And they may just really overcomplicate things, they grossly overcomplicate things. And sometimes I feel like the most important thing is telling them what not to do, like giving them the very defined guardrails of like you don’t need to worry about this. Don’t overcomplicate this thing, don’t think about that. This is not a scenario to worry about. Stay in these guardrails, and sometimes that’s the most important thing to do.

Matt DeCoursey 38:45
No, I agree. I agree. And you know, Matt, we’ll be back next week to talk about the ever-so-captivating subject of testing.

Matt Watson 38:54
God, my least favorite subject. See you next week.