Terminology: Rewrite, Refactor, Rebuild, Redo? (Ep. 162)

Welcome to Never Rewrite. I'm Isaac Asimov. 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 uh and how to tell the difference.

And this was brought up uh a long-time listener of the show was telling me, "Hey, I've got this technical founder and he has and we're talking about a automation system which for those of you who don't know, automations is a very common SaaS piece of a SaaS where the users can set up workflows to happen automatically in the background. And because they are a core piece of a SaaS, they're often built early and then people want to rebuild them.

Uh and so you get uh you know, you've got automations one and then automations two and then automations three and so on and so forth. And so this story is like, "Oh, well, the founder you know, we have this automations thing and it's uh the the automations 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, "Ah, I know what it should be. I know how to what it should look like." And he's a 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, "Oh, wow, this is great." And so then this person is like, "Well, does this invalidate They're going to say, "Oh, wow, it's so great." because he's the he's the leader. Yes, he because he's the leader and I'm sure it was perfect and it had the cats and the dogs sleeping together. Uh But take it as a given uh for the purpose of this story that it is actually great. Okay, sure.

And you know, in the 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 cuz the original one was server-side PHP and this is React. Well, it's not server-side entirely, so anyway. Moving along. And so it's like, "Oh, well, does this invalidate your thing of well, never rewrite?" Cuz here the 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. All right. Because he didn't change any of the back-end 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. Yeah. There's the UI thing with the PHP version and there's this UI in the React version that's new. Uh-huh. And if you made one, it would work in the other and vice versa because they're using the same endpoints.

And and more importantly, even if you took that as well, oh, 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 a 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. Yeah.

So, it sounds like uh 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. 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 Yeah. To me, that's the difference between a remodel and a gut rehab. Yeah, we've had trouble I think in general with these re- words. Rebuild, refactor, rewrite, remodel, you know, like [laughter] Because Rehab. We're using um Unfortunately, there's like this terminology of what it means in English and what it means in technology. And so I I we've even had an episode on this. Like, what do we mean?

Because one person said, "Don't rewrite it. Rebuild it." And to anybody else who's not even tech-savvy, if you you know, if you said you're going to 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, "Oh, no. Don't build an exact replica of the old system. Build it towards current modern-day business needs versus what you built 10 years ago for the old business needs." I'm like, "Sure. I like your definition of that.

But how do you sell that to everybody is what you mean by 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. Right. But then but you know You you don't want to say that phrase 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, "Ah, in our case that wasn't That's just a refactor." Well, isn't refactoring rewriting it? Well, in our case, refactoring means changing mak- making the code simpler but not changing the behavior. Right? Right. That goes back to uh the very first episode we ever did on the podcast. Yeah. Uh one of the comments afterwards was, "Oh, so you're saying don't rewrite, instead rewrite." Yep. So, it's confusing. And it's confusing.

It's a real language problem because of the synonyms there. Um so, in in in the book that we're writing, there's even a page on definitions. Like a, you know, so let people know people use all of these terms interchangeably. And And it's important to It's not splitting hairs here. It's very important to be specific with what you mean when you say these things. So, if someone says, "Hey, I want to rebuild automations." And you go, "Hey, well, what do you mean by that?" And they go, "Uh I think it needs a fresh coat of paint.

It looks kind of weird." Like, "Oh oh, thank god. I thought you meant rebuild the back end in PHP from PHP to Ember or whatever." Or I guess PHP or Ember would be fine. Um they've been Yeah, rebuild uh the data structure behind it. Uh so, it's not even using the same I mean, MySQL, they're just using something else instead. You know, that that's a re- as we've been calling it, a big bang rewrite. How we just we completely change the entire [clears throat] thing.

You know, um and we even have an episode we're talking about is a front end rewrite, a rewrite, you know. So, we can go back and point them to this episode. Mhm. I had forgotten that. Yes, we did do an episode on that. We did We did one on that cuz it's the same thing that brought up before. Well, 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 in and of itself. You should always break it down into pieces that are easy and safe to deliver. If there's nothing else, screw all the rewrite and redo and rebuild and whatever. The thesis 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. And And there's two specific things here that I want to highlight with the 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 was like it was backwards and forwards compatible.

So, you could release it like in an AB fashion. Like, "Oh, would you like to see what's coming up?" And you say this is this is the beta version. You can show it to customers, and they can say, "Oh, there's a bug." You can go, "Oh, well, fine. Go back to the original." Or you can get feedback. Right? Right. And that stays in line with our concepts of feature flagging things, gating things, rolling them out. Strangler fig, if you want to deprecate some other things later, different end points or different features. Yeah.

And the second thing is you always have working software. And this is It's an Agile thing, but it 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 over the last decade from running Automations, which I'm sure there are plenty.

And you're like, "Oh, this could be a so much better data model that would work so much better. The code would be so much easier if we could just start off with a new data model." And I'm sure that's true. Yeah. You can 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 a new execution system, and a new monitoring system, and all these other new things. Yeah.

And if that's a huge thing, now you're not Theseus shipping. You're not iteratively delivering. You're doing a rewrite. We should change the name from never rewrite to always Theseus' ship. [laughter] Maybe that sells our message better. Yes, that that sounds like a 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's not nonsense, but it in Southern California in the '80s when I was growing up the new if you the taxes the the amount of taxes could go up on a house property taxes were limited. Uh but if you built a new house, they would just start over. So it'd be like oh, well, you're paying $2,000 of property taxes and you should be paying paying $10,000. But we don't want to basically push you out of your home, so it can only go up 5% a year. Okay.

Right. So what happened is in Southern Califor- well, in California property values went way up and what 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 going to 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 Okay.

Uh and the basically this loop law a loophole in the law as long as you left one wall standing, it was a rehab uh 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'd 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. [laughter] Okay. Right. And then but this is the silly kind of thing that law constraints have.

And software has the same kind of silly constraints. Uh they're just not as somewhat absurd as this one, but where You just Oh, well, if it's Cuz 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. If it can be What is that? If it can be Gamed it can be it can be gamed. Yeah. Yep. All right. Well, with one wall standing, shall we I think we're done. [laughter] Yep. Thank you. All right. Thank you all for listening. I'm Jeffrey Sherman.

And I'm Isaac Askew, and this is Always See the Ship. Never rewrite.