- Hey, there, I'm Dan Martell,
serial entrepreneur, investor, and creator of SaaS Academy.
In this episode,
I'm gonna share with you the thinking process to decide
if you should do the big rewrite,
or refactor your code base.
I know it's the big question,
I'm gonna give you some different thoughts,
some examples and specifically at the end
I'm gonna share with you how to get access
to my code base remodeler framework,
it's a worksheet that not only talks about the metrics
you should be monitoring to know if it's a today thing,
it's gonna talk about the prioritisation strategy
that I teach my coaching clients, as well as the five rules
to make sure you don't end up back in the same place
that you are now as you rewrite,
or refactor your whole code base, let's get into it.
(upbeat music)
So fun fact, most people don't know this,
but I started my career as a developer.
I'm technical, I used to write code,
I wrote code for over a decade.
I taught myself how to code when I was 17.
I started in Pearl,
did ColdFusion for some of you OGs around,
eventually .NET, Microsoft Stack,
and kind of fell in love with Ruby and Rails and kind of
web and all that fun stuff.
But my first few companies,
we did a lot of work refactoring, recoding
and really rebuilding new platforms
for a lot of the world's largest companies, the Fortune 500.
So I have the experience of like
what they said it would take,
in regards to the engineering team on their team, our team,
versus what happened because I was managing these products.
I probably did
12 rewrites in my career over a four year period,
so I have like 10,000 hours of experience
and I had to extract and build my own methodology
for when it makes sense,
versus when it doesn't, when does a refactor process,
which is not throwing away everything old,
but slowly cleaning up and modernising your code base,
makes more sense.
And if you're non-technical, this can be a big question.
It's literally, when you've got like,
ah, do I put off launching anything new to my client base
for what your developers say will six months,
which I've discovered is probably more like a year
or even worst case two years, sometimes three years.
Most people forget,
Netscape went through a five-year period before they launch
their next version because they kept
trying to stick everything into it.
And then I've gone on and I've built Flowtown and Clarity
and I've had to do big, big refactoring projects there,
but I never went through the rewrite.
And the reason why is I believe that
if your core data structure is gonna stay the same
and there have been situation, we bought a company
and when we looked under the hood
we realised there was no referential integrity
in the data structure.
There was no, it wasn't a relational database,
it was kind of like this flat file with keys
that were hard coded in the front end code.
And in those cases we decided to rewrite it,
but for the most part, you're gonna wanna refactor.
Now, what you may not have experience
is how to think through that process
and that's what I wanna dive into
to save you hundreds of thousands of dollars
and years, not even months,
years of not having a competitive product in the market.
So let's get into it.
Number one principle is love your legacy, your legacy code,
the current code.
If you have any kind of revenue and customers
and you're debating if you should rewrite it,
you should first off acknowledge this code
has gotten you to a place where you have revenue
and you have a team and this is a tough decision
because if you didn't have those,
this wouldn't be a tough decision,
you would just decide to rewrite it.
So not only should you love your legacy,
you should understand that there's certain parts of it
that are good and I know, maybe it's your part time CTO,
or your contractor, or even your co-founder,
technical people will always come in and say,
"We can't do this 'cause we don't have a modern platform.
We can't do this 'cause of that."
If you don't have glaring data concerns
on the core data structure, or security vulnerabilities
that can't be fixed through
upgrading different components in your code base,
then it is very unlikely that you need to do a full rewrite,
instead consider a refactor
and understand that there's ways to pull out,
I'm gonna get into it,
pull out the feature sets to allow yourself
to refactor the code base in smaller chunks.
But the first principle is just know
that you should love your legacy code.
Number two is think small.
So most people think,
"I'm going to refactor this whole thing."
And then what you do is you start working down that path
and you start looking at like other features
you could sneak into the roadmap and
so it's not even like I've got to rewrite all the features
that I currently have and make sure I have feature parity,
but now you're like thinking of like innovation.
So it's like, "Ooh, what if we add this?
How much more time would take?"
And then your engineers will say like, "Two weeks,"
and it's not two weeks, it's six weeks.
And it's not even six weeks,
it's the fact that you just delayed the whole project,
so it's the exposure of not being in market.
So what I wanna recommend
is as you're rewriting your code base,
think the smallest, granular piece,
I'm gonna link up a bunch of links below,
which is probably the five most powerful articles
from people way smarter than me.
If you're not technical,
I'd still encourage you to read these articles
'cause it will help you understand
why you should focus on a rewrite,
not a re, sorry (chuckles),
scratch that, on a refactor, not a rewrite.
And use that to argue back with your engineering
and technical team
'cause these are people that are way smarter
than probably anybody working on your code base,
the top minds from some of the best companies in the world
that talk about this.
And here's this proof,
have you ever heard of like Facebook version four
and Facebook version two?
And I've seen like,
one time I asked my coaching clients,
I have hundreds of coaching clients in SaaS Academy.
And I asked them,
"How many of you still have an older version
of your client's use of your code base?"
And I'd say it's about eight to 10% of people
had like a classic version and then the new version.
Trying to maintain two code bases and being competitive
when you've got a bunch of keys and Y combinator,
they've got millions of dollars in funding.
You're just gonna get your butt kicked.
So think small when you go to rewrite, or refactor,
don't rewrite.
Honestly, most people, listen to this,
you don't need to rewrite, you need to refactor.
Number three is focus your fix.
So I always recommend that you focus your fix
based on the thing that breaks,
if you 10X your capacity today.
So all of a sudden tomorrow, boom,
great marketing strategy brought in 10 times more customers,
ask your engineering team what breaks,
what part of the code base is gonna completely melt,
focus your fix on those areas and the way you do that
is you think about, like remodelling a house.
I don't tear down the whole house to change the kitchen,
I work on the kitchen
and I wouldn't even start on the kitchen
because the kitchen is a place where people need to eat
and live.
I might start with a bathroom remodel
and then some bedroom remodels
and maybe the basement and maybe the living room.
And then maybe after I got really good at
remodelling those areas 'cause it's a skill set
that your engineering team may not have experience on,
then we're gonna attack a bathroom, or the kitchen
where the food is made
because that's gonna be a very big disruption.
But I always ask myself,
where will this thing fall down if we 10X in our work,
in the load or the capacity of our system.
And that's where we wanna focus our fix.
Number four is be quiet, that's the nice way I say it.
Normally I say, "Shut the F up."
And the reason why is so many of you are building products
and rewriting, or coming out with new versions
and you start talking about it
and you start talking about all the cool stuff.
And you use your events as like launch pads
to tell everybody how amazing your next version
is gonna be, or partners are upset
because it's totally bugging, you use that as the answer.
And what happens is you now have made a commitment
and there's no way to work backwards.
I would highly recommend that you just keep iterating
and creating a process to improve
and not make it about a big event
and just make it a cultural thing that you do
of just coming out with new versions
and improving the code base.
And think about, like,
to me when I think of product management,
there's three core areas.
There's the business needs,
there's the customer's needs
and then there's technical needs
and all three need to be considered
in regards to the limited resources
we have on our engineering teams,
to focus solving those three core areas.
So it can't be just business needs all the time
and it can't just be paying down technical debt.
It has to be all three considered
and be quiet when you're doing this
so you don't set expectations that you can't pull back from
with your client base.
So that's number four.
Number five is your lifecycle, so in the software world
there's thing called software development life cycle
and it is everything from how you decide
what you're gonna build, how you build it, how you test it,
how you quality assure it,
how you push it out to production.
So that's everything from like your scrum,
if you never heard of scrum, go check that out.
Agile development is usually probably the most standard,
maybe you're doing some pair programming,
that kind of stuff, but it's your code base,
it's your git flow, check that, those terms, again,
I'm gonna link up some of my favourite resources below
and your CI/CD, your continuous integration,
continuous deployment process,
and I can usually tell people's maturity of their code base
based on the frequency that they pushed to production
and test coverage that they have on their code base.
If you don't have those things figured out,
then you probably don't have a good life cycle
and I would highly recommend that you not only implement it,
but respect it, especially if you're the founder
and not push people out of fast hot fixes.
If you have a conversation with your team every week
about hot fixes, then you're clearly moving way too fast,
you need to slow down to fix and respect your life cycle.
So quick recap,
five areas to look at when you're considering rewriting
versus refactoring your code base,
which I recommend refactoring, is number one,
love your legacy.
Number two, think small.
Number three, focus your fix.
Number four, be quiet, don't tell your customers.
And number five, respect your life cycle.
As I mentioned at the beginning of this episode,
I wanna share with you an exclusive resource,
it's my code base remodeler worksheet,
it's a framework to think about the,
first off the five key metrics you should be monitoring
to tell you what's breaking in your product,
where should you be focusing your time?
I'm also gonna share with you the prioritisation framework
that I use to understand how to refactor, or, sorry,
yeah, refactor your code base in the right sequence.
And then finally the five principles of development
so that you can avoid getting back into this exact same spot
that you found yourself in into the future
'cause if you don't fix that,
then you're just gonna rewrite, or refactor your code base
and end up in the same place in two or three years.
So be sure to click the link below,
to download your copy of my code base remodeler.
And if you liked this video, be sure to subscribe,
leave a comment and click that Like button, smash it.
And as per usual,
I wanna challenge you to live a bigger life
and a bigger business and I'll see you next Monday.
(upbeat music)