Dan Martell - April 04, 2022


Rewrite Your SaaS Code (The Simple Way)


Episode Stats

Length

11 minutes

Words per Minute

192.71704

Word Count

2,191

Sentence Count

101

Misogynist Sentences

1

Hate Speech Sentences

2


Summary

Summaries generated with gmurro/bart-large-finetuned-filtered-spotify-podcast-summ .

Transcript

Transcript generated with Whisper (turbo).
Misogyny classifications generated with MilaNLProc/bert-base-uncased-ear-misogyny .
Hate speech classifications generated with facebook/roberta-hate-speech-dynabench-r4-target .
00:00:00.120 Hey there, I'm Darren Martell,
00:00:01.120 serial entrepreneur, investor, and creator of SaaS Academy.
00:00:03.720 In this episode, I'm gonna share with you
00:00:05.600 the thinking process to decide
00:00:07.940 if you should do the big rewrite or refactor your code base.
00:00:12.680 I know it's the big question.
00:00:14.380 I'm gonna give you some different thoughts, some examples,
00:00:17.120 and specifically at the end, I'm gonna share with you
00:00:19.200 how to get access to my code base remodeler framework.
00:00:22.800 It's a worksheet that not only talks about the metrics
00:00:25.160 you should be monitoring to know if it's a today thing,
00:00:28.040 It's gonna talk about the prioritization strategy
00:00:31.800 that I teach my coaching clients,
00:00:33.040 as well as the five rules to make sure you don't end up
00:00:36.760 back in the same place that you are now
00:00:39.240 as you rewrite or refactor your whole code base.
00:00:42.680 Let's get into it.
00:00:44.000 So fun fact, most people don't know this, but I started my career as a developer.
00:01:00.680 I'm technical. I used to write code. I wrote code for over a decade. I taught myself how to
00:01:06.000 code when I was 17. I started in Perl, did ColdFusion for some of you OGs around, eventually
00:01:11.920 .NET, Microsoft Stack, and kind of fell in love with Ruby
00:01:16.080 and Rails and kind of, you know, web and all that fun stuff.
00:01:19.940 But my first few companies, we did a lot of work
00:01:23.000 refactoring, recoding, and really rebuilding new platforms
00:01:28.260 for a lot of the world's largest companies, the Fortune 500.
00:01:32.240 So I have the experience of like what they said
00:01:35.200 it would take, you know, in regards to the engineering team
00:01:38.100 on their team, our team, versus what happened
00:01:40.360 because I was managing these products.
00:01:41.640 I probably did, you know, 12 rewrites in my career
00:01:45.040 over a four-year period.
00:01:46.260 So I have like 10,000 hours of experience
00:01:49.300 and I had to extract and build my own methodology
00:01:52.080 for when it makes sense versus when it doesn't.
00:01:55.140 When does a refactor process,
00:01:57.320 which is not throwing away everything old,
00:01:59.900 but slowly cleaning up and modernizing your code base
00:02:03.740 makes more sense.
00:02:04.980 And if you're non-technical, this can be a big question.
00:02:07.680 It's literally, you know, when you've got like,
00:02:09.900 do I put off launching anything new to my client base
00:02:13.520 for what your developers say will six months,
00:02:15.640 which I've discovered is probably more like a year
00:02:17.540 or even worst case, two years, sometimes three years.
00:02:20.680 Most people forget, you know,
00:02:22.100 Netscape went through a five-year period
00:02:24.740 before they launched their next version
00:02:27.420 because they kept trying to stick everything into it.
00:02:31.000 And then, you know, I've gone on
00:02:32.440 and I've built Flowtown and Clarity
00:02:33.940 and I've had to do big, big refactoring projects there,
00:02:37.980 but I never went through the rewrite, okay?
00:02:40.160 So, and the reason why is I believe that if there is,
00:02:44.700 if your core data structure is gonna stay the same, okay?
00:02:48.260 And there have been situations, we bought a company
00:02:51.100 and when we looked under the hood, you know,
00:02:53.480 we realized there was no referential integrity
00:02:57.060 in the data structure.
00:02:57.960 There was no, it wasn't a relational database.
00:03:00.640 It was kind of like this flat file with keys
00:03:02.520 that were hard-coded in the front-end code.
00:03:04.100 And in those cases, we decided to rewrite it.
00:03:07.140 but for the most part, you're gonna wanna refactor.
00:03:10.600 Now, what you may not have experienced
00:03:12.460 is how to think through that process.
00:03:14.600 And that's what I wanna dive into
00:03:16.060 to save you hundreds of thousands of dollars
00:03:18.780 and years, not even months,
00:03:21.140 years of not having a competitive product in the market.
00:03:25.520 So let's get into it.
00:03:27.140 Number one principle is love your legacy,
00:03:29.360 your legacy code, the current code.
00:03:31.440 If you have any kind of revenue and customers
00:03:34.160 and you're debating if you should rewrite it,
00:03:36.380 you should first off acknowledge that this code
00:03:39.700 has got you to a place where you have revenue
00:03:41.240 and you have a team and this is a tough decision
00:03:43.300 because if you didn't have those,
00:03:44.460 this wouldn't be a tough decision.
00:03:45.760 You would just decide to rewrite it.
00:03:47.300 So not only should you love your legacy,
00:03:49.900 you should understand that there's certain parts of it
00:03:52.520 that are good.
00:03:53.860 And I know, you know, maybe it's your part-time CTO
00:03:57.400 or your contractor or even your co-founder,
00:03:59.860 you know, technical people will always come in and say,
00:04:02.800 we can't do this because we don't have a modern platform.
00:04:04.660 We can't do this because of that.
00:04:06.280 If you don't have glaring data concerns
00:04:09.980 on the core data structure or security vulnerabilities
00:04:13.840 that can't be fixed through upgrading different components
00:04:17.320 in your code base, then it is very unlikely
00:04:20.420 that you need to do a full rewrite.
00:04:22.620 Instead, consider a refactor
00:04:25.820 and understand that there's ways to pull out.
00:04:28.640 I'm gonna get into it.
00:04:29.640 Pull out the feature sets to allow yourself
00:04:32.140 to refactor the code base in smaller chunks.
00:04:34.980 But the first principle is just know
00:04:36.840 that you should love your legacy code.
00:04:39.220 Number two is think small.
00:04:40.660 So most people think I'm going to refactor this whole thing.
00:04:44.580 And then what you do is you start working down that path
00:04:47.660 and you start looking at like other features
00:04:49.680 you could sneak into the roadmap.
00:04:51.480 And you know, so it's not even like I've got to rewrite
00:04:53.880 all the features that I currently have
00:04:55.280 and make sure I have feature parity.
00:04:56.880 But now you're like thinking of like innovation.
00:04:59.200 So it's like, ooh, what if we had this?
00:05:00.960 How much more time would it take?
00:05:02.040 And then your engineers will say like two weeks.
00:05:04.200 And it's not two weeks, it's six weeks.
00:05:06.100 And it's not even six weeks.
00:05:07.480 It's the fact that you just delayed the whole project.
00:05:09.980 So it's the exposure of not being in market.
00:05:12.580 So what I wanna recommend is
00:05:14.140 as you're rewriting your code base,
00:05:15.980 think the smallest granular piece, okay?
00:05:19.480 I'm gonna link up a bunch of links below,
00:05:21.120 which is probably the five most powerful articles
00:05:24.340 from people way smarter than me.
00:05:26.260 If you're not technical,
00:05:27.660 I'd still encourage you to read these articles
00:05:29.420 because it will help you understand
00:05:31.720 why you should focus on a rewrite, not a re,
00:05:34.680 sorry, scratch that on a refactor, not a rewrite,
00:05:38.480 and use that to argue back
00:05:40.400 with your engineering and technical team.
00:05:42.300 Because these are people that are way smarter
00:05:43.900 than probably anybody working on your code base,
00:05:45.960 the top minds from some of the best companies in the world
00:05:48.520 that talk about this.
00:05:49.520 And here's just proof.
00:05:50.360 Have you ever heard of like Facebook version four
00:05:53.220 and Facebook version two?
00:05:54.940 And I've seen like, man, one time I asked my coaching clients,
00:05:57.520 I have hundreds of coaching clients in SaaS Academy,
00:05:59.640 And I asked them, how many of you still have an older version
00:06:02.440 that your clients use of your code base?
00:06:04.340 And I'd say it's about eight to 10% of people
00:06:07.000 had like a classic version and then the new version.
00:06:09.900 Trying to maintain two code bases and being competitive
00:06:12.860 when you've got a bunch of kids that want a Combinator
00:06:15.320 that've got millions of dollars in funding,
00:06:17.440 you're just gonna get your butt kicked.
00:06:19.200 So think small when you go to rewrite or refactor.
00:06:23.580 Don't rewrite.
00:06:24.180 Honestly, most people listen to this,
00:06:26.220 you don't need to rewrite, you need to refactor.
00:06:28.700 Number three is focus your fix.
00:06:30.440 So I always recommend that you focus your fix
00:06:35.120 based on the thing that breaks
00:06:36.980 if you 10X your capacity today.
00:06:38.920 So all of a sudden tomorrow, boom,
00:06:40.500 great marketing strategy brought in 10 times more customers.
00:06:43.820 Ask your engineering team what breaks,
00:06:45.920 what part of the code base is gonna completely melt.
00:06:49.800 Focus your fix on those areas.
00:06:52.240 And the way you do that
00:06:53.320 is you think about like remodeling a house.
00:06:55.360 I don't tear down the whole house
00:06:57.260 to change the kitchen, right?
00:06:59.680 I work on the kitchen.
00:07:01.300 And I wouldn't even start on the kitchen
00:07:02.940 because the kitchen's a place
00:07:04.060 where people need to eat and live.
00:07:05.800 I might start with a bathroom remodel
00:07:07.480 and then some bedroom remodels
00:07:08.680 and maybe the basement
00:07:09.500 and maybe the living room.
00:07:10.800 And then maybe after I got really good
00:07:12.920 at remodeling those areas,
00:07:15.020 because it's a skillset
00:07:16.040 that your engineering team
00:07:16.920 may not have experience on,
00:07:18.520 then we're gonna attack a bathroom
00:07:20.940 or the kitchen where the food is made
00:07:24.420 because that's gonna be a very big disruption.
00:07:27.840 But I always ask myself,
00:07:29.740 where will this thing fall down
00:07:31.860 if we 10X in the load or the capacity of our system?
00:07:36.320 And that's where we wanna focus our fix.
00:07:38.340 Number four is be quiet.
00:07:39.860 That's the nice way I say it.
00:07:41.480 Normally I'd say shut the F up.
00:07:43.040 And the reason why is so many of you are building products
00:07:46.780 and rewriting or coming out with new versions
00:07:49.560 and you start talking about it
00:07:51.880 and you start talking about all the cool stuff
00:07:53.840 and you use your events as like launch pads
00:07:56.980 to tell everybody how amazing
00:07:58.560 your next version is gonna be
00:07:59.740 or partners are upset because it's totally buggy
00:08:02.480 and you use that as the answer
00:08:03.640 and what happens is you now have made a commitment
00:08:06.520 and there's no way to work backwards.
00:08:08.280 I would highly recommend that you just keep iterating
00:08:11.120 and creating a process to improve
00:08:13.420 and not make it about a big event
00:08:15.720 and just make it a cultural thing that you do
00:08:19.100 of just coming out with new versions, right?
00:08:20.860 And improving the code base
00:08:22.180 And think about like, to me, when I think of product management, there's three core areas.
00:08:26.360 There's the business needs, there's the customer's needs, and then there's technical needs.
00:08:30.400 And all three need to be considered in regards to the limited resources we have on our engineering teams
00:08:35.040 to focus solving those three core areas.
00:08:38.320 So it can't be just business needs all the time.
00:08:40.700 And it can't just be, you know, paying down technical debt.
00:08:43.760 It has to be all three considered and be quiet when you're doing this
00:08:48.240 so you don't set expectations that you can't pull back
00:08:50.840 from with your client base, okay?
00:08:52.900 So that's number four.
00:08:54.300 Number five is respect your life cycle.
00:08:56.720 So in the software world,
00:08:58.820 there's a thing called software development life cycle,
00:09:01.020 and it is everything from how you decide
00:09:04.300 what you're gonna build, how you build it,
00:09:06.100 how you test it, how you quality assure it,
00:09:09.500 how you push it out to production, okay?
00:09:11.860 So that's everything from like your Scrum.
00:09:13.520 If you've never heard of Scrum, go check that out.
00:09:15.180 Agile development is usually probably
00:09:16.840 the most standard, maybe you're doing some pair programming,
00:09:19.700 that kind of stuff, but you know, it's your code base,
00:09:22.020 it's your Git flow, check that, those terms again,
00:09:24.560 I'm gonna link up some of my favorite resources below,
00:09:26.520 and your CICD, your continuous integration,
00:09:29.200 continuous deployment process, you know,
00:09:31.700 and I can usually tell people's maturity of their code base
00:09:34.900 based on the frequency that they push to production
00:09:37.840 and test coverage that they have on their code base.
00:09:40.460 If you don't have those things figured out,
00:09:42.160 then you probably don't have a good life cycle,
00:09:44.320 And I would highly recommend that you not only implement it,
00:09:48.080 but respect it, especially if you're the founder
00:09:50.840 and not push people out of fast, you know, hot fixes.
00:09:54.940 If you have a conversation with your team every week
00:09:57.000 about hot fixes, then you're clearly moving way too fast.
00:10:01.020 You need to slow down to fix and respect your life cycle.
00:10:03.840 So quick recap, five areas to look at
00:10:06.900 when you're considering rewriting
00:10:07.980 versus refactoring your code base,
00:10:09.960 which I recommend refactoring is number one,
00:10:12.200 love your legacy.
00:10:14.000 Number two, think small.
00:10:15.860 Number three, focus your fix.
00:10:17.640 Number four, be quiet.
00:10:19.660 Don't tell your customers.
00:10:21.040 And number five, respect your life cycle.
00:10:24.160 As I mentioned at the beginning of this episode,
00:10:25.660 I wanna share with you an exclusive resource.
00:10:27.640 It's my code-based remodeler worksheet.
00:10:30.360 It's a framework to think about the, first off,
00:10:33.300 the five key metrics you should be monitoring
00:10:35.720 to tell you what's breaking in your product.
00:10:38.040 Where should you be focusing your time?
00:10:39.740 I'm also gonna share with you the prioritization framework
00:10:42.380 that I use to understand how to refactor,
00:10:46.020 or sorry, yeah, refactor your code base
00:10:48.840 in the right sequence.
00:10:49.900 And then finally, the five principles of development
00:10:54.260 so that you can avoid getting back
00:10:56.240 into this exact same spot that you found yourself in
00:10:59.240 into the future, because if you don't fix that,
00:11:01.400 then you're just gonna rewrite or refactor your code base
00:11:04.220 and end up in the same place in two or three years.
00:11:07.080 So be sure to click the link below
00:11:08.860 to download your copy of my code base remodeler.
00:11:12.040 And if you like this video, be sure to subscribe,
00:11:13.680 leave a comment and click that like button, smash it.
00:11:17.640 And as per usual, I wanna challenge you
00:11:19.080 to live a bigger life and a bigger business
00:11:20.660 and I'll see you next Monday.