March 23, 2025 • 32 mins
In this episode, we chat about Peter’s decision to start fresh with a new code base. He believes it can sometimes be the right move. Geoff shares his perspective, which sparked a lively discussion and gave developers some food for thought when it comes to existing projects and technical debt.
- (00:00) - Introduction
- (10:13) - Become a supporting member
- (20:19) - Get over 200 Mac Apps
- (27:02) - Support the podcast
Links:
Things You Should Never Do, Part I
Working Effectively with Legacy Code
Become a supporting member
https://patreon.com/compileswift
- flanker
- Jay Wilson
- Adam Wulf
- bitSpectre
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Peter (00:02):
What's up, everybody? Welcome to another episode of
the podcast. I am your host,Peter. Geoff is here again
today, your other host. How aredoing, Geoff?
Geoff (00:10):
I'm doing just great. Been working on a lot of
different projects and trying toship a bunch of stuff all at the
same time.
Peter (00:17):
Awesome. That's always good fun. Right? Because
everything always goes accordingto plan. Never goes wrong.
Right?
Geoff (00:21):
A %.
Peter (00:22):
So interestingly, in this one, I think we're gonna have
different opinions, which alwaysmakes, I think, for for the best
conversations, and and peoplejust like to hear us disagree.
And then they can pick sides.Right? I just wish somebody
would pick my side once. That'sjust that's all I want in life.
In this episode, I'm going to betalking about something that
(00:45):
I've been doing recently thatsparked a thought here. And it's
this idea of saying, Okay, youknow, I've got an app a game,
you've got some something you'rebuilding, right? And you realise
there's a point that you say toyourself, You know what? Maybe
the best thing to do here is tostart over. And so I want to
(01:08):
talk through that process of howI got to where I'm at and the
decision I made, and then we'llsort of go into a discussion on
it.
So some of you may know, I havebeen working on a game for,
gosh, I don't know, a couple ofyears at this point, on and off.
And it was purely a game Iwanted for me and for my friends
(01:29):
that had the idea, and it'scalled Project Hack.
Projecthack.net is where you canfind it. And I went through, and
I'll sort of break it down abit. I built the first version.
It was great. Did everything Iwanted it to, but it was only
ever meant to be the firstversion to see, number one, is
(01:51):
this going to work as an idea?Number two, can I do the bigger
plan? Now, this was a singleplayer game. It's kind of an
idle style game.
I'm not going to go into all thedetails. You can go to
projecthack.net and see itthere. You'll get the idea. But
when it came time to build outwhat I call in air quotes the
bigger, proper version, I alwayswanted it to be a multiplayer,
(02:16):
because that was one of thedriving ideas. And I was faced
with this decision.
I originally built the game inUnity back when I was learning
Unity. This is how I learned tomake games with Unity, building
this game. So as you canimagine, I did a bunch of things
wrong. And when I went back tothe codebase and looked at it,
(02:36):
and then I was like, okay. Youknow what?
I cannot save this codebase. OrI can, but I've got to basically
understand what the hell I did,like, a year ago before I can
start rebuilding it and buildingthe new stuff. That's when this
idea of maybe I should juststart over came into play. Now I
(02:58):
decided to start over. And thisalso gave me an opportunity to
go out and try a bunch ofdifferent game engines for the
same game to figure out whichone I was most comfortable with,
which one worked the best forthis game.
Again, this can apply to apps,everything. Right? And I knew
that I had learned newtechniques. I learned how to do
(03:18):
a whole lot of things betterbecause I had become a better
programmer in that time as well.And therefore, again, I was
like, Okay, you know what?
At this point, I can spendmonths and months trying to
relearn my old code base writtenwith a visual scripting language
and rebuild it in C, becausethat's what Unity uses, and
(03:39):
that's that's the route I wantedto go to to make it work for a
bunch of things that basicallyjust were very difficult to do
with visual scripting. So that'swhy I decided to start over. And
that brought us to thisdiscussion here today about the
pros and cons of doing that forsome of you who may be in the
same boat. Right? You've hitsome kind of problem, some kind
(04:02):
of wall or something.
Maybe you inherited an app.Maybe you purchased an app from
somebody else. And you'relooking at this code base now,
this foreign code base, saying,what what should I do? Should I
start over, or should I continueto, you know, try and make the
existing code base work. Sothat's the backstory here for
(04:25):
this.
And clearly, my opinion on thisis sometimes starting over is
the good way to go. But, Geoff,I I think that you have a
different take on this. Whatwhat do you think?
Geoff (04:36):
Yeah. My take is the exact opposite. That starting
over completely from scratch.I'm gonna caveat this with the
word almost, but I I feel likethat almost is entirely
miniscule, tiny middle school.Not the right thing to You
should should almost almostalmost almost never ever just do
(04:57):
a complete rewrite of something.
And let me say that, you know, II'm gonna I'm gonna eat my own
words a little bit here and andsay that, you know, I've learned
this from experience. Okay. ThatI have done the full rewrite of
things multiple times, and it itnever works. I sit here and I
go, hey. You know, this seemslike this is one of those times
(05:19):
where I should go back andrewrite this, and it almost
always is a mistake.
I think the one that I'm gonnarefer to most in this particular
conversation is going to be thebig rewrite that I did last year
of Kineo. And I I think thatthat seems like it fits all of
(05:42):
the areas where you might wantto do a big rewrite. I was
porting it to a differentplatform. I was using Apple's
newest user interface designs interms of using SwiftUI versus
UIKit. I was doing a lot of newfeatures for that app.
And still, in hindsight, Ishould not have done a clean
(06:03):
rewrite. I should have insteaddone the incremental migration
of piece by piece, breaking itup as needed, and not doing the
kind of ground up new version ofthe app for VisionOS.
Peter (06:16):
Okay. Can I ask a question there? Because I I feel
like I need a littleclarification here. Because I I
heard you say I thought I heardyou say that you were doing it
for a new platform. Right?
Geoff (06:29):
I was doing it for a new platform.
Peter (06:30):
So my question is, how is doing it for a new platform not
starting from the ground up onthat platform. Do you follow me?
Geoff (06:42):
Well, okay. So it's it's still an Apple platform.
Peter (06:45):
Oh, okay. Which means it's not like
Geoff (06:46):
I can I can reuse? Yeah. I I was porting it from iOS and
iPadOS to Visualize.
Peter (06:52):
Because that was gonna be my follow-up question was, well,
hang on. Surely you used adifferent technology. The answer
here is no. Same platform.
Geoff (06:58):
Okay. Got it. Honestly, for a lot of those things, it it
may still be true. You may stillbe able to migrate existing
stuff, but I I feel like that'smore complicated than we wanna
get into here. Okay.
So there you
Peter (07:13):
have it, folks. Right? We've got two differing
opinions, which is gonna makefor a great conversation here.
So why do you think that it isbest to, you know, take what
you've got and rework? I don'twant to use the word refactor
because I think that's wrong.
But why is it best to take whatyou've got and keep working with
(07:36):
that? Be it mistakes, bad code,bad patterns, and to keep going
with that. To me that soundslike you're burning time on
something that, okay, you mayhave all the logic in there. You
may have what the app does.Right?
So you've got essentially theskeleton of the app, and you're
(07:56):
gonna gonna reflesh it out withwith new new code, new whatever
you wanna call it. So so why doyou think that that is the way
to go?
Geoff (08:05):
I think you've just made my argument for me. Damn. Yeah.
All of these all of these thingsalready exist. And, yes, you may
have learned better ways to doit.
You may have learned a a nicerway to do it. But what you have
presumably works, at least tosome extent. And so you can
leave that there and buildscaffolding around it.
Peter (08:27):
Okay.
Geoff (08:27):
You can say, okay. I need to add this new feature or I
need to improve some existingpart of it, and you can leave
everything else in there whileyou build that. You used the
term at one point, you're, like,wasting time on this. But but I
I feel like the complete throwit out approach is itself
(08:52):
wasting time. You're wastingtime reimplementing things that
you already have, that you'vealready done.
Okay. And for that, like, yes,they may not be ideal. Nothing
is ever ideal. No code is everideal. You can sit there and you
can kind of put that behind awall.
(09:12):
You can sit there and say, thiscode, we know this code is bad,
and try to avoid touching it asmuch as possible, but it's still
there. It's still working tosome extent. And so it's worth
having that code there that youdon't have to spend time
rewriting from scratch.
Peter (09:31):
Okay. So someone in our chat room, we got a chat room on
our Discord going here whilewhile we're recording this. If
you want to take part in that,come join our Discord. We'll put
a link in the show notes. Butthey pointed out that, Oh, well,
you can take this modularapproach.
But I think that that only worksif you've got a good modular
approach to begin with. Right?And that is part of my argument
(09:51):
for why it's good to start over,is you could have a code base
that is so entwined andspaghetti bold that you just
can't unravel that mess. And Idon't mean, you know, not break
everything because chances areyou are gonna break everything.
But that's kind of the point, Iguess, in some ways.
(10:12):
Right? Hey, folks. If you likewhat you're hearing in this
podcast and you wanna help thispodcast to continue going
forward and having great guestsand great conversations, I
invite you to become a Patreonsupporter. You can go to
patreon.com/compileswift whereyou will get ad free versions of
the podcast along with othercontent. But the idea I'm saying
(10:37):
is, yes, you're throwing out thecode, but you're not throwing
out all of the problems that youhave solved, meaning the
business logic and the rules andeverything that you had in the
original app still exist.
You're just using those as thetemplate to build the new app
(11:00):
with maybe the new technology,right? I mean, I think, I will
say that I don't thinkrebuilding with the same
technology is worth it, right? Ifeel like that's kind of like,
well, you're just going to endup exactly where you were. Why
are you doing that? Right?
But I think that that's kind ofwhere I'm coming from on some of
this is sometimes trying tounravel the spaghetti is harder
(11:23):
than just acknowledging it'sthere and building it. Building
the the idea and thephilosophies behind it, but in a
newer, cleaner way.
Geoff (11:33):
Yeah. Let me tackle this a couple pieces at a time. You
said you're throwing away thecode, but you're not throwing
away the business logic.
Peter (11:41):
Yeah.
Geoff (11:42):
I think for a lot of people, the business logic is
your code. Interesting. Youlikely have not been documenting
your code to the extent like, tothe bug for bug match up of here
is everything that I've chosen,and here is every decision that
I've made, and here is thisextent. When you recreate a
(12:06):
piece of software like that, youare going to make changes. You
are gonna make things that aredifferent Unless you fully
understand your code to thepoint of in order to recreate
the business logic that you'vealready created, you're gonna
have to understand the code tothe level that you're talking
about not wanting to do in thefirst place
Peter (12:27):
Okay.
Geoff (12:28):
To to unravel that spaghetti.
Peter (12:30):
Sure. And I and I I should say here, yeah, I agree
that, you know, if you're theonly if the only rules or
whatever you want to call it,documentation, you have to
follow as to what this app is,how it does it, and how it was
built, is the code withoutdocumentation, then, you know,
(12:52):
from my perspective, you know,you're in a hard place either
way, right? You've got toreverse engineer before you can
either repair or restart eitherway. Unfortunately, it's easy to
sit here and say, Of course,none of us would do that, right?
Yes, we would We've all donethat.
(13:13):
And something that I want tothrow in here, and I'm curious
now that I think about it. Doyou have the same opinion
whether it's an app that youbuilt meaning you, your team,
whatever that may look like foryou or one that you have
inherited from somebody else?Would you say that the opinion
(13:33):
is the same on both? Given thatthis
Geoff (13:36):
I would
Peter (13:36):
say that the Sorry. Given that maybe the app that you
inherited, the code is allyou've got by way of what does
this thing do?
Geoff (13:44):
Yep. I would say in a case where the code is all
you've inherited, that almostdoubled down on, you should not
rewrite that because you havethat existing as it is. But I
would say nobody is so good tounderstand their own code
(14:04):
however long ago they wrote it.
Peter (14:06):
Right.
Geoff (14:07):
You know, there's there's the old adage of realize like,
realize when you're writing codethat the person that has to
maintain it later knows whereyou live.
Peter (14:18):
Yeah. Yeah. That's
Geoff (14:20):
true. Because it's
Peter (14:20):
you.
Geoff (14:21):
Yeah. And and and so, like, I I feel like that that is
going to be the problem. It'slike, whether it was somebody
else that wrote it or whether itwas you that wrote it, the you
in the past is somebody elsethat wrote it.
Peter (14:33):
No. Absolutely. They they, you know Yeah.
Geoff (14:36):
They they are a completely different person.
Obviously, the whole reason thatyou're talking about rewriting
this in the first place isbecause you made decisions then
that you would not have madenow. And so I don't think
there's much of a reason totreat those two things
(14:56):
differently. To say, hey. Youknow, whether I rewrote this or
sorry.
Whether I wrote this originallyor whether somebody else wrote
this originally and I'm justmaintaining it after the fact, I
I feel like those are similarenough that, no, in both cases,
I would avoid doing a rewrite.
Peter (15:13):
Okay. So to me then, that also and and and I get what
you're saying there. Right?Because if I understand it
correctly, we could say (15:20):
Hey, regardless of whatever path I
choose to take here, me sixmonths from now will be looking
at the me now with the same eyesthat the me now is looking at me
from six months ago. Right?
Yeah. No, I totally get that.Yeah. No, I understand. And
(15:41):
also, hey, you know, whatever Idecide now will be just as wrong
six months from now as it wassix months ago for different
reasons.
I I think that's what you'resaying. Right?
Geoff (15:50):
Now to go back to the idea of modularization and and
kind of unraveling the spaghettias it were, I agree that this is
generally a approach that youshould move towards and that
making things more modular doesmake it easier to do these
(16:10):
refactors as as you're goingalong. But I think that it's not
a reason to completely throw outsomething that already exists if
it is not modularized. What youshould do instead, I'm gonna
refer to a great, great book. Icame with Refactoring by Martin
Fowler, and I came with WorkingEffectively with Legacy Code by
Peter (16:34):
Michael Feathers. That's interesting. You know that
Working with Legacy Code is abook on my Amazon list to read
one day.
Geoff (16:40):
It it is such a great book. You should know why read
this book.
Peter (16:43):
And we'll folks, we'll Every we'll put
Geoff (16:45):
a link that. This
Peter (16:46):
book. Yeah.
Geoff (16:47):
Both of these books, highly recommended. You should
read both of Alright. Period.I'm trying to remember which one
in particular refers to thething that I want to refer to.
Yes.
It is working effectively withLegacy Code. It's on page 30 of
my copy. It is very early in onthe book.
Peter (17:06):
Seems. Okay.
Geoff (17:08):
Yep. So the idea being that what you do is you take
that code, that that big blob ofspaghetti code that you've
already got. You take that code.You put that in a module. That
is your one module.
You can call this modulewhatever you want. I tend in my
projects where I'm going backand doing something like this,
(17:28):
call it just core or legacy orsomething like that.
Peter (17:32):
Okay.
Geoff (17:33):
And you you put it off to the side, you wall it off. Then
what you do with that code, asyou need pieces of that code, as
you need to bring this into yourmodern architecture, your modern
rewrite, your modern whatever,you go in and you find the
seams. You find the bits of codewhere you can go, oh, I can
(17:58):
stick in a a point of injectionhere. Injection in the terms of,
like, dependency injection or orOkay. Something like that, where
I can go, I can connect to thiscode with my new code.
I I can plug in here. This isthis is my entry point. And you
go in and you find that. Andthen once you've got that seam
there, it works very much like aa I don't know. Carving a rock.
(18:21):
Carving carving something out ofmarble. You've got your chisel
in there. Mhmm. And once you'vegot your chisel in there, you
can start to pick around. Youcan pull a piece off.
And that's how you get aroundthis spaghetti code. You pull
off small pieces at a time. Youget in there. You go, oh, this
bit of business logic. I canseparate this out.
I can I can put in a connectionto it right there, and then
(18:44):
using that connection, I canstart to pry this bit out? And
now that bit, again, still kindof a self contained module,
maybe inside of it. It's not theprettiest. It's not what you
want, but you can pull thatsmall piece out into your new
architecture. And then onceyou've got that small piece out
into your new architecture,you've got a much more minimal
interface around it.
(19:04):
You've got a much smaller thing,to to have to communicate with.
And you know what you got whenyou have that small thing to
communicate with? You can writetests for it. You can write unit
tests around it. And then onceyou got unit tests around it,
you know what you can do with itthen?
Then you can rewrite that smalllittle piece. You rewrite that
small little piece. You makethat small little piece better,
(19:25):
and you've got it completelyunit tested. You've got it
separated from all of the restof your spaghetti ball, and
you've got that piece fixed.
Peter (19:35):
Okay.
Geoff (19:35):
Alright. And you do that again and again and again and
again until your core library,that library that you put down
there, you slowly chip away atit one piece at a time. At every
point, you've got working code.At every point, you've got an
app that continues to exist.You've got an app that you you
haven't had to spend all of yourtime rebuilding, and you've
(19:59):
you've you're able to makeprogress on your project as a
whole.
Oh, and so you've been able tobuild everything that you're
still doing, and you're able tomake those improvements over
time without having ever neededto step back, take a huge amount
of time to rewrite all of thesebits. Time for a break.
Peter (20:20):
Hey, everybody. It's Peter Widom here from the
compulsive podcast. I'm gonnatell you about Setapp. Setapp is
a service that provides asubscription fee of just $10 a
month, and you get access toover 200 Mac applications, and
it's also available now on iOSas part of that deal. I use the
(20:40):
service because it just has aton of really good first rate
apps that I use all the time.
And for me, it's invaluable as adeveloper to have access to
tools for things like APIs, forplanning projects, writing
emails, writing documentation.And you get all of these things,
including database apps, all ofthat kind of stuff right there
(21:03):
on the Setapp service for just$10 a month. You can use as many
or as few applications as youneed. If you're interested in
checking this out, go toPeterWidham.com, p e t e r w I t
h a m Com forward / set app, s et a p p, and you can see the
details there. And it's got alink that you can go over and
(21:25):
start using the service and seehow it works out for you.
I strongly recommend this toevery Mac user.
Geoff (21:32):
Break timed over. All at once.
Peter (21:35):
Okay. Alright. And that sounds very similar to to what
they're saying in the chat room,you know, as far as, oh, yeah.
Well, let's let's wall this offand then see, you know, I I
guess the thing for me is, like,in the chat room where they're
saying about refactor it later.And that's kind of the part that
that bothers me about.
(21:56):
This is, no, if you're going togo to the trouble now, refactor
it now. Right? But the segmentthat you're talking about,
right? Module, however you wantto phrase it, whatever it means
to anybody. And and I don'tdisagree with that.
I think would it be fair to saythat is what most of us did as
(22:18):
we migrated to Swift? Okay.Well, I'm gonna rewrite this
controller as Swift fromObjective C. I'm gonna rewrite
this view in SwiftUI fromwhatever it was, storyboard
hell. Right?
And and picking them off one byone like that because it's also
a technology that allows us todo that. Right?
Geoff (22:40):
But it it would have been silly, I think, for a lot of
people to have gone back and go,you know what? Swift is the new
thing. Swift is the new hotness.Swift is cool. What we need to
do is completely throw away allof our Objective C code, not
look at it, and build a new appfrom scratch in Swift based on,
(23:00):
what we had before.
Peter (23:01):
Okay.
Geoff (23:02):
I I I don't think that that people think that would be
a good idea. I I I was sittinghere trying to say, like, if you
think that's a good idea, you'rewrong. No. Because I think it it
is wrong. But at the same time,like, I I I feel like they're
I'm gonna have people pushingback.
They're like, oh, no. Well,That's definitely a
Peter (23:22):
good idea. This is where things get awkward because I
have to cross back over theother side of the fence and
stand with you here because thatis what I went through. Right?
And I'm still going through is,Yeah, you know what? Hey, guess
what?
Companies and that won't giveyou time to start from scratch.
You know, but So I've beenthrough that. And yes, it
(23:44):
worked, but it was extremelypainful. Because you also have
to try and pick and choose theright parts to start with. Like
you say, I do agree with theidea of, well, you know, it's
kind of like building a house,right?
Use that analogy. Let's makesure the core foundation is good
first, otherwise all hope islost. You know, and so I get
(24:05):
that. But I don't know, I thinkfor me, you know, some of the
attraction I will admit this, Ithink part of the attraction of
starting from scratch is thefreedom to choose maybe
different technologies butcertainly a different approach
(24:28):
but I also get and acknowledgethat sometimes well, just
refactoring this part first isthe way to go. Because there is
a very good argument to keep theproduct alive, but I'm also
thinking, hey, either way yougo, you're keeping the product
(24:48):
alive, right?
Because if I'm starting acompletely new app, the old one
is still there to be patched andupdated and sent out. Whereas if
I and work, you know, yeah, canmake a new branch and work on
migrating that code andimproving that code and whatever
term you want to use, but Istill have to make sure that
(25:10):
it's shippable one way or theother. Right? As opposed to
knowing that it is shippable atany moment because I'm not
touching the existing version.Does it and and I get you
probably don't agree with that,but you see where I'm coming
from?
Geoff (25:24):
I I I see where you're coming from, but the the problem
is I don't believe you.
Peter (25:30):
No. That's fine. No. As long as you understood. I'm
gonna edit this so that itsounds like you said this.
No. No.
Geoff (25:35):
Yeah. Yeah. No. When you're talking about keeping a
project alive, keeping keepingan app alive, you're you're
talking about, like, oh, well,we can build this new thing, and
we can patch the other one atthe same time. And the problem
is every resource that you'respending on doing this rewrite
(25:55):
is a resource not spent onpatching Agree.
On doing new features, on doingall of all of this. Absolutely.
If you have unlimited resources,yeah, you can have two
completely ongoing projects atthe same time. You run into
problems where you're doingstuff like, oh, well, this app
is gonna need this new feature.Well, now, do you are you
(26:18):
building the feature in the oldapp and in the new app at the
same time?
Because you're building it twicebecause you've got you've gotta
build it in both places. And soI think that at those times, you
are effectively spending a lotof time on solely just doing
this rewrite. You regardless ofwhether you've got two streams
(26:40):
at the same time, you've got thesame amount of engineering hours
in the day. And you need to sayany engineering hours that I put
on just rewriting code thatalready exists is engineering
hours that I can't put into justdoing improvements, just doing
(27:02):
bug fixes or new features oranything like that to the old
project.
Peter (27:06):
Yeah. And you do, at least from where I sit, along
the way somewhere, somebody,usually me, you have to justify
to other folks why and whereyou're burning those hours.
Right? So for example, let'stake a slightly different tack
(27:27):
here. You know that this app hasa limited shelf life in that
maybe it only ever meant toexist for a certain amount of
time or for a a specific reasonand then will be killed off
Certainly that is something youdon't want to rewrite I will say
(27:47):
upfront that is a complete wasteof time that is definitely, you
know, maintain it, keep it alivefor as long as it needs to be
and then let it die.
Don't burn the hoursunnecessarily. And I would
actually go as far as to saydon't burn these hours
unnecessarily on either path.Know I would say that there's
(28:08):
certainly no business inrefactoring something either
unless you have to for somereason, right? Some serious bug,
some security flaw, whatever itmay be. But if your app has an
shelf life this probablyshouldn't even be a
consideration in eitherdirection and you should just
keep it alive and then let itdie.
(28:29):
But if your app or apps have anunlimited life in the, you know,
hey, as far as you know, this isgonna live forever, You know,
that that's where thisconversation comes into play.
But I think I don't know. I I Igotta say, I feel like maybe
(28:50):
you've swayed me a little bit,but I think I think I would
still evaluate on a per appbasis as to, okay, which is the
best path to go here? Right?Because I still feel that for
me, I feel like there arescenarios where code base can be
(29:11):
so old that it's it's just it'snot that it's beyond saving,
it's that it's it's not worthit.
I'm still I can save it, but I'mstill gonna be left with
technical debt of of how it'sworking and what it's doing.
Does that make sense?
Geoff (29:27):
Yeah. I I I definitely a % get the appeal. And like I
said, I've done it beforemyself. It it I I definitely
understand why somebody mightthink, hey. You know, it's a
good idea to just throw this allaway and start over.
The problem is, again, it it allcomes down to what are the
(29:51):
resources you have? What are thewhere is your time best spent? I
think it is very, very rare, ifever at all, that the trade off
of we need to just do somethinga second time is better than we
(30:14):
need to take what we have andmake it better.
Peter (30:17):
Okay. Alright. Yeah. Alright. So there you have it,
folks.
We went into this knowing thatwe both had differing
viewpoints, which is great. Ithink that those make for good
conversations. I feel like weboth presented pretty good, you
know, stance on both sides. Wenever promised to have the
(30:40):
answer for you. Go make thatdecision for yourself.
But it's good to have twodifferent viewpoints and take it
from there. If you want to tellus about your viewpoint, hey.
Well, you know what, Geoff?Where can they find you?
Geoff (30:55):
You can find me at cocoatype.com, which should be
undergoing a significantredesign soon. It actually has
more links to things.
Peter (31:03):
More links to things, folks. Yeah. And you can find me
of course at peterwitham.com.Now here's the surprise folks.
You didn't see this one coming.
In the next episode we havefinally reached the end of our
journey. We have been high andlow. We've been to the Himalayan
(31:23):
Mountains, to the deepestoceans. We have found the new
name and branding, I guess, togo with that for the podcast.
And all will be revealed in thenext episode.
So hey, you know what? If youhaven't followed and subscribed
already, you should go do that.And if you want to go the extra
(31:46):
mile, and hey, always go theextra mile, right? Go to
patreon.com/compileswift, andyou can become a member there
and support what we do here. Wegreatly appreciate all of our
members.
Shout out to all of you. Thankyou so much for supporting us.
And you get ad free versions,and sometimes you get to know
about this you know, theseepisodes or anybody else. So
(32:09):
with that, everybody, hey. Whoknows what we'll be calling it
next time?
We know. You'll have to come andfind out. See you later, folks.
Geoff (32:19):
Goodbye.
What's up, everybody? Welcome to another episode of
the podcast. I am your host,Peter. Geoff is here again
today, your other host. How aredoing, Geoff?
Geoff (00:10):
I'm doing just great. Been working on a lot of
different projects and trying toship a bunch of stuff all at the
same time.
Peter (00:17):
Awesome. That's always good fun. Right? Because
everything always goes accordingto plan. Never goes wrong.
Right?
Geoff (00:21):
A %.
Peter (00:22):
So interestingly, in this one, I think we're gonna have
different opinions, which alwaysmakes, I think, for for the best
conversations, and and peoplejust like to hear us disagree.
And then they can pick sides.Right? I just wish somebody
would pick my side once. That'sjust that's all I want in life.
In this episode, I'm going to betalking about something that
(00:45):
I've been doing recently thatsparked a thought here. And it's
this idea of saying, Okay, youknow, I've got an app a game,
you've got some something you'rebuilding, right? And you realise
there's a point that you say toyourself, You know what? Maybe
the best thing to do here is tostart over. And so I want to
(01:08):
talk through that process of howI got to where I'm at and the
decision I made, and then we'llsort of go into a discussion on
it.
So some of you may know, I havebeen working on a game for,
gosh, I don't know, a couple ofyears at this point, on and off.
And it was purely a game Iwanted for me and for my friends
(01:29):
that had the idea, and it'scalled Project Hack.
Projecthack.net is where you canfind it. And I went through, and
I'll sort of break it down abit. I built the first version.
It was great. Did everything Iwanted it to, but it was only
ever meant to be the firstversion to see, number one, is
(01:51):
this going to work as an idea?Number two, can I do the bigger
plan? Now, this was a singleplayer game. It's kind of an
idle style game.
I'm not going to go into all thedetails. You can go to
projecthack.net and see itthere. You'll get the idea. But
when it came time to build outwhat I call in air quotes the
bigger, proper version, I alwayswanted it to be a multiplayer,
(02:16):
because that was one of thedriving ideas. And I was faced
with this decision.
I originally built the game inUnity back when I was learning
Unity. This is how I learned tomake games with Unity, building
this game. So as you canimagine, I did a bunch of things
wrong. And when I went back tothe codebase and looked at it,
(02:36):
and then I was like, okay. Youknow what?
I cannot save this codebase. OrI can, but I've got to basically
understand what the hell I did,like, a year ago before I can
start rebuilding it and buildingthe new stuff. That's when this
idea of maybe I should juststart over came into play. Now I
(02:58):
decided to start over. And thisalso gave me an opportunity to
go out and try a bunch ofdifferent game engines for the
same game to figure out whichone I was most comfortable with,
which one worked the best forthis game.
Again, this can apply to apps,everything. Right? And I knew
that I had learned newtechniques. I learned how to do
(03:18):
a whole lot of things betterbecause I had become a better
programmer in that time as well.And therefore, again, I was
like, Okay, you know what?
At this point, I can spendmonths and months trying to
relearn my old code base writtenwith a visual scripting language
and rebuild it in C, becausethat's what Unity uses, and
(03:39):
that's that's the route I wantedto go to to make it work for a
bunch of things that basicallyjust were very difficult to do
with visual scripting. So that'swhy I decided to start over. And
that brought us to thisdiscussion here today about the
pros and cons of doing that forsome of you who may be in the
same boat. Right? You've hitsome kind of problem, some kind
(04:02):
of wall or something.
Maybe you inherited an app.Maybe you purchased an app from
somebody else. And you'relooking at this code base now,
this foreign code base, saying,what what should I do? Should I
start over, or should I continueto, you know, try and make the
existing code base work. Sothat's the backstory here for
(04:25):
this.
And clearly, my opinion on thisis sometimes starting over is
the good way to go. But, Geoff,I I think that you have a
different take on this. Whatwhat do you think?
Geoff (04:36):
Yeah. My take is the exact opposite. That starting
over completely from scratch.I'm gonna caveat this with the
word almost, but I I feel likethat almost is entirely
miniscule, tiny middle school.Not the right thing to You
should should almost almostalmost almost never ever just do
(04:57):
a complete rewrite of something.
And let me say that, you know, II'm gonna I'm gonna eat my own
words a little bit here and andsay that, you know, I've learned
this from experience. Okay. ThatI have done the full rewrite of
things multiple times, and it itnever works. I sit here and I
go, hey. You know, this seemslike this is one of those times
(05:19):
where I should go back andrewrite this, and it almost
always is a mistake.
I think the one that I'm gonnarefer to most in this particular
conversation is going to be thebig rewrite that I did last year
of Kineo. And I I think thatthat seems like it fits all of
(05:42):
the areas where you might wantto do a big rewrite. I was
porting it to a differentplatform. I was using Apple's
newest user interface designs interms of using SwiftUI versus
UIKit. I was doing a lot of newfeatures for that app.
And still, in hindsight, Ishould not have done a clean
(06:03):
rewrite. I should have insteaddone the incremental migration
of piece by piece, breaking itup as needed, and not doing the
kind of ground up new version ofthe app for VisionOS.
Peter (06:16):
Okay. Can I ask a question there? Because I I feel
like I need a littleclarification here. Because I I
heard you say I thought I heardyou say that you were doing it
for a new platform. Right?
Geoff (06:29):
I was doing it for a new platform.
Peter (06:30):
So my question is, how is doing it for a new platform not
starting from the ground up onthat platform. Do you follow me?
Geoff (06:42):
Well, okay. So it's it's still an Apple platform.
Peter (06:45):
Oh, okay. Which means it's not like
Geoff (06:46):
I can I can reuse? Yeah. I I was porting it from iOS and
iPadOS to Visualize.
Peter (06:52):
Because that was gonna be my follow-up question was, well,
hang on. Surely you used adifferent technology. The answer
here is no. Same platform.
Geoff (06:58):
Okay. Got it. Honestly, for a lot of those things, it it
may still be true. You may stillbe able to migrate existing
stuff, but I I feel like that'smore complicated than we wanna
get into here. Okay.
So there you
Peter (07:13):
have it, folks. Right? We've got two differing
opinions, which is gonna makefor a great conversation here.
So why do you think that it isbest to, you know, take what
you've got and rework? I don'twant to use the word refactor
because I think that's wrong.
But why is it best to take whatyou've got and keep working with
(07:36):
that? Be it mistakes, bad code,bad patterns, and to keep going
with that. To me that soundslike you're burning time on
something that, okay, you mayhave all the logic in there. You
may have what the app does.Right?
So you've got essentially theskeleton of the app, and you're
(07:56):
gonna gonna reflesh it out withwith new new code, new whatever
you wanna call it. So so why doyou think that that is the way
to go?
Geoff (08:05):
I think you've just made my argument for me. Damn. Yeah.
All of these all of these thingsalready exist. And, yes, you may
have learned better ways to doit.
You may have learned a a nicerway to do it. But what you have
presumably works, at least tosome extent. And so you can
leave that there and buildscaffolding around it.
Peter (08:27):
Okay.
Geoff (08:27):
You can say, okay. I need to add this new feature or I
need to improve some existingpart of it, and you can leave
everything else in there whileyou build that. You used the
term at one point, you're, like,wasting time on this. But but I
I feel like the complete throwit out approach is itself
(08:52):
wasting time. You're wastingtime reimplementing things that
you already have, that you'vealready done.
Okay. And for that, like, yes,they may not be ideal. Nothing
is ever ideal. No code is everideal. You can sit there and you
can kind of put that behind awall.
(09:12):
You can sit there and say, thiscode, we know this code is bad,
and try to avoid touching it asmuch as possible, but it's still
there. It's still working tosome extent. And so it's worth
having that code there that youdon't have to spend time
rewriting from scratch.
Peter (09:31):
Okay. So someone in our chat room, we got a chat room on
our Discord going here whilewhile we're recording this. If
you want to take part in that,come join our Discord. We'll put
a link in the show notes. Butthey pointed out that, Oh, well,
you can take this modularapproach.
But I think that that only worksif you've got a good modular
approach to begin with. Right?And that is part of my argument
(09:51):
for why it's good to start over,is you could have a code base
that is so entwined andspaghetti bold that you just
can't unravel that mess. And Idon't mean, you know, not break
everything because chances areyou are gonna break everything.
But that's kind of the point, Iguess, in some ways.
(10:12):
Right? Hey, folks. If you likewhat you're hearing in this
podcast and you wanna help thispodcast to continue going
forward and having great guestsand great conversations, I
invite you to become a Patreonsupporter. You can go to
patreon.com/compileswift whereyou will get ad free versions of
the podcast along with othercontent. But the idea I'm saying
(10:37):
is, yes, you're throwing out thecode, but you're not throwing
out all of the problems that youhave solved, meaning the
business logic and the rules andeverything that you had in the
original app still exist.
You're just using those as thetemplate to build the new app
(11:00):
with maybe the new technology,right? I mean, I think, I will
say that I don't thinkrebuilding with the same
technology is worth it, right? Ifeel like that's kind of like,
well, you're just going to endup exactly where you were. Why
are you doing that? Right?
But I think that that's kind ofwhere I'm coming from on some of
this is sometimes trying tounravel the spaghetti is harder
(11:23):
than just acknowledging it'sthere and building it. Building
the the idea and thephilosophies behind it, but in a
newer, cleaner way.
Geoff (11:33):
Yeah. Let me tackle this a couple pieces at a time. You
said you're throwing away thecode, but you're not throwing
away the business logic.
Peter (11:41):
Yeah.
Geoff (11:42):
I think for a lot of people, the business logic is
your code. Interesting. Youlikely have not been documenting
your code to the extent like, tothe bug for bug match up of here
is everything that I've chosen,and here is every decision that
I've made, and here is thisextent. When you recreate a
(12:06):
piece of software like that, youare going to make changes. You
are gonna make things that aredifferent Unless you fully
understand your code to thepoint of in order to recreate
the business logic that you'vealready created, you're gonna
have to understand the code tothe level that you're talking
about not wanting to do in thefirst place
Peter (12:27):
Okay.
Geoff (12:28):
To to unravel that spaghetti.
Peter (12:30):
Sure. And I and I I should say here, yeah, I agree
that, you know, if you're theonly if the only rules or
whatever you want to call it,documentation, you have to
follow as to what this app is,how it does it, and how it was
built, is the code withoutdocumentation, then, you know,
(12:52):
from my perspective, you know,you're in a hard place either
way, right? You've got toreverse engineer before you can
either repair or restart eitherway. Unfortunately, it's easy to
sit here and say, Of course,none of us would do that, right?
Yes, we would We've all donethat.
(13:13):
And something that I want tothrow in here, and I'm curious
now that I think about it. Doyou have the same opinion
whether it's an app that youbuilt meaning you, your team,
whatever that may look like foryou or one that you have
inherited from somebody else?Would you say that the opinion
(13:33):
is the same on both? Given thatthis
Geoff (13:36):
I would
Peter (13:36):
say that the Sorry. Given that maybe the app that you
inherited, the code is allyou've got by way of what does
this thing do?
Geoff (13:44):
Yep. I would say in a case where the code is all
you've inherited, that almostdoubled down on, you should not
rewrite that because you havethat existing as it is. But I
would say nobody is so good tounderstand their own code
(14:04):
however long ago they wrote it.
Peter (14:06):
Right.
Geoff (14:07):
You know, there's there's the old adage of realize like,
realize when you're writing codethat the person that has to
maintain it later knows whereyou live.
Peter (14:18):
Yeah. Yeah. That's
Geoff (14:20):
true. Because it's
Peter (14:20):
you.
Geoff (14:21):
Yeah. And and and so, like, I I feel like that that is
going to be the problem. It'slike, whether it was somebody
else that wrote it or whether itwas you that wrote it, the you
in the past is somebody elsethat wrote it.
Peter (14:33):
No. Absolutely. They they, you know Yeah.
Geoff (14:36):
They they are a completely different person.
Obviously, the whole reason thatyou're talking about rewriting
this in the first place isbecause you made decisions then
that you would not have madenow. And so I don't think
there's much of a reason totreat those two things
(14:56):
differently. To say, hey. Youknow, whether I rewrote this or
sorry.
Whether I wrote this originallyor whether somebody else wrote
this originally and I'm justmaintaining it after the fact, I
I feel like those are similarenough that, no, in both cases,
I would avoid doing a rewrite.
Peter (15:13):
Okay. So to me then, that also and and and I get what
you're saying there. Right?Because if I understand it
correctly, we could say (15:20):
Hey, regardless of whatever path I
choose to take here, me sixmonths from now will be looking
at the me now with the same eyesthat the me now is looking at me
from six months ago. Right?
Yeah. No, I totally get that.Yeah. No, I understand. And
(15:41):
also, hey, you know, whatever Idecide now will be just as wrong
six months from now as it wassix months ago for different
reasons.
I I think that's what you'resaying. Right?
Geoff (15:50):
Now to go back to the idea of modularization and and
kind of unraveling the spaghettias it were, I agree that this is
generally a approach that youshould move towards and that
making things more modular doesmake it easier to do these
(16:10):
refactors as as you're goingalong. But I think that it's not
a reason to completely throw outsomething that already exists if
it is not modularized. What youshould do instead, I'm gonna
refer to a great, great book. Icame with Refactoring by Martin
Fowler, and I came with WorkingEffectively with Legacy Code by
Peter (16:34):
Michael Feathers. That's interesting. You know that
Working with Legacy Code is abook on my Amazon list to read
one day.
Geoff (16:40):
It it is such a great book. You should know why read
this book.
Peter (16:43):
And we'll folks, we'll Every we'll put
Geoff (16:45):
a link that. This
Peter (16:46):
book. Yeah.
Geoff (16:47):
Both of these books, highly recommended. You should
read both of Alright. Period.I'm trying to remember which one
in particular refers to thething that I want to refer to.
Yes.
It is working effectively withLegacy Code. It's on page 30 of
my copy. It is very early in onthe book.
Peter (17:06):
Seems. Okay.
Geoff (17:08):
Yep. So the idea being that what you do is you take
that code, that that big blob ofspaghetti code that you've
already got. You take that code.You put that in a module. That
is your one module.
You can call this modulewhatever you want. I tend in my
projects where I'm going backand doing something like this,
(17:28):
call it just core or legacy orsomething like that.
Peter (17:32):
Okay.
Geoff (17:33):
And you you put it off to the side, you wall it off. Then
what you do with that code, asyou need pieces of that code, as
you need to bring this into yourmodern architecture, your modern
rewrite, your modern whatever,you go in and you find the
seams. You find the bits of codewhere you can go, oh, I can
(17:58):
stick in a a point of injectionhere. Injection in the terms of,
like, dependency injection or orOkay. Something like that, where
I can go, I can connect to thiscode with my new code.
I I can plug in here. This isthis is my entry point. And you
go in and you find that. Andthen once you've got that seam
there, it works very much like aa I don't know. Carving a rock.
(18:21):
Carving carving something out ofmarble. You've got your chisel
in there. Mhmm. And once you'vegot your chisel in there, you
can start to pick around. Youcan pull a piece off.
And that's how you get aroundthis spaghetti code. You pull
off small pieces at a time. Youget in there. You go, oh, this
bit of business logic. I canseparate this out.
I can I can put in a connectionto it right there, and then
(18:44):
using that connection, I canstart to pry this bit out? And
now that bit, again, still kindof a self contained module,
maybe inside of it. It's not theprettiest. It's not what you
want, but you can pull thatsmall piece out into your new
architecture. And then onceyou've got that small piece out
into your new architecture,you've got a much more minimal
interface around it.
(19:04):
You've got a much smaller thing,to to have to communicate with.
And you know what you got whenyou have that small thing to
communicate with? You can writetests for it. You can write unit
tests around it. And then onceyou got unit tests around it,
you know what you can do with itthen?
Then you can rewrite that smalllittle piece. You rewrite that
small little piece. You makethat small little piece better,
(19:25):
and you've got it completelyunit tested. You've got it
separated from all of the restof your spaghetti ball, and
you've got that piece fixed.
Peter (19:35):
Okay.
Geoff (19:35):
Alright. And you do that again and again and again and
again until your core library,that library that you put down
there, you slowly chip away atit one piece at a time. At every
point, you've got working code.At every point, you've got an
app that continues to exist.You've got an app that you you
haven't had to spend all of yourtime rebuilding, and you've
(19:59):
you've you're able to makeprogress on your project as a
whole.
Oh, and so you've been able tobuild everything that you're
still doing, and you're able tomake those improvements over
time without having ever neededto step back, take a huge amount
of time to rewrite all of thesebits. Time for a break.
Peter (20:20):
Hey, everybody. It's Peter Widom here from the
compulsive podcast. I'm gonnatell you about Setapp. Setapp is
a service that provides asubscription fee of just $10 a
month, and you get access toover 200 Mac applications, and
it's also available now on iOSas part of that deal. I use the
(20:40):
service because it just has aton of really good first rate
apps that I use all the time.
And for me, it's invaluable as adeveloper to have access to
tools for things like APIs, forplanning projects, writing
emails, writing documentation.And you get all of these things,
including database apps, all ofthat kind of stuff right there
(21:03):
on the Setapp service for just$10 a month. You can use as many
or as few applications as youneed. If you're interested in
checking this out, go toPeterWidham.com, p e t e r w I t
h a m Com forward / set app, s et a p p, and you can see the
details there. And it's got alink that you can go over and
(21:25):
start using the service and seehow it works out for you.
I strongly recommend this toevery Mac user.
Geoff (21:32):
Break timed over. All at once.
Peter (21:35):
Okay. Alright. And that sounds very similar to to what
they're saying in the chat room,you know, as far as, oh, yeah.
Well, let's let's wall this offand then see, you know, I I
guess the thing for me is, like,in the chat room where they're
saying about refactor it later.And that's kind of the part that
that bothers me about.
(21:56):
This is, no, if you're going togo to the trouble now, refactor
it now. Right? But the segmentthat you're talking about,
right? Module, however you wantto phrase it, whatever it means
to anybody. And and I don'tdisagree with that.
I think would it be fair to saythat is what most of us did as
(22:18):
we migrated to Swift? Okay.Well, I'm gonna rewrite this
controller as Swift fromObjective C. I'm gonna rewrite
this view in SwiftUI fromwhatever it was, storyboard
hell. Right?
And and picking them off one byone like that because it's also
a technology that allows us todo that. Right?
Geoff (22:40):
But it it would have been silly, I think, for a lot of
people to have gone back and go,you know what? Swift is the new
thing. Swift is the new hotness.Swift is cool. What we need to
do is completely throw away allof our Objective C code, not
look at it, and build a new appfrom scratch in Swift based on,
(23:00):
what we had before.
Peter (23:01):
Okay.
Geoff (23:02):
I I I don't think that that people think that would be
a good idea. I I I was sittinghere trying to say, like, if you
think that's a good idea, you'rewrong. No. Because I think it it
is wrong. But at the same time,like, I I I feel like they're
I'm gonna have people pushingback.
They're like, oh, no. Well,That's definitely a
Peter (23:22):
good idea. This is where things get awkward because I
have to cross back over theother side of the fence and
stand with you here because thatis what I went through. Right?
And I'm still going through is,Yeah, you know what? Hey, guess
what?
Companies and that won't giveyou time to start from scratch.
You know, but So I've beenthrough that. And yes, it
(23:44):
worked, but it was extremelypainful. Because you also have
to try and pick and choose theright parts to start with. Like
you say, I do agree with theidea of, well, you know, it's
kind of like building a house,right?
Use that analogy. Let's makesure the core foundation is good
first, otherwise all hope islost. You know, and so I get
(24:05):
that. But I don't know, I thinkfor me, you know, some of the
attraction I will admit this, Ithink part of the attraction of
starting from scratch is thefreedom to choose maybe
different technologies butcertainly a different approach
(24:28):
but I also get and acknowledgethat sometimes well, just
refactoring this part first isthe way to go. Because there is
a very good argument to keep theproduct alive, but I'm also
thinking, hey, either way yougo, you're keeping the product
(24:48):
alive, right?
Because if I'm starting acompletely new app, the old one
is still there to be patched andupdated and sent out. Whereas if
I and work, you know, yeah, canmake a new branch and work on
migrating that code andimproving that code and whatever
term you want to use, but Istill have to make sure that
(25:10):
it's shippable one way or theother. Right? As opposed to
knowing that it is shippable atany moment because I'm not
touching the existing version.Does it and and I get you
probably don't agree with that,but you see where I'm coming
from?
Geoff (25:24):
I I I see where you're coming from, but the the problem
is I don't believe you.
Peter (25:30):
No. That's fine. No. As long as you understood. I'm
gonna edit this so that itsounds like you said this.
No. No.
Geoff (25:35):
Yeah. Yeah. No. When you're talking about keeping a
project alive, keeping keepingan app alive, you're you're
talking about, like, oh, well,we can build this new thing, and
we can patch the other one atthe same time. And the problem
is every resource that you'respending on doing this rewrite
(25:55):
is a resource not spent onpatching Agree.
On doing new features, on doingall of all of this. Absolutely.
If you have unlimited resources,yeah, you can have two
completely ongoing projects atthe same time. You run into
problems where you're doingstuff like, oh, well, this app
is gonna need this new feature.Well, now, do you are you
(26:18):
building the feature in the oldapp and in the new app at the
same time?
Because you're building it twicebecause you've got you've gotta
build it in both places. And soI think that at those times, you
are effectively spending a lotof time on solely just doing
this rewrite. You regardless ofwhether you've got two streams
(26:40):
at the same time, you've got thesame amount of engineering hours
in the day. And you need to sayany engineering hours that I put
on just rewriting code thatalready exists is engineering
hours that I can't put into justdoing improvements, just doing
(27:02):
bug fixes or new features oranything like that to the old
project.
Peter (27:06):
Yeah. And you do, at least from where I sit, along
the way somewhere, somebody,usually me, you have to justify
to other folks why and whereyou're burning those hours.
Right? So for example, let'stake a slightly different tack
(27:27):
here. You know that this app hasa limited shelf life in that
maybe it only ever meant toexist for a certain amount of
time or for a a specific reasonand then will be killed off
Certainly that is something youdon't want to rewrite I will say
(27:47):
upfront that is a complete wasteof time that is definitely, you
know, maintain it, keep it alivefor as long as it needs to be
and then let it die.
Don't burn the hoursunnecessarily. And I would
actually go as far as to saydon't burn these hours
unnecessarily on either path.Know I would say that there's
(28:08):
certainly no business inrefactoring something either
unless you have to for somereason, right? Some serious bug,
some security flaw, whatever itmay be. But if your app has an
shelf life this probablyshouldn't even be a
consideration in eitherdirection and you should just
keep it alive and then let itdie.
(28:29):
But if your app or apps have anunlimited life in the, you know,
hey, as far as you know, this isgonna live forever, You know,
that that's where thisconversation comes into play.
But I think I don't know. I I Igotta say, I feel like maybe
(28:50):
you've swayed me a little bit,but I think I think I would
still evaluate on a per appbasis as to, okay, which is the
best path to go here? Right?Because I still feel that for
me, I feel like there arescenarios where code base can be
(29:11):
so old that it's it's just it'snot that it's beyond saving,
it's that it's it's not worthit.
I'm still I can save it, but I'mstill gonna be left with
technical debt of of how it'sworking and what it's doing.
Does that make sense?
Geoff (29:27):
Yeah. I I I definitely a % get the appeal. And like I
said, I've done it beforemyself. It it I I definitely
understand why somebody mightthink, hey. You know, it's a
good idea to just throw this allaway and start over.
The problem is, again, it it allcomes down to what are the
(29:51):
resources you have? What are thewhere is your time best spent? I
think it is very, very rare, ifever at all, that the trade off
of we need to just do somethinga second time is better than we
(30:14):
need to take what we have andmake it better.
Peter (30:17):
Okay. Alright. Yeah. Alright. So there you have it,
folks.
We went into this knowing thatwe both had differing
viewpoints, which is great. Ithink that those make for good
conversations. I feel like weboth presented pretty good, you
know, stance on both sides. Wenever promised to have the
(30:40):
answer for you. Go make thatdecision for yourself.
But it's good to have twodifferent viewpoints and take it
from there. If you want to tellus about your viewpoint, hey.
Well, you know what, Geoff?Where can they find you?
Geoff (30:55):
You can find me at cocoatype.com, which should be
undergoing a significantredesign soon. It actually has
more links to things.
Peter (31:03):
More links to things, folks. Yeah. And you can find me
of course at peterwitham.com.Now here's the surprise folks.
You didn't see this one coming.
In the next episode we havefinally reached the end of our
journey. We have been high andlow. We've been to the Himalayan
(31:23):
Mountains, to the deepestoceans. We have found the new
name and branding, I guess, togo with that for the podcast.
And all will be revealed in thenext episode.
So hey, you know what? If youhaven't followed and subscribed
already, you should go do that.And if you want to go the extra
(31:46):
mile, and hey, always go theextra mile, right? Go to
patreon.com/compileswift, andyou can become a member there
and support what we do here. Wegreatly appreciate all of our
members.
Shout out to all of you. Thankyou so much for supporting us.
And you get ad free versions,and sometimes you get to know
about this you know, theseepisodes or anybody else. So
(32:09):
with that, everybody, hey. Whoknows what we'll be calling it
next time?
We know. You'll have to come andfind out. See you later, folks.
Geoff (32:19):
Goodbye.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.