Dan Martell - Rewrite Your SaaS Code (The Simple Way)

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 1.00

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, 0.99

00:06:17.440 you're just gonna get your butt kicked. 0.98

00:06:19.200 So think small when you go to rewrite or refactor. 0.99

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 1.00

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. 0.99

00:07:41.480 Normally I'd say shut the F up. 0.95

00:07:43.040 And the reason why is so many of you are building products 0.95

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.

Dan Martell - April 04, 2022

Rewrite Your SaaS Code (The Simple Way)

Episode Stats

Summary

Transcript