Ep. #646 - Avoiding Technical Debt

Matt DeCoursey 0:00
And we’re back. Matt DeCoursey, here, with Matt Watson for another episode of Startup Hustle and part 26 of our 52-part series about how to start a tech company. Hi, Matt.

Matt Watson 0:13
How’s it going, man?

Matt DeCoursey 0:15
I’m good. I’m good. And you know, we missed last week’s episode because shit happens is

Matt Watson 0:24
No. It’s just summer vacation time. Let’s be real.

Matt DeCoursey 0:27
You weren’t feeling well.

Matt Watson 0:28
That’s true. You’re right. I was.

Matt DeCoursey 0:32
Yeah, yeah. Because, you know, much like many startups and early-stage tech companies, we may have made some inappropriate estimations and the timeline of our deliverables as we are now openly admitting we are three full weeks behind are in our 2021 series, which is now a 2021/2022 series.

Matt Watson 0:57
You know what? That sounds like technical debt. We’re behind.

Matt DeCoursey 1:01
Oh, wow. Let’s talk about how we’re going to avoid it. But yeah, so like this is, for those of you listening, today’s episode of Startup Hustle is brought to you by FullScale.io, helping you build a software team quickly and affordably. That’s a business that Matt and I own together. We have over 200 IT professionals, web developers, QA testers, product managers, Dev managers, and people that try to spend a fair amount of time figuring out how the hell to avoid technical debt, Matt, what is technical debt?

Matt Watson 1:37
Oh, there’s got to be some official dictionary definition here. But it’s really all this shit that we should have done that we didn’t do that, at some point in time comes back to bite us in the ass. You know, in our personal lives, it almost be like not paying our taxes. Eventually, that shit catches up to us. I mean, maybe that’s the best way to look at it.

Matt DeCoursey 1:57
I think that’s a fair comparison. You know, I’ve always referred to technical debt as all of the things you it’s, it’s having to go back and fix all the things that you didn’t know you didn’t know, or the things that you knew were shortcuts. But for whatever reason, you said, go ahead just does it work. And you know, you’re looking at Yes, it works. But it might not always work. Or in some cases, as you continue to add rubber bands to the ball of rubber bands, you eventually get to a point where you need to undo said ball of rubber bands and, and just kind of figure some shit out?

Matt Watson 2:37
Well, you know, through all of our hundreds of episodes of this podcast a few times, we’ve talked about the problem of the guy that he’s opening a restaurant, and he’s so worried about cleaning the restaurant and get everything so perfect. He never opens it, right? Where if you just threw some shit together, you get some used furniture. And yet, you know, whatever the hell you do, and you open your restaurant, you’re in business, but you got some technical debt, right? You’re like, oh, we need to remodel this thing, I need to buy a new stove. I didn’t really train the cook, how to do this the right way, whatever, you got all these browsers, there’s roaches, whatever, but you’re in business. That’s the difference, right? Where it is, as a startup and a technical company, you can spend forever perfecting every single thing of like, our software does every single feature, it has the perfect documentation, it’s ready to scale to 8 billion users because every human on the planet is going to use it right? You can perfect every one of those things, but you’ll never ship a product, you’ll be the guy in the restaurant that never opened the door. Right. And that’s the problem with software is it’s impossible to perfect it and I can give you a real world example from Netro. That happened today. So we’re ship we’re releasing a new version of prefix, which is our free tool. And we’re making a paid version of it. And somebody internally is upset. Because if you have the paid version of it, it’s not easy to go for from the paid version of it. But to the paid version of the product, you’d have to have two bills. So do we sell the product and make money? Or do we put it back on the shelf and spend a bunch of time doing engineering work to simplify that? Right? Like these are the types of things that become technical debt? And it’s like, are you either in business or not in business, because you’re so worried about perfecting every little thing.

Matt DeCoursey 4:27
So about speaking of perfecting every little thing, I thought that I would take a little time to you know, when you use the term technical debt that’s broad and far reaching. So I’m gonna rattle off a list of different types of technical debt. And if we had to talk about all these, this would be like another 52 part series. So we’ve got architecture debt, build debt code, debt defect, debt design, documentation, infrastructure, people process requirements, services, test automation, and just general testing. Those are all done Print Legos that you can stack on top of each other when building a technical debt Castle,

Matt Watson 5:05
you know what I just heard?

Matt DeCoursey 5:08
What’s that?

Matt Watson 5:10
Job security, job security, job security jobs. That’s what I just started.

Matt DeCoursey 5:14
As a founder and an entrepreneur, I heard no sound. That’s the sound it made when I opened the business’s bank account. Yeah, because that’s what that’s the sound that comes out of your bank account and your budget when you go to see about the technical debt. But I mean, overall, like when it comes to in a business, we’re talking more specifically about software and tech companies. But businesses in general accumulate, accumulate as a sort of technical debt. That is eventually like you said, it’s kind of like taxes, if you don’t pay it, eventually, someone’s going to show up at the door and either lock it or haul you away, or, and those people could be everything from your customers, your clients, your own employees, your partners, I mean, a whole lot of difference or a tour, or go ahead,

Matt Watson 6:13
or you sell the company and you run the fuck away from all of it.

Matt DeCoursey 6:17
True, that is, that is what there is an exit the technical debt. But in the end, someone’s gonna have to clean it up. And you know, much like an oil spill. It sometimes takes specific processes, technicians and you know, I like you, Matt, we’d like to share real life examples. When we first started creating GigaBook. It wasn’t it didn’t have as as much stuff stacked onto as you build software, you get more layers, more functions, more features. And we had created GigaBook in a specific type of coding that was in its swan song on the way out meaning like it wasn’t what people use is procedural coding, which ended up you’ll hear a lot of developers and technical people talk about spaghetti code, meaning it looks like a messy, sloppy bowl of spaghetti. So when you go to pull one noodle out, it’s touching a whole bunch of other stuff. And really, in the end, we we got to the point where the complexity of the platform was interconnected. And in a way that didn’t really have a lot of logic to it. So we would go to fix one thing, and maybe break three or four others. And that’s what technical, that’s what technical debt does. And you know, the and people think about it, now you can speak to this as well. So you know, we use GigaBook as an example. So putting something on and off at a calendar is not inherently that difficult. It was the 19 other if then scenarios that could occur after and you start building and stacking and layering things into your tech company. And it doesn’t just turn it doesn’t get twice as hard or three times or four times as hard. Those are like multiples. It’s like four times harder once you add another layer eight times 1632 Infinite. Yeah. And we and that’s when the technical depth starts to mess with?

Matt Watson 8:15
Well, it’s some of what you’re talking about. There isn’t so much technical debt, it’s also just product complexity, right? And, you know, we had the same problem at VinSolutions, my, my former company, and it was a CRM for car dealers. And the problem is, at some point in time, software gets so complicated, it has so many levers and switches and options, kind of like Giga book that nobody even knows what they’ll do. And Drew like nobody in the employee in the company, none of the employees in the company even know what all the different things do. And then as a developer, if I’m the one in the code, trying to change that shit, I’m breaking stuff I didn’t even know existed, right? Like, because there’s so much complexity, like you said, with Giga book, but that in some of this has come down to technical debt. Because the problem is, eventually the product is so complicated, everybody is scared to change it. And you sort of stuck with what you got, because you’re like, the risk of changing this far outweighs the reward of whatever it was, we were wanting to improve. Because it’s just so inherently complicated. And we know we’re gonna break all sorts of shit if we touch it.

Matt DeCoursey 9:18
And much like a Weezer song, once you start pulling that string on the sweater. Yeah, you watch it unravel as you walk away. And that’s the thing is so like, you sell the company and you walk away. There you go. That’s when we really have just invented a new type of exit, which actually isn’t new. I think that that type of exit has been occurring for since technology existed, but you’re totally right. And we run into this a lot at Full Scale, because people will reach out about what we do. And you know, sometimes you say, Well, what tech stack do you use and they named something that has just not been common

Matt Watson 9:57
for and they want to start with that. us to fix it right. And so, so much of the technical depth part of this when you talk about coding, and specifically the coding parts of it, sometimes it just comes down to trends, right? You’re like, when you first wrote the first version of giga book, you may have done what was normal in that day and time, and it was trendy. And that was the common way of doing things. Well, three years go by five years go by, there’s newer versions of PHP. Now people are using MVC style frameworks are now they’re using front end frameworks are using Angular, or they’re using React or whatever scenario. So no matter no matter what it is, you look back, you’re like, Man, the way they did this shit five years ago was stupid. They don’t use all this cool new stuff. But the thing is, no matter how you do it today, the same thing is gonna happen five years from now, it won’t be react and won’t be Angular, it’ll be something else five years from now. And you’ll look back at whatever it is you did today. It’s a never ending thing. It’s just the trends that go on with software development. And part of the problem with software developers, they always want to do whatever the trendy thing is, because it looks good on their resume. What they don’t want to do is get stuck in the old antiquated technologies, like you said, like, Oh, they’re writing COBOL, or Delphi, or Perl, or cold fusion, or flash, or like some of these technologies that are like, really dead, like there are companies that still use them. And by the way, if you have those skills, go find one of those companies, because they’ll probably pay super top dollar. But past that, it’s hard to find a job because you know, if you’re looking for a dotnet, developer, Java or whatever it is, you’re not going to hire somebody who’s a Perl expert. It’s just hard. But that’s what happens with the trends is these companies build things. They just keep maintaining them forever. And that’s why you have all these companies to this day still use COBOL and mainframe technologies because you know what they work.

Matt DeCoursey 11:42
For those of you listening, I want to point out that before the last couple episodes, Matt has looked at our setlist and go on man, I’m not even sure we’re going to be able to talk about this for 40 minutes. And then I get him started on some of this and and we end up with like an hour and a half long episode. And why is that awesome? Because now he knows what he’s talking about. This is someone that has built two tech companies, and legit taking them all the way to the finish line. So listen to what he has to say about a lot of this, you know, one of the things that you that we were talking about along the way, you know, so if you’re trying to build the goal is an entrepreneur and a tech company or really, if you want to do something vigorous, you need to make it bigger than you and bigger than the than the couple people that may have started it. So now you look at like scaling a team. So what does that mean? It means being able to in a somewhat frictionless way, and improve the capacity of what you’re delivering, or even the the number of people that are on it. And I think when it comes to avoiding technical debt, one of the things that’s a key is is like you said, it’s like, there’ll be like two people that know how something works. And there aren’t enough basic notes. And like some of that it can be pretty basic, like a simple if then sheet when I say if then like you like you can bring in a new developer or if you lose a key member of a team, you might end up having that person need a month, maybe even more to really understand like, what, what does this what does that what you like, and when I say if then If this occurs, then yeah, this and, and that’s where developers, you know, without that simple, you know, documentation, it doesn’t have to be fancy, like, we had to go through that with GigaBook because we try to bring someone new in and you know, it was stupid for us to think that they would just immediately say, oh, when this occurs, it’s going to trigger four different reminders, it’s got to put this price on an invoice, it’s got to do this, it’s got to do that. And like in Giga bucks case, like some of these F dens for one simple thing, go in like 15 different directions, adding to an invoice, adding to an email, adding to a text message adding to different kinds of emails, and like, all this stuff. And if you don’t keep track of the basics of that in the beginning, you can’t test it, you can’t scale it and you can’t really do anything with it. So like I think that on the most basic level, just having an inherent understanding of your F then scenarios is probably in my least in my experience, one of the cornerstones for avoiding technical debt, what do you Well, what are your thoughts on any of that?

Matt Watson 14:26
Well, I would say based on what you’re just describing, there’s four key pillars, you’ve got some sort of product, like requirements, documentation that was done in advance is that what is the thing supposed to do? Right? You’ve got customer documentation, so that potentially the developers or employees can go back and see what kind of documentation exists for the customers because that can be helpful to understand what it’s supposed to do. One of the most important things is unit testing or some form of automated testing. That can save the developers asked, right like if I’ve got a series of have tests. And maybe the developer doesn’t really understand how it all works. But he knows or she knows, if I make some changes, I can run these tests. And these tests help me validate, I didn’t break something, those are really important. And the last thing that I would say is simply tribal knowledge. And if you don’t have developers that have been around for long enough, you lose that tribal knowledge of how the system works, right? All four of those things are important. But as we talked about earlier, when you’re first starting a company, you don’t have time to perfect all four of those things, you’re just not going to do it, what you end up mostly with is probably tribal knowledge, and then probably a half assed job at one of the other three, but you’re not going to perfect all four of them, it just doesn’t happen.

Matt DeCoursey 15:43
And that’s well, that’s where when the technical debt collector, comes around, and look, this is a real like, this is a real thing, people this is and it can have a damaging effect on your business. Because if the technical debt becomes such a such a big mountain, you can’t just go through it, you can’t walk around it, it’s a it’s a long path to get around it to get over it or to tunnel through it. And so an example is, you know, you look at at Overall, like the the limited bandwidth that early stage tech companies have, maybe you have, maybe you’ve grown to the point where you have five or six developers, you want them solving problems that bring in more customers or retain the ones you have. And if they have to spend all their time, energy and emotion rebuilding all the shit that you’ve already built poorly, you’re not going to make that forward progress, because you have to have a working platform and software on the most basic level, or you run into scenarios where what you want to do isn’t even possible, because it won’t connect, or it won’t behave well, with whatever you have already constructed.

Matt Watson 16:57
Well, and somebody is talking about almost a little two different problems, right? We’re talking about scalability problems. And we’re also talking about technical debt. And these things are intertwined to some degree. But but some of it with hiring developers, essentially, this is really a scalability problem have, we had this problem at Metro Metro is 20 years old. And they’ve got two really, really, really good developers. And as the company has grown, those two are the bottleneck, right? And so it’s really hard to hire new people get them up to speed, they don’t understand all the tribal knowledge that the other two have, right. And so then on top of it, they’re dealing with a code base that’s old, that has a lot of technical debt, it’s messy, has a lot of problems, right? And it just becomes hard to even bring new people in and get them up to speed quickly, right. And add to that, if you’re using a weird ass programming language that you can’t even hire for. So that I mean, that’s the problem. It’s so technical debt is part of it. That’s but a lot of this manifests itself in scalability issues, right? Where, in as we’ve been talking about, it’s, it’s, you’re between a rock and a hard place of when you first start your company, you’re not going to do everything perfectly. But eventually these things are. Yeah, which is okay. Like I said, what you really do is you just get to a certain point, you sell it, you run away, and you let somebody else come in and fix it.

Matt DeCoursey 18:20
Yeah, I know, it’s part of part of an evolved, part of the evolved tech entrepreneur is, is being able to know that you’re accumulating technical debt and having some plan for addressing it if and when needed. I think some of it’s okay, cuz, you know, in the beginning, I’ll be the first person to tell you that it’s okay to move fast and break things. I mean, that’s just kind of the way it goes, get it out, get it out to market, get feedback on it, and have a better understanding of what you need to build and how, rather than trying to, you know, Matt, you use one of my favorite analogies earlier, just the story of the shopkeeper that never opens a store because he’s too busy cleaning it, you don’t want to be that person in the beginning, either we’ve seen that occur with, with clients we’ve had at Full Scale, and you know, they’re months behind some kind of release. And when you look under the hood, it’s because they’re sitting there mucking around with whether or not buttons should be green or blue. And, you know, the not does the button work. And some of that stuff is is kind of pertinent literally defines that example of what we’re talking about now, in the beginning, you know, like so now, what’s some technical debt that it like, you should assume that you’re gonna accumulate?

Matt Watson 19:35
Well, you’re definitely going to accumulate a certain number of bugs and architecture problems. And so by bugs, what I mean is, you know, if you go into the software and you do XYZ, it’s not going to work or it’s going to blow up or it only supports up to 100 things once you add 101 It doesn’t work, right, whatever it is. There’s some certain limitations in the software, that if you work around those, it’ll work fine and on Mostly, every software has them. Every every software product is has problems, I don’t remember, I think it was on CVS, his website or some of the other day, and I was scheduling my appointment to be tested for COVID. I think that’s what it was. And when I typed in the date, which you would think could be a pretty simple thing, if I hit backspace, you have like numbers and slashes together, and then I couldn’t type in a date. If I typed in the date, the first time it worked perfectly, but if you had to like backspace it, it was all sorts of screwed up and whatnot, seems like a simple problem. But at some point in time, you’re like, hey, type in the date the right way, the first time and it works perfect. And we’re in business, and let’s go versus like, Oh, we’re gonna have to spend a couple of weeks figuring out how to perfect this thing. The index, those are the things you deal with right now that one was obnoxious as hell and stupid, that should fix it. But as a software company, you end up stacking up a bunch of these things. And it’s just part of the deal if you run into all these known issues, and you can spend forever fixing all these little edge cases and known issues, or delivering value to your customers that they actually care about. And it’s always it’s always a balancing act of chasing this little shit that maybe doesn’t quite matter. And trying to be a perfectionist. Versus like, Ah, this thing’s got little hair on it. And we know there’s some problems like, don’t go over there don’t do that thing, versus giving the customer what they really need.

Matt DeCoursey 21:20
So I think that there’s roughly 10 to 20 key ingredients of most software platforms that if they aren’t working like, great, you have no business messing with anything else until those are right. Yes. Like we’ve been using Giga book as an example. Like, if you can’t add or edit an appointment on the calendar, we have no business doing other stuff until that’s fixed. Yeah, part of part is like really determined. And it’s going to be different for every platform, like you mentioned, like, if you have a date picker that you can’t add a date to, and an appointment, anything, it’s useless, it’s completely useless, you have no but if you don’t want other stuff, but if you

Matt Watson 21:59
don’t like how it uploads a photo for the type of appointment, and it doesn’t resize it, or crop it the right way, or the photo size is too big, it doesn’t downsample it. So the photo is smaller and more lightweight, and it doesn’t work perfect, like, but it still works. Right at some point. So

Matt DeCoursey 22:14
and that’s what you weigh. And you know, I’ve run into this, you know, still using Giga bucket as an example. We have one tester on the team, who’s been with the platform for the life of the platform, and he really likes finding bugs, but some that at one point, we had to say like, Hey, dude, some of these are like way fringe like like, there’s no point in trying to solve for this, because it would be like, if you entered something, deleted it three times and went back to do it again, you may have to refresh the page. You know, but but then we start looking at it, we’re like, how often can or could that or would that even occur? That’s the kind of technical debt that I’ll leave, I’ll leave. That’s more like, I don’t know if that’s even technical debt. That’s like the technical debt jar of coin sir

Matt Watson 22:59
bug. There? No, this is above bugs, right? Yeah. And so earlier I talked about the other big category is architecture issues. And when I say architecture issues, that usually gets into like scalability problems, right? Like, take Instagram as an example. You know, they’re like, Okay, how do we build this and scale to handle 100 users or 1000 users or 10,000 users? Right? Whenever you’re designing, or 100 million, right. But when they first started out, they had to make some sort of architecture decisions around? How far will this scale? How will it perform what happens, right? Well, they, I mean, they had dreams of it, getting to a billion users or whatever. But when they first started out, they had to pick some sort of goal. And they knew there were issues, they know, like, oh, this will work really well, until x, when we hit X, these things are all going to break. And what’s funny is, you know that certain things are gonna break, but then there’s a bunch more that you don’t know, right? You think this is this thing is going to work until it doesn’t. And that’s, that’s another part of the technical debt and kind of scalability problems you run into as a young startup, you, you only know you don’t know what you don’t know, to some degree about these things, like you know, certain architecture decisions you make. But then there are other things that crop up and honestly, this is why people need a product like stack if I what I built is to help find these performance issues and bugs or whatever. But it’s just unknowns. You don’t know what you don’t know you’re gonna hit a brick a brick wall somewhere. And I know Giga book, you probably got some examples as to right. It’s like, oh, the calendar, calendar syncing thing works great until you run across somebody who has like 10,000 appointments, and then it fails gloriously and explodes, right? Like there’s this

Matt DeCoursey 24:39
takes forever or takes forever to complete. Yeah, you just can’t see them. So some of the things that I see early stage founders making mistakes on is okay, you heard the phrase, you know, we’ll have to cross that bridge when we exactly. You have to make some of these decisions. So some of it it’s like, you know, at some point Instagram was a day one Startup just like all the rest of ours, and it wasn’t this billion dollar acquisition or are what it is. And you know, they may very well looked at it and said, our architecture right now can support 100,000 users. And that’s that’s that evolved state of tech entrepreneurship is understanding and being able to know that the bridge is is approaching, and adequately handling it, but worrying about what your architecture is going to do, when you have a million users when you currently have 32. Exact shouldn’t be, doesn’t need to be the number one thing that you’re concerned about. And it’s a balancing act, slowing things down and spending money, it’s plate spinning, you know, like, and that’s part of what you have to realize. And another thing you need to realize, Matt, is that today’s episode of Startup Hustle is brought to you by FullScale.io, helping you build a software team quickly and affordably. We’ve built a whole company around trying to help other tech companies do a better job at succeeding when it comes to scaling their development plans. And so much of that is about finding experienced people that have already have already been exposed to technical debt and other projects. So hopefully, they aren’t creating it for you. But you know, there’s another thing you said. So I’ve learned, I’ve learned definitely, this one thing in the last 12 plus years of doing this tech stuff, is that all software has bugs, and that that’s actually two things. But those are the two things that and I say that a lot. But and you know, there are I just I just Googled this to make sure I was looking at because someone had brought up an example. You know, when Microsoft Word was launched, it had 30,000 known bugs, you know, it was like, I mean, and some of that just didn’t matter. And some of that’s like icebox and way in the back and just not something you’re paying attention to, but not being able to open or something like that. It’s a critical error. That’s what you got to look for.

Matt Watson 27:05
I was at CVS yesterday, and I don’t know if you’ve been to one recently, but they added self checkout, which is like my favorite thing in the world. And at my CVS down the street, they’ve got two self checkout kiosks. And guess what one of them yesterday, didn’t work. It’s got big old software on it. It happens, whatever is current, I just use the other one to move on. Right? It’s it’s inevitable, like software just breaks it just

Matt DeCoursey 27:32
when I see big box prod products, and they have an error or an issue. I just kind of chuckle. I mean, honestly, it kind of makes me feel better. Like okay, so what happens to everyone? Absolutely, yeah, that’s just, that’s just the way it goes. All right. So, you know, one of the things that I want to get back to about the importance of like, technical debt, and knowing when you when it exists, is you know, it can create that opportunity cost, meaning the absolutely to do other things, and then in some cases, so I ran into this with Giga buck, and I’m not gonna say who but at the time, we were still really early in our process. And we had a very small team, you know, we had there was like, the whole entire company was five people and, and we had done a really good job of marketing ourselves. And I had the opportunity to do business with two really big clients and to like, well, one was a city and the other was a huge furniture chain. And the problem that I had was we hadn’t fully addressed all of the technical debt problems yet. So what was what happened was, when we needed to fix or change a few things, we weren’t able to be agile enough to do it, to get either one of those clients into our platform. And that created that was opportunity cost to find meaning we had let the technical doubt accumulate to the point where we weren’t able to make changes or updates fast enough to accommodate either one of these like Mega clients. Yep. And we came in second place out of a whole bunch of other companies. And the companies that got the business, we’re just bigger, more established places, because they were a day had a better handle on it, even though they liked our product more. We lost confidence from the potential users and big users that we would be able to support it. Yep, change it or build it. And you know, that’s like, that’s the worst feeling of all, by the way.

Matt Watson 29:31
Well, here here’s so opportunity. I’m it’s so funny, you brought this up as a topic because it’s exactly the one I was thinking about we hadn’t talked about. And let’s take another good example of that. Think about like Facebook when it first started, right? It started off at at Harvard, right and went college to college to college. So at some point in time, it’s about market share and a race, right? It’s a race to capture market share, right? Where if they it’s a balancing act, because at some point in time, whatever little thing that Zuckerberg threw together was only going to scale so far, right? So it does at some point does he have to stop and say, Look, we can’t bring on any more colleges because I’ve got to make this thing scale? Or are we going to run the race as fast as possible to go capture market share as fast as possible, right? Knowing that you could be living dangerously, and you’re going to hit a brick wall at some point in time where this thing’s not going to scale. And when you’re in those early stages of startup, sometimes that’s the fine line, you have to walk down. And it’s all comes down to opportunity costs. And it can be a race to get market share and who’s gonna win or not?

Matt DeCoursey 30:35
Yeah, and that’s a, you know, that’s a very similar to, you know, what I just mentioned, and, you know, it’s like, I don’t know, and these, these things are, they’re gonna happen, you know. So, you know, while we’re talking about how to avoid technical debt, I mean, what’s your like? What’s your if you think about if you sit down? Alright, so here we are, you’re over 40. Now, dude, so you’re getting old like me. But that means that we are more experienced. And we’ve learned a few things. When you go back and look at like the things you could have, should have or would do differently if you started something over new, like, Where would that begin?

Matt Watson 31:15
Well, to me, it’s sort of like everything almost similar to startups, right? You look at you look back at a startup or Giga book, whatever it is a certain point in time, you’re like, Man, I can’t believe we did X or Y at that point in time. But generally speaking, you make the best decision, you can at the moment with the information you have just like as a developer, or just like as a startup making a business decision, right. And so as a developer, you know, when I created something using Microsoft Azure seven years ago, that was the best way to do it the way I did it. Now, today, Azure has no longer supports the way I designed it. So now it’s technical debt, and I’ve got to change how it works. But when I made it, then, based on you know, all the knowledge I had, it was the right way to do it. And the problem is, at some point in time, things just changed. They changed what the trends are, you made the best decision you could make at the time. But things just change over time. And ultimately, we find better ways to do things. But when you made the decision, hopefully, you you made the best decision of the way to do it at that time.

Matt DeCoursey 32:19
I think if you have the ability to try to create your product, roadmap and timeline like it, and you have to really, really, really try to consider and think about what you might need or want something to do later. And which is a challenge because sometimes you just don’t know until you get that feedback. But I think that that’s the importance of getting something out early by talking to users, I think one of the things like you know, we’ve been picking on Giga buck a little bit on this, but, you know, we could have done a better job in the beginning of really going out and trying to target the end user, like we, you know, is able to, we were able to build and plan for 80% of it based on the knowledge we already had as business owners and stuff like that. But what we didn’t do is go out and talk to a wide enough swath of potential users that would have found different importance in different things. And that’s the thing that is also challenging to do, because you can talk to 10 different business owners that own 10 businesses that from the outside looking in appear the same and they do things 10 different ways. So you know, so much of that is a challenge. But if you have an idea, like for example, like if you know, you want to add payment collection, and having you know, because having that future product roadmap, a little more established, it will help the build in the beginning phases of it to know that you’re going to you need or want or will be connecting to multiple sources of incoming data or stuff like that. I think that, you know, building software 10 years ago is so much different than it is now because now we’re in this like World of hyper connectivity. So how are you going to get how are you going to bring in just some of its like data, data planning, you know, you’re gonna, you don’t tell Google how it’s going to give you anything. You build your shit to accommodate the way Google is going to give data or input and you know, that kind of planning and like, how do you make all this data job, there’s a lot of mapping and just weird shit. And really, in the end, it’s just product management. But I think as a startup, you’re oftentimes just trying to keep your head above water and it’s easy to get away from you may have a product timeline in the beginning, but you lose that agility. You become that that flat footed fighter or athlete that’s not literally on their toes.

Matt Watson 34:51
Yeah, at some point in time, it’s like, what is good enough, right? It works. It works and I was on Amazon On earlier in like AWS, and never a pretty UI looks great, right? But I need to go in and change my email address from stock fighter Netro. And for whatever reason, when I click the link to do that, it brings up some ugly ass page, it doesn’t look like anything else in Amazon. And I guess that’s technical debt, they never updated the style of it. But you know what the page worked and nobody gives a shit. It just works, right? And no doubt Amazon as big as they are, have got a whole laundry list of things just like that. But it just works, right. And you would be amazed behind the scenes and a lot of big companies how shitty their technology really is. And they hold it all together with like Excel and spreadsheets and goofy shit. And I want to give out a shout out to the guys from lollipop remember them? They’re like a whole frickin business on Google spreadsheets that today still blows me away is the most complicated thing I’ve ever seen in Google Spreadsheets. That was absolutely beautiful. But they made it work. Like somehow or another, they made like a whole business with software business with Google Spreadsheets and made this shit work. And they can always then make it more complicated later, right? I’m still impressed at what they were able to do.

Matt DeCoursey 36:16
Yeah, and that’s when that’s that Buy, buy versus build. And, you know, we

Matt Watson 36:20
yeah,

Matt DeCoursey 36:21
we have either either talked about that already, or we will in the coming episodes talking about lack of product planning. There you go. Our own 52 part series is sometimes lacking the planning. But you know, another thing I that I think is important when it Alright, so you can put yourself in weird situations where you have to accept technical debt, meaning like, you’re like, Hey, it’s 50 cents or nothing, you know, and like, that’s the equivalent of like, and so that product timeline, it can easily be interrupted, because maybe one piece of it goes through, maybe it’s just simply on time, maybe it’s ahead or certain things slow down. One of the things as as a tech founder, you’re going to have to realize is that oftentimes you can’t. So it’s not just always a, b, c, d, sometimes if c is slow, it’s going to completely disrupt D, E and F and then sometimes you can continue to operate step see, maybe it looks like the Deathstar before it’s completely finished, but it can still blow up a planet, right? It can still it’s still somewhat operational is that back to that juggling act of figuring out what you can get away with and what you can’t really in the end? I think that, for me, it’s an I’ve heard, I’ve said this too many times, hey, it doesn’t work. Yeah, does it work? It works. Okay, then let’s move on. Now, I’ve also been the driver of, of much accumulated technical debt. So now I’m out one of the things that I see a lot at Full Scale is that, you know, I see a lot of teams that are incoming teams that don’t have any testing protocol, and he like QA is that is that the best way to accumulate unknown technical debt is to just simply not have people that look for it and calculate it.

Matt Watson 38:18
You know, it’s a double edged sword. I mean, I’ve probably told you this before, but we sold VinSolutions, and didn’t have a QA team or a product management team and a bunch of other things. But part of it was I knew how all this shit was supposed to work. And it was all in my head and whatever. But I don’t scale either, right. So when I left, they had to probably hire 50 people to figure all this shit out. Like I said, you just sell the company and run away, and then they have to solve these problems. It works. But testing absolutely helps. And that’s why I mentioned it was probably one of the one of those kind of four pillars along the conversation earlier, especially if you have automated testing, because at least you have some automated testing to help validate, like how things are supposed to work. So at least if somebody screws something up, you know that you broke like, it’s supposed to work this way, right. But I think QA in general is helpful and QA a lot of times are experts on the product, they know how the product is supposed to work, the features, the functionality, all that stuff, they become product experts, if you have really good QA people, and they contain a lot of that tribal knowledge as well about how the product is supposed to work.

Matt DeCoursey 39:24
And that’s that, you know, that I still feel like the avoidance of tribal knowledge, like and we can, that there’s different kinds. There’s the spoken kind and there is like I don’t I mean, I’ve never been I’ve never been a huge advocate of like over documentation, meaning like you have as many people that are writing documents about your ship because the thing is, when you write documents, if you’re not willing to keep up with them, then they’ve just they become obsolete in a hurry. So you got to and you know, there’s a lot of there’s a lot of interesting products and things out there. The world of technology has probably created some thing that, that moves that needle forward. Alright, so, before we do the founders freestyle, just quick reminder that today’s episode Startup Hustle is brought to you by full scale.io, let us help you build an amazing development team, like the team you want, not just the team you can afford, that’s part of what we help where they will help you do it quickly and affordably and courteous, and provide a lot of the background structure that it takes to be successful. So now early in the end, as we kind of sum up today’s episode and the content within I mean, what’s the best advice for avoiding technical debt? I know, we just mentioned a few things, but like, you have to pick one,

Matt Watson 40:40
I think the key is you’re not going to avoid it. And you just have to understand what it is. And we talked earlier about like opportunity costs, and you have risk as well. And it’s just trying to understand what what is your opportunity cost, right, we can spend forever perfecting this thing, versus what is the customer need, what’s going to bring revenue to the customer or you know, to to the business and make the customer happy, all those things. And it’s always a balancing act. And ultimately, you’ve I always say there’s things you have to do you need to do, and you want to do right. And technical debt sometimes fits in all three of those buckets. But the point is, you’ve got to balance all three of them, you’ve always got to be paying down the technical debt a little bit at a time, but you can’t put all of your attention on it. And I’ve got a developer on my team. Now that drives me crazy, because he’s like that perfectionist guy. And he will literally never ship a product because he would never he’s the guy that would never open the restaurant. And him and I don’t see eye to eye a lot of times as you can imagine. But sometimes we create a healthy balance between the two of us. So I like to move fast and break things as you would say, he likes to not move at all and not break anything. And neither one of those are probably good on the extreme. Somewhere in the middle is better, but you just have to understand it’s part of part of the of the business of what happens.

Matt DeCoursey 42:01
I recently had someone refer to that as gold plating. Yeah, meaning like, you get these people that they they want a gold plate, everything and not everything, the very few things, and almost no things to be honest, are truly worth gold plating. So when you sit there and you try to make everything perfect, it really can slow things down. I mean, I think for I think for me, the I think if I have to give the best advice is to just really try to develop a sense for what is acceptable and what isn’t. You know, like there are there are and some of that’s a feel thing, you know, it’s like, like I said, I’ll be the first person that’s like, does it work? Cool. Ship it, you know, and here’s at the same time, but at the same time, like you got to know what, you can’t just be in the habit of doing that every single time. I got a great example. What if you do that though, as a founder and the leader, if you’re that guy or gal, and you’re just always like, ship it, ship it, ship it ship it, that you can’t get pissed or upset or frustrated when think when the car breaks down on the middle of the highway?

Matt Watson 43:16
I got a great example of this. And it’s with Full Scale, right? We’re in business. We’ve got 200 employees. We don’t have an automated invoicing system.

Matt DeCoursey 43:25
Nope. But it works. today.

Matt Watson 43:28
We it works. Right? Yeah, it’s manual work. We go through spreadsheets, whatever and do invoicing, review it all, but it works. Right? Like that doesn’t prevent us from being in business. It’s somewhat technical debt or it’s a scalability issue at some point in time, it gets painful enough that you’ve got to solve it. And I think that’s the key is trying to get what is the level of pain associated with these things?

Matt DeCoursey 43:52
Yeah, and that’s and you know, and that’s a that’s a bandwidth issue. Because in some cases, like, for example, there are out of the box products that will invoice certain things automatically, but there’s some, a little bit of complexity to what we do and how we do it that makes that a little less straightforward. And then some of it’s just the reactionary you know, the company has grown so fast, it’s like getting strapping things down. It’s like a pickup truck, on the highway, you know, with in the back and a strap comes loose and it’s, you know, flailing around in the wind. It’s like, you know, can you manage that or do you pull over do you do a lot of different things. And I mean, you know, I recently asked the question, and the Startup Hustle, Facebook chat is there. Is there such thing as a business having good problems, and I got we got a unanimous, yes. Now, ask the person that’s fully immersed and experiencing the problem. They may have a different answer, but you have to basically get come to an agreement. with yourself about what’s acceptable, and that’s, I mean, that’s my best advice is like, just try to gain an understanding. I think if, if what you’re working on and what you’re fixing, doesn’t bring you new users or keep the ones you have, then you’re probably focused on the wrong stuff.

Matt Watson 45:14
So I like the idea of the works, that works. And I like the idea of applying the pain index, right? How much pain does this cause? And does it cause our employees pain or customers pain?

Matt DeCoursey 45:27
Yeah, and that’s, that’s the opportunity costs. I’m picturing that thing at the doctor’s office that has the like, one to 10. And they’re like, point at your number of pain point. You know, and if you’re like, at a two or three, they’re giving you an aspirin, like, you know, but uh, you know, by the time you get up to the top, they’re like, Okay, we’re gonna, we’re gonna just put yet we’re gonna just knock you out for a while. So you want to avoid that. Well, another great episode. For those of you interested in building your software team, go to full scale.io We’d love to help you out. We can give you a lot of good advice about, about the approach pattern to building an effective team. And you know, like, like I said, there’s no such thing as a business without problems. And there’s no such thing as a software as software that bugs so at the end of the day, give yourself a little bit of a break. It’s completely unavoidable on some levels, and then some of it is not, I’ll see you next week.

Matt Watson 46:20
See? Thank you.