Isaac: Welcome to Never Rewrite. I'm Isaac Askew.

Jeffrey Sherman: And I'm Jeffrey Sherman. And today we're going to discuss the difference between rebuilding a piece or iterative or theseus shipping versus a rewrite and how to tell the difference. And this was brought up a longtime listener of the show was telling me hey, I've got this technical founder, and he has and we were talking about an automation system, which

Isaac: Mm-hmm.

Jeffrey Sherman: For those of you who don't know, automations is a very common SaaS piece of Assass where the users can set up ⁓ workflows to happen automatically in the background. And because they are a core piece of assass, they're often built early, and then people want to rebuild them. ⁓ and so you get ⁓ you know, I've got automations one and then automations two and then automations three, and so on and so forth. And so this story is like, ⁓ well, the founder, you know, we've had this automations thing and it's

Isaac: Mm-hmm.

Jeffrey Sherman: ⁓ the the automation's builder is a decade old and it's in the wrong technology. And the founder got annoyed and he had an epiphany. He's like, ⁓ I know what it should be. I know how to what it should look like. And he said, Technical founder. And so after a decade, he sat down with an LLM and he's like, Boom, knocked it out, and it's gone from PHP to React. And here's this new thing, and it's everyone says, ⁓ wow, this is great. And so then this person's like, Well, does this invalidate?

Isaac: Mm-hmm. Well they're gonna say, ⁓ wow, it's so great because he's the he's the leader.

Jeffrey Sherman: Yes, he di yes, because he's the leader and I'm sure it was perfect, and it had the cats and the dogs sleeping together. ⁓ but take it as a given ⁓ for the purpose of this story that it is actually great. ⁓ in you i in the tr reality underlying the story, the existing thing was bad. So almost anything would be much better than the existing thing. And it had a technology shift which needed to happen.

Isaac: Yeah, ⁓ yeah. Mm. Okay, sure. Yeah.

Jeffrey Sherman: Because the original one was server side PHP and this is React. Well, it's not server-side entirely server. Anyway, moving along. And so it's like, ⁓ well, does this invalidate your thing of we'll never rewrite? Because here the founder has rewritten this. And I said, Well, no, because it he's exactly what we're talking about. He's theseus shipping. He has rebuilt a part of it. He's changed the piece. He has changed the presentation layer.

Isaac: Mm-hmm. Mm-hmm. Right.

Jeffrey Sherman: Because he didn't change any of the backend endpoints, which also means he didn't change any of the model. And so what he has done, it's entirely 100% backwards and forwards compatible with the existing stuff. There's the UI thing with the PHP version, and there's this UI in the React version that's new. And if you made one, it would work in the other, and vice versa, because they're using the same endpoints. ⁓

Isaac: Yeah.

Jeffrey Sherman: And more importantly, even if you took that as well, ⁓ you know, the an automation system is much more than a presentation layer, because it's by design, you're talking about a a scheduler and an e and a runner and all of the retries and all like there is so much encompassing of an automation system that even if it's a well built system and you have a very fancy UI, the UI is never going to be more than 10% of this whole thing.

Isaac: Yeah. So it sounds like ⁓ it's like if you tell somebody you remodeled your kitchen and what you really did was paint the walls and take a cabinet down. But all the plumbing's the same, you didn't have to change anything about the kitchen itself. It's like it's a very it's an interesting thing to say. I would never say I remodeled my kitchen with such a small change. It's the same thing, you just added a different kind of presentation view to it.

Jeffrey Sherman: Right, and that's I think what we're talking about here is people use these words interchangeably and how you can tell the difference. Like to me that's the difference between a remodel and a gut rehab.

Isaac: Mm. Yeah. Yeah, we've had tr trouble, I think, in general, with these re-words. Rebuild, refactor, rewrite, remodel, you know, like ⁓ because rehab. We're using ⁓ unfortunately there's like this terminology of what it means in English and what it means in technology. And so I I but we we've even had an episode on this, like, what do we mean? Because one person said, don't rewrite it, rebuild it.

Jeffrey Sherman: There's there's Rehab. Mm-hmm.

Isaac: And to anybody else who's not even tech savvy, if you you know, if you said you're gonna redo something versus rebuild something, right? That sounds like the same thing. Right? And so somebody else was making their own case that rebuild means, ⁓ no, don't build an exact replica of the old system, build it towards current modern day business needs versus what you built ten years ago for the old business needs. And I'm like, sure, I like your definition of that. But how do you sell that to everybody? Is what you mean by

Jeffrey Sherman: Mm-hmm. Right. Mm-hmm.

Isaac: rewrite because when we're talking about never rewrite or the rewrite trap, we're saying never do this huge big bang rewrite of the entire system. But then but you know you you don't want to say that phrase over and over and over and over and over again. So you say never rewrite. I mean but you lose some of that context each time. So it's difficult when someone comes back and says, Well, you said don't rewrite it. I'm like, ⁓ in our case that was that's just a refactor. Well isn't refactoring rewriting it? Well in our case refactoring means changing Make making the code simpler but not changing the behavior, right?

Jeffrey Sherman: Right, goes back to ⁓ off the very first episode we ever did on the podcast. one of the comments afterwards was, ⁓ so you're saying don't rewrite, instead rewrite.

Isaac: Yeah. Yep. So it's confusing. And so it's a it's a real language problem because of the syn synonyms there. ⁓ so w in in in the book that we're writing, there's even a page on on definitions, like a you know, to let people know people use a lot of these terms interchangeably. And it's important, it's not splitting hairs here. It's very important to be specific with what you mean when you say these things. If someone says, Hey, I want to rebuild automations, and you go, Hey, well, ⁓ what do you mean by that? and they go,

Jeffrey Sherman: It's confusing. Mm-hmm.

Isaac: ⁓ I think it needs a fresh coat of paint and it looks kinda weird. Like, ⁓ thank God. I thought you meant rebuild the back end in PHP from PHP to Ember or whatever. Or I guess PHP ⁓ Ember's front end. ⁓ rebend yeah. Rebuild ⁓ the data structure behind it, ⁓ so it's not even using the same I mean MySQL and it's using something else instead. You know, that that's a re as we've been telling it a big bang rewrite. How we just we completely change the entire thing. You know, ⁓ and we even have an episode talking about is

Jeffrey Sherman: That wouldn't make sense. Java. Mm-hmm.

Isaac: A front-end rewrite, a rewrite, you know, so we can go back and point them to this episode. ⁓ right, so we did we did one on that because the same thing got brought up before, but then this sounds closer to what they're talking about, which is more of a front end thing. But the thing that I want to drill home to any listeners that haven't gotten the message this far is plain and simple, all we're saying is everything should be delivered safely and iteratively. So things you should never take on a huge project.

Jeffrey Sherman: Mm. I had forgotten we yes, we did do an episode on that.

Isaac: In and of itself, you should always break it down into pieces that are easy and safe to deliver. If there is nothing else, screw all the rewrite and redo and rebuild and whatever. The these shipping is just saying iterative delivery. And if you can deliver the front end piece safely and decoupled from any other things you want to do, that's what we want you to do. We're saying don't do everything, do tiny things. That's the message.

Jeffrey Sherman: Yes. Right. And and there's two specific things here that I want to highlight with this story is one, because they were the in this case it was only ⁓ a front end thing and all the back end stayed the same, it was completely compatible with the existing stuff. ⁓ and it would like it was backwards and forwards compatible. So you could release it like in an A B fashion, be like, ⁓ would you like to see what's coming up? And you p say this is this is the beta version. Then you could show it to customers and they could say, ⁓ there's a bug. And you go, ⁓ well, fine, go back to the original. Or you can get feedback, right?

Isaac: Yeah. Right, and that stays in line with our concepts of feature flagging things, gating things, rolling them out, strangler fig if we wanna deprecate some other things later, different endpoints or different features. Yeah.

Jeffrey Sherman: Mm-hmm. Right. And the second thing is you always have working software. ⁓ and this is it's an agile thing, but at like at the end of the release, you have working software. So in this case, if you redo the front end in one large chunk and then boom, you now have working software. But if you had done automations 2-0 and built a new data model that, you know, it contained all the things that you learned.

Isaac: Yes, yeah. Mm-hmm.

Jeffrey Sherman: Over the last decade from running automations, which I'm sure there are plenty, and you're like, ⁓ it this could be a so much better data model that would work so much better. The code would be so much easier if if we could just start off with a new data model. And I'm sure that's true. We could fit the problem you because now you know so much more about the problem scope. You could build a new data structure that would fit the problem scope better, but now it's not backwards compatible. Now you also need

Isaac: Yeah.

Jeffrey Sherman: a new execution system and a new monitoring system and all this n other new things and it that's a huge thing. Now you're not theseus shipping, you're not iteratively delivering, you're doing a rewrite.

Isaac: We should change the name from Never Rewrite to Always C Cus Ship. Maybe that sells our message better. After all this time.

Jeffrey Sherman: Yes. Yes. That that sounds like good good selling. ⁓ I'm reminded I grew up in Southern California and I'm reminded of a of a piece of ⁓ nonsense that it it it's not nonsense, but it in Southern California w in the eighties when I was growing up, the new if you the taxes, the the amount the taxes could go up on a house, property taxes, were limited.

Isaac: Less confusing. Mm.

Jeffrey Sherman: But if you built a new house, they would just start over. So it'd be like, ⁓ well, you're paying two thousand dollars of property taxes and you should be taying paying ten thousand dollars, but we don't want to basically push you out of your home, so it can only go up five percent a year. Right. So it what happened is in Southern California, well, in California, property values went way up. ⁓ and but and people were losing their houses because they couldn't afford property taxes, even though they hadn't done anything. And so they said, okay, well, we're gonna cap the rate of change on existing houses for property tax. So if you sold your house or you built a new house, then it would jump. But if you kept living there, and so people would do rehabs, and

Isaac: Mm. Okay.

Jeffrey Sherman: The basically this loop law, a loophole in the law, as long as you left one wall standing, it was a rehab ⁓ for tax purposes. And so you would come and you would see them knock down the whole house except for one wall. And then they build a brand new house, but keep the one wall. And so it was a rehab and not a new house for tax purposes. Because the tax had it, because they had defined this is the definition between a new house and a rehab.

Isaac: Interesting. Okay.

Jeffrey Sherman: Right? And that but this is the silly kind of thing that law constraints have. And software has the same kind of silly constraints. ⁓ they're just not as somewhat absurd as this one, but where you just ⁓ well if it's because if it had been two walls, they would have figured out a way to keep two walls. Right? It's just wherever you draw the line.

Isaac: Okay. Yeah, yeah. Yeah. ⁓ yeah. If it can be what is that? If it can be measured, it can be gamed. Yeah. Yep.

Jeffrey Sherman: Gaming the system. Yeah. All right. Well, with one wall standing, should we I think we're done done here. All right. Thank you all for listening. I'm Jeffrey Sherman.

Isaac: Yeah, sounds good. And I'm Isaac Askew, and this is always C C S Ship. Never rewrite.

Jeffrey Sherman: Yes. Never rewrite.