Starting over on apps and code

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 are doing, Geoff?

I'm doing just great. Been working on a lot of different projects and trying to ship a bunch of stuff all at the same time.

Awesome. That's always good fun. Right? Because everything always goes according to plan. Never goes wrong.

Right?

A %.

So interestingly, in this one, I think we're gonna have different opinions, which always makes, I think, for for the best conversations, and and people just like to hear us disagree. And then they can pick sides. Right? I just wish somebody would pick my side once. That's just that's all I want in life.

In this episode, I'm going to be talking about something that I've been doing recently that sparked a thought here. And it's this idea of saying, Okay, you know, I've got an app a game, you've got some something you're building, right? And you realise there's a point that you say to yourself, You know what? Maybe the best thing to do here is to start over. And so I want to talk through that process of how I got to where I'm at and the decision I made, and then we'll sort of go into a discussion on it.

So some of you may know, I have been working on a game for, gosh, I don't know, a couple of years at this point, on and off. And it was purely a game I wanted for me and for my friends that had the idea, and it's called Project Hack. Projecthack.net is where you can find it. And I went through, and I'll sort of break it down a bit. I built the first version.

It was great. Did everything I wanted it to, but it was only ever meant to be the first version to see, number one, is this going to work as an idea? Number two, can I do the bigger plan? Now, this was a single player game. It's kind of an idle style game.

I'm not going to go into all the details. You can go to projecthack.net and see it there. You'll get the idea. But when it came time to build out what I call in air quotes the bigger, proper version, I always wanted it to be a multiplayer, because that was one of the driving ideas. And I was faced with this decision.

I originally built the game in Unity back when I was learning Unity. This is how I learned to make games with Unity, building this game. So as you can imagine, I did a bunch of things wrong. And when I went back to the codebase and looked at it, and then I was like, okay. You know what?

I cannot save this codebase. Or I can, but I've got to basically understand what the hell I did, like, a year ago before I can start rebuilding it and building the new stuff. That's when this idea of maybe I should just start over came into play. Now I decided to start over. And this also gave me an opportunity to go out and try a bunch of different game engines for the same game to figure out which one I was most comfortable with, which one worked the best for this game.

Again, this can apply to apps, everything. Right? And I knew that I had learned new techniques. I learned how to do a whole lot of things better because 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 spend months and months trying to relearn my old code base written with a visual scripting language and rebuild it in C, because that's what Unity uses, and that's that's the route I wanted to go to to make it work for a bunch of things that basically just were very difficult to do with visual scripting. So that's why I decided to start over. And that brought us to this discussion here today about the pros and cons of doing that for some of you who may be in the same boat. Right? You've hit some kind of problem, some kind of wall or something.

Maybe you inherited an app. Maybe you purchased an app from somebody else. And you're looking at this code base now, this foreign code base, saying, what what should I do? Should I start over, or should I continue to, you know, try and make the existing code base work. So that's the backstory here for this.

And clearly, my opinion on this is sometimes starting over is the good way to go. But, Geoff, I I think that you have a different take on this. What what do you think?

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 like that almost is entirely miniscule, tiny middle school. Not the right thing to You should should almost almost almost almost never ever just do a complete rewrite of something.

And let me say that, you know, I I'm gonna I'm gonna eat my own words a little bit here and and say that, you know, I've learned this from experience. Okay. That I have done the full rewrite of things multiple times, and it it never works. I sit here and I go, hey. You know, this seems like this is one of those times where I should go back and rewrite this, and it almost always is a mistake.

I think the one that I'm gonna refer to most in this particular conversation is going to be the big rewrite that I did last year of Kineo. And I I think that that seems like it fits all of the areas where you might want to do a big rewrite. I was porting it to a different platform. I was using Apple's newest user interface designs in terms of using SwiftUI versus UIKit. I was doing a lot of new features for that app.

And still, in hindsight, I should not have done a clean rewrite. I should have instead done the incremental migration of piece by piece, breaking it up as needed, and not doing the kind of ground up new version of the app for VisionOS.

Okay. Can I ask a question there? Because I I feel like I need a little clarification here. Because I I heard you say I thought I heard you say that you were doing it for a new platform. Right?

I was doing it for a new platform.

So my question is, how is doing it for a new platform not starting from the ground up on that platform. Do you follow me?

Well, okay. So it's it's still an Apple platform.

Oh, okay. Which means it's not like

I can I can reuse? Yeah. I I was porting it from iOS and iPadOS to Visualize.

Because that was gonna be my follow-up question was, well, hang on. Surely you used a different technology. The answer here is no. Same platform.

Okay. Got it. Honestly, for a lot of those things, it it may still be true. You may still be able to migrate existing stuff, but I I feel like that's more complicated than we wanna get into here. Okay.

So there you

have it, folks. Right? We've got two differing opinions, which is gonna make for a great conversation here. So why do you think that it is best to, you know, take what you've got and rework? I don't want to use the word refactor because I think that's wrong.

But why is it best to take what you've got and keep working with that? Be it mistakes, bad code, bad patterns, and to keep going with that. To me that sounds like you're burning time on something that, okay, you may have all the logic in there. You may have what the app does. Right?

So you've got essentially the skeleton of the app, and you're gonna gonna reflesh it out with with new new code, new whatever you wanna call it. So so why do you think that that is the way to go?

I think you've just made my argument for me. Damn. Yeah. All of these all of these things already exist. And, yes, you may have learned better ways to do it.

You may have learned a a nicer way to do it. But what you have presumably works, at least to some extent. And so you can leave that there and build scaffolding around it.

Okay.

You can say, okay. I need to add this new feature or I need to improve some existing part of it, and you can leave everything else in there while you build that. You used the term at one point, you're, like, wasting time on this. But but I I feel like the complete throw it out approach is itself wasting time. You're wasting time reimplementing things that you already have, that you've already done.

Okay. And for that, like, yes, they may not be ideal. Nothing is ever ideal. No code is ever ideal. You can sit there and you can kind of put that behind a wall.

You can sit there and say, this code, we know this code is bad, and try to avoid touching it as much as possible, but it's still there. It's still working to some extent. And so it's worth having that code there that you don't have to spend time rewriting from scratch.

Okay. So someone in our chat room, we got a chat room on our Discord going here while while 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. But they pointed out that, Oh, well, you can take this modular approach.

But I think that that only works if you've got a good modular approach to begin with. Right? And that is part of my argument for why it's good to start over, is you could have a code base that is so entwined and spaghetti bold that you just can't unravel that mess. And I don't mean, you know, not break everything because chances are you are gonna break everything. But that's kind of the point, I guess, in some ways.

Right? Hey, folks. If you like what you're hearing in this podcast and you wanna help this podcast to continue going forward and having great guests and great conversations, I invite you to become a Patreon supporter. You can go to patreon.com/compileswift where you will get ad free versions of the podcast along with other content. But the idea I'm saying is, yes, you're throwing out the code, but you're not throwing out all of the problems that you have solved, meaning the business logic and the rules and everything that you had in the original app still exist.

You're just using those as the template to build the new app with maybe the new technology, right? I mean, I think, I will say that I don't think rebuilding with the same technology is worth it, right? I feel like that's kind of like, well, you're just going to end up exactly where you were. Why are you doing that? Right?

But I think that that's kind of where I'm coming from on some of this is sometimes trying to unravel the spaghetti is harder than just acknowledging it's there and building it. Building the the idea and the philosophies behind it, but in a newer, cleaner way.

Yeah. Let me tackle this a couple pieces at a time. You said you're throwing away the code, but you're not throwing away the business logic.

Yeah.

I think for a lot of people, the business logic is your code. Interesting. You likely have not been documenting your code to the extent like, to the 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 this extent. When you recreate a piece of software like that, you are going to make changes. You are gonna make things that are different Unless you fully understand your code to the point of in order to recreate the business logic that you've already created, you're gonna have to understand the code to the level that you're talking about not wanting to do in the first place

Okay.

To to unravel that spaghetti.

Sure. And I and I I should say here, yeah, I agree that, you know, if you're the only 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 without documentation, then, you know, from my perspective, you know, you're in a hard place either way, right? You've got to reverse engineer before you can either repair or restart either way. Unfortunately, it's easy to sit here and say, Of course, none of us would do that, right? Yes, we would We've all done that.

And something that I want to throw in here, and I'm curious now that I think about it. Do you have the same opinion whether it's an app that you built meaning you, your team, whatever that may look like for you or one that you have inherited from somebody else? Would you say that the opinion is the same on both? Given that this

I would

say that the Sorry. Given that maybe the app that you inherited, the code is all you've got by way of what does this thing do?

Yep. I would say in a case where the code is all you've inherited, that almost doubled down on, you should not rewrite that because you have that existing as it is. But I would say nobody is so good to understand their own code however long ago they wrote it.

Right.

You know, there's there's the old adage of realize like, realize when you're writing code that the person that has to maintain it later knows where you live.

Yeah. Yeah. That's

true. Because it's

you.

Yeah. And and and so, like, I I feel like that that is going to be the problem. It's like, whether it was somebody else that wrote it or whether it was you that wrote it, the you in the past is somebody else that wrote it.

No. Absolutely. They they, you know Yeah.

They they are a completely different person. Obviously, the whole reason that you're talking about rewriting this in the first place is because you made decisions then that you would not have made now. And so I don't think there's much of a reason to treat those two things differently. To say, hey. You know, whether I rewrote this or sorry.

Whether I wrote this originally or whether somebody else wrote this originally and I'm just maintaining it after the fact, I I feel like those are similar enough that, no, in both cases, I would avoid doing a rewrite.

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: Hey, regardless of whatever path I choose to take here, me six months from now will be looking at the me now with the same eyes that the me now is looking at me from six months ago. Right?

Yeah. No, I totally get that. Yeah. No, I understand. And also, hey, you know, whatever I decide now will be just as wrong six months from now as it was six months ago for different reasons.

I I think that's what you're saying. Right?

Now to go back to the idea of modularization and and kind of unraveling the spaghetti as it were, I agree that this is generally a approach that you should move towards and that making things more modular does make it easier to do these refactors as as you're going along. But I think that it's not a reason to completely throw out something that already exists if it is not modularized. What you should do instead, I'm gonna refer to a great, great book. I came with Refactoring by Martin Fowler, and I came with Working Effectively with Legacy Code by

Michael Feathers. That's interesting. You know that Working with Legacy Code is a book on my Amazon list to read one day.

It it is such a great book. You should know why read this book.

And we'll folks, we'll Every we'll put

a link that. This

book. Yeah.

Both of these books, highly recommended. You should read both of Alright. Period. I'm trying to remember which one in particular refers to the thing that I want to refer to. Yes.

It is working effectively with Legacy Code. It's on page 30 of my copy. It is very early in on the book.

Seems. Okay.

Yep. So the idea being that what you do is you take that code, that that big blob of spaghetti 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 module whatever you want. I tend in my projects where I'm going back and doing something like this, call it just core or legacy or something like that.

Okay.

And you you put it off to the side, you wall it off. Then what you do with that code, as you need pieces of that code, as you need to bring this into your modern architecture, your modern rewrite, your modern whatever, you go in and you find the seams. You find the bits of code where you can go, oh, I can stick in a a point of injection here. Injection in the terms of, like, dependency injection or or Okay. Something like that, where I can go, I can connect to this code with my new code.

I I can plug in here. This is this is my entry point. And you go in and you find that. And then once you've got that seam there, it works very much like a a I don't know. Carving a rock.

Carving carving something out of marble. You've got your chisel in there. Mhmm. And once you've got your chisel in there, you can start to pick around. You can pull a piece off.

And that's how you get around this spaghetti code. You pull off small pieces at a time. You get in there. You go, oh, this bit of business logic. I can separate this out.

I can I can put in a connection to it right there, and then using that connection, I can start to pry this bit out? And now that bit, again, still kind of a self contained module, maybe inside of it. It's not the prettiest. It's not what you want, but you can pull that small piece out into your new architecture. And then once you've got that small piece out into your new architecture, you've got a much more minimal interface around it.

You've got a much smaller thing, to to have to communicate with. And you know what you got when you have that small thing to communicate with? You can write tests for it. You can write unit tests around it. And then once you got unit tests around it, you know what you can do with it then?

Then you can rewrite that small little piece. You rewrite that small little piece. You make that small little piece better, and you've got it completely unit tested. You've got it separated from all of the rest of your spaghetti ball, and you've got that piece fixed.

Okay.

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 at it 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 your time rebuilding, and you've you've you're able to make progress on your project as a whole.

Oh, and so you've been able to build everything that you're still doing, and you're able to make those improvements over time without having ever needed to step back, take a huge amount of time to rewrite all of these bits. Time for a break.

Hey, everybody. It's Peter Widom here from the compulsive podcast. I'm gonna tell you about Setapp. Setapp is a service that provides a subscription fee of just $10 a month, and you get access to over 200 Mac applications, and it's also available now on iOS as part of that deal. I use the service because it just has a ton of really good first rate apps that I use all the time.

And for me, it's invaluable as a developer to have access to tools for things like APIs, for planning projects, writing emails, writing documentation. And you get all of these things, including database apps, all of that kind of stuff right there on the Setapp service for just $10 a month. You can use as many or as few applications as you need. If you're interested in checking this out, go to PeterWidham.com, p e t e r w I t h a m Com forward / set app, s e t a p p, and you can see the details there. And it's got a link that you can go over and start using the service and see how it works out for you.

I strongly recommend this to every Mac user.

Break timed over. All at once.

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 off and 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.

This is, no, if you're going to go to the trouble now, refactor it now. Right? But the segment that you're talking about, right? Module, however you want to phrase it, whatever it means to anybody. And and I don't disagree with that.

I think would it be fair to say that is what most of us did as we migrated to Swift? Okay. Well, I'm gonna rewrite this controller as Swift from Objective C. I'm gonna rewrite this view in SwiftUI from whatever it was, storyboard hell. Right?

And and picking them off one by one like that because it's also a technology that allows us to do that. Right?

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 all of our Objective C code, not look at it, and build a new app from scratch in Swift based on, what we had before.

Okay.

I I I don't think that that people think that would be a good idea. I I I was sitting here trying to say, like, if you think that's a good idea, you're wrong. 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 pushing back.

They're like, oh, no. Well, That's definitely a

good idea. This is where things get awkward because I have to cross back over the other side of the fence and stand with you here because that is what I went through. Right? And I'm still going through is, Yeah, you know what? Hey, guess what?

Companies and that won't give you time to start from scratch. You know, but So I've been through that. And yes, it worked, but it was extremely painful. Because you also have to try and pick and choose the right parts to start with. Like you say, I do agree with the idea of, well, you know, it's kind of like building a house, right?

Use that analogy. Let's make sure the core foundation is good first, otherwise all hope is lost. You know, and so I get that. But I don't know, I think for me, you know, some of the attraction I will admit this, I think part of the attraction of starting from scratch is the freedom to choose maybe different technologies but certainly a different approach but I also get and acknowledge that sometimes well, just refactoring this part first is the way to go. Because there is a very good argument to keep the product alive, but I'm also thinking, hey, either way you go, you're keeping the product alive, right?

Because if I'm starting a completely new app, the old one is still there to be patched and updated and sent out. Whereas if I and work, you know, yeah, can make a new branch and work on migrating that code and improving that code and whatever term you want to use, but I still have to make sure that it's shippable one way or the other. Right? As opposed to knowing that it is shippable at any 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?

I I I see where you're coming from, but the the problem is I don't believe you.

No. That's fine. No. As long as you understood. I'm gonna edit this so that it sounds like you said this.

No. No.

Yeah. Yeah. No. When you're talking about keeping a project alive, keeping keeping an app alive, you're you're talking about, like, oh, well, we can build this new thing, and we can patch the other one at the same time. And the problem is every resource that you're spending on doing this rewrite is a resource not spent on patching Agree.

On doing new features, on doing all of all of this. Absolutely. If you have unlimited resources, yeah, you can have two completely ongoing projects at the same time. You run into problems where you're doing stuff like, oh, well, this app is gonna need this new feature. Well, now, do you are you building the feature in the old app and in the new app at the same time?

Because you're building it twice because you've got you've gotta build it in both places. And so I think that at those times, you are effectively spending a lot of time on solely just doing this rewrite. You regardless of whether you've got two streams at the same time, you've got the same amount of engineering hours in the day. And you need to say any engineering hours that I put on just rewriting code that already exists is engineering hours that I can't put into just doing improvements, just doing bug fixes or new features or anything like that to the old project.

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 where you're burning those hours. Right? So for example, let's take a slightly different tack here. You know that this app has a limited shelf life in that maybe it only ever meant to exist for a certain amount of time or for a a specific reason and then will be killed off Certainly that is something you don't want to rewrite I will say upfront that is a complete waste of time that is definitely, you know, maintain it, keep it alive for as long as it needs to be and then let it die.

Don't burn the hours unnecessarily. And I would actually go as far as to say don't burn these hours unnecessarily on either path. Know I would say that there's certainly no business in refactoring something either unless you have to for some reason, right? Some serious bug, some security flaw, whatever it may be. But if your app has an shelf life this probably shouldn't even be a consideration in either direction and you should just keep it alive and then let it die.

But if your app or apps have an unlimited life in the, you know, hey, as far as you know, this is gonna live forever, You know, that that's where this conversation comes into play. But I think I don't know. I I I gotta say, I feel like maybe you've swayed me a little bit, but I think I think I would still evaluate on a per app basis as to, okay, which is the best path to go here? Right? Because I still feel that for me, I feel like there are scenarios where code base can be so old that it's it's just it's not that it's beyond saving, it's that it's it's not worth it.

I'm still I can save it, but I'm still gonna be left with technical debt of of how it's working and what it's doing. Does that make sense?

Yeah. I I I definitely a % get the appeal. And like I said, I've done it before myself. It it I I definitely understand why somebody might think, hey. You know, it's a good idea to just throw this all away and start over.

The problem is, again, it it all comes down to what are the resources you have? What are the where is your time best spent? I think it is very, very rare, if ever at all, that the trade off of we need to just do something a second time is better than we need to take what we have and make it better.

Okay. Alright. Yeah. Alright. So there you have it, folks.

We went into this knowing that we both had differing viewpoints, which is great. I think that those make for good conversations. I feel like we both presented pretty good, you know, stance on both sides. We never promised to have the answer for you. Go make that decision for yourself.

But it's good to have two different viewpoints and take it from there. If you want to tell us about your viewpoint, hey. Well, you know what, Geoff? Where can they find you?

You can find me at cocoatype.com, which should be undergoing a significant redesign soon. It actually has more links to things.

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 have finally reached the end of our journey. We have been high and low. We've been to the Himalayan Mountains, to the deepest oceans. We have found the new name and branding, I guess, to go with that for the podcast. And all will be revealed in the next episode.

So hey, you know what? If you haven't followed and subscribed already, you should go do that. And if you want to go the extra mile, and hey, always go the extra mile, right? Go to patreon.com/compileswift, and you can become a member there and support what we do here. We greatly appreciate all of our members.

Shout out to all of you. Thank you so much for supporting us. And you get ad free versions, and sometimes you get to know about this you know, these episodes or anybody else. So with that, everybody, hey. Who knows what we'll be calling it next time?

We know. You'll have to come and find out. See you later, folks.

Goodbye.