Over Optimism of Rewrites in Software Engineering - Principal Engineering Manager AMA

All right, the streams are streaming. Oh, maybe not. I might have broken might have broken Instagram. What's going on here? Welcome, folks. We have a topic that's going to be about rewriting code, which is pretty fun on code commute. So, we'll get into that. I just want to fix up my my live stream here for Instagram folks. Rewriting code. What a fun [snorts] topic. Is my mic working today? Yes, it is. Good news. Hello on kick. Good to see you. I can't see your your GIF. It's too small. >> [laughter] >> Oh, I probably put the wrong thing in here. That's probably what happened. Dumb me. Okay, we'll get that going for Facebook folks. So, in general, if you're new to the live streams, they're in AMA format. So, if you have any questions along the way, regardless of whatever we're talking about, just jump in the chat, ask away. Um, I'll usually try to wrap up my thought and then get to the chat and then uh try to answer for you. But, um, obviously I'll try my best to complete my thoughts before jumping over. But it'll be fun. Um, definitely meant to be interactive, right? So, um, don't don't hold back if there's stuff you want to ask. Uh, there's a lot of people that are repeat viewers that will come back for Mondays and stuff when we do these streams. So, uh, they'll jump in the chat sometimes. They'll answer questions for you. They'll share stuff. So don't be a stranger. The whole reason I do the live streams is so that you can interact and ask questions. Otherwise, a lot of this [clears throat] stuff makes it onto code commute, which is actually where this topic comes from. So for a little bit of background, especially if you're new, um I have there's Devon. See, Devon's a repeat offender. Um Devin is checking out code an awful lot. Devon also joins the live streams. Uh really appreciate you being here, Devin. And um so if you're not familiar uh the way that I generally do my content uh across channels is on code commute. It's a vlog channel that I have on YouTube. People can submit questions and stuff related to software engineering, career advice, that kind of stuff. And then I make a video response usually when I'm either driving to or from CrossFit or uh to or from work. And so that's a lot of fun for me because that's the kind of stuff that I really enjoy talking about. And so that gets translated uh the sort of best performing or mo most engaging code commit video generally gets translated into a newsletter. So you can check that out here. One sec I'll put it in the chat. It's just weekly.devleer.ca. weekly.devleer.ca. And so it is an email newsletter. No, you don't have to subscribe to the email. If you just go to the website, you can usually see whatever the article is going to be. And then I use that for the live stream topic as well most of the time. The last couple of weeks we were actually coding live uh which was a lot of fun. Uh unfortunately I feel like in both of those sessions I didn't actually write as much code [laughter] as I was just blabbing away about things. So apologies for that. Um but sometimes we will code on these. Um given that AI is a really hot topic. I've been trying to demonstrate using different tools and things like that. So, you can check out my main channel which is just Dev Leader. If you're on YouTube, you're not on my main channel right now. Um, you are on my one of my other channels. And so, check out Dev Leader. That has a lot of uh sort of examples of me using AI tools to try building things. And [clears throat] I try to take the perspective generally that like I I don't want to just show you something working perfectly and being like, wow, like, you know, everyone's cooked. AI can do everything. There's a couple videos where I was trying out tools and got really lucky that they just worked and built something and like that was pretty cool. So, you get like a genuine reaction out of me when that happens. But, um, most of the time I'm trying to show you like here's my workflow. Here's where it falls down. Here's where it's it's doing well. Um, but you can check that stuff out on Dev Leader. So this topic is uh something that I I don't know I I hold near and dear to my heart. Um [laughter] software rewrites. Uh man, I was laughing. I took a screenshot and I forgot to make a post about it for code commute folks. But um the there's, you know, a handful of people that regularly comment on videos and stuff on code commute. And when I made this video response to uh rewrites and refactoring and talk, I had a bunch of people that commented, "Hey, I'm doing a rewrite right now." And I so I took a screenshot of it and I was going to say, "Guys, come on. [laughter] We're saying don't do it." Um, but it's a it's a thing that comes up for all of us in our software engineering careers, probably multiple times. And the the whole idea and the whole reason I was doing this topic is that this originally came up on a Reddit post. And so the person on the Reddit post was saying, "Hey, I've been, you know, in software engineering for like eight years or something like that. Uh, is it just me or does it seem like uh when we try to do rewrites like we're always surprised that it's like gone over budget?" I was like, "Yeah, man. like this is going to this is a good topic because that's exactly my experience is every single rewrite is always always always overbudget and so I wanted to talk about some different perspectives that I have on this for why I think that happens and of course because it's a live stream and there is a chat like would love to hear from people uh on their experiences on this kind of thing because I think if people do engage in the chat what you'll probably notice is that there's some there's probably some common themes. I hope that uh what I've written about and what we'll you know what we'll talk about from my perspective resonates with people and I'm also hoping there's some stuff that like if people are sharing that it's like hey I maybe I haven't seen that like that's a good point or I didn't talk about it we should cover it. So feel free to jump in the chat as we're going through this. But that's the topic today. Why do we always go over budget with our rewrites? And so um like I said common theme that I think most people work will experience but I when I was thinking about this to talk about it on code commute I was saying that I think most of the time most of the time I've seen rewrites almost come from like the engineering side and I'm not saying that it's impossible that you have like a productled rewrite or some pressure for a rewrite. I've heard of people, you know, I've heard of engine like in the past six months, I suppose, I've heard of engineering teams being told to to rewrite whatever this means, rewrite their architecture um to like leverage to to be MCP based and they're like, well, that's not even that's not even what like our product doesn't fit into something like that. But um you know, the more buzzwords you slap together, the better, I guess. So, it's not like this kind of thing doesn't happen. Uh I will talk about two examples uh later on in the discussion uh of rewrites that I've been through. Um there have been more talk a little bit about refactoring and stuff as well. Um but I have mostly found that rewrites come from from like the engineering team. And I'm not saying that to like say okay like it's the fault of the engineers like uh get rid of the engineers. They're the problem. It's more that like the I think the motivation at least to start rewrites I've seen come from engineering side and I think that like from you know as a as someone who does write software and and has been a software engineer um I I do think that a lot of the reason that this happens is that a couple things right so if you were to join a team and the product was or the product service was just starting to be built, right? It's the very beginning. Maybe you joined like a couple weeks in or a month in or like whatever. You're you're sub one year or something like that. Things are being built up. Probably if you were to look at the codebase, you're probably not going to totally freak out and be like, "Oh my goodness, like this is so terrible." Like you're going to have people there that are working in a relatively new codebase, right? It's still pretty fresh. Something subear. You can do a lot of damage to a code base in a year or two. Don't get me wrong, and I've I've been there and done that. But it's pretty fresh. So, if there were architectural patterns that someone else someone set out to go do, they're likely still being mostly maintained. And the other thing is likely, I don't have like stats to back this up, but likely the people that started it and have been working on it are still those same people. That's just because you're at the beginning of the life cycle of this thing. Naturally, what happens over time with software is that it's being like, you know, it's being built in teams. So, you may have people that change on the team, right? That's a that's a normal thing. Some some people might work on a team for one, two, three years. Some people will be there longer, four, five, six, seven. Some people are there on the team for forever. But reality is not all team members will be there for forever. Reality is you won't be there always right at the beginning. So you're going to have in team members. Okay, that means different perspectives. That's a good thing, but it's also going to mean that you're losing context. And this is a natural thing to happen because we don't document everything we do. And even if you have a really heavy documentation culture, there will inevitably be things that like there's history, there's reasons for selecting things. There's things that will fall off. And just like with people in general, we'll forget things too. But when you're changing members of a team, the um sort of the the tribal knowledge and the history, right, that stuff can kind of fall off. Devon saying in the chat telephone game. Yeah. Right. You just it's not one person that maintains all of the context in their brain perfectly and then people can like summon that from the person. Now the other thing here is that not only does that just not work but the code base is going to be growing and so you will have fragmented information because as a code base grows it's very difficult even if you had one awesome 10x engineer that can do everything to maintain the knowledge of the code base in their head as it's growing. Maybe they can do it when it's small but the more and more it grows the more and more unrealistic that becomes. The other thing is that going back to this idea of like you know you're maintaining this this architectural vision that you have over time that will erode and I don't mean to say that to imply that like no you shouldn't make architectural decisions because they won't matter anyway. Not the point. Um, I think having good architectural decisions allows things to last longer, but they will inevitably as you're adding things and changing things and priorities change and direction changes, it will inevitably not be what you set out for it to be. So along the way, you will pivot. You'll say, "Oh, we didn't design for this." And like you will do some work to get that to go in the right direction. There's going to be situations where engineering doesn't win and you got to ship something and that means okay like there's this tech debt that's been acred. There's going to be times where people want to refactor things. So now you're you're introducing a new pattern in the new direction. The codebase is going to be changing dramatically over time. Okay. So when we layer all these things together it's a little bit chaotic. And what ends up happening over time, the longer this stuff's around, more people change, less uh information is sort of remembered like history-wise, and then the complexity of the code base grows and grows and grows. So, a lot of the time it reaches a point where people are going, "Look, you think this stuff's hard to work with. I think it's hard to work with. Jimmy doesn't like remember anything and Sally's new to the team and like product is on us. They want features and we just can't we can't get it done. We just can't do it right. So what like something's got to change here. And then this genius idea comes to our minds as software engineers. And I say this not to pick on software engineers because it makes sense in my brain too. this genius moment dawns on us where we go, if we're having such a difficult time with this, if we just like wrote it right, if we just made this the right way, we could solve these problems, right? If we just did it right, we could solve these problems. And we know all the problems. We're living them every day. There's this spot in the code. There's this god class over here. There's all these static things that are shared across all this stuff. And that's always causing uh issues. these tests in this class in this file are all you know skipped or flaky and they're always busted like we go design it this way we'll start rewriting it and it's going to be perfect right so I'm exaggerating maybe a little bit but the idea is that at least in my experience I've seen this motivated from engineering teams a lot and I don't blame them right like for those reasons I don't blame them because you get to a point where maintaining and working in some codebase without all the tribal knowledge and the experts around to like to do it for you or to take care of all these things. It can be really hard. Okay. So engineering driven most of the time in my experience like I did uh kind of mention it's not that it has to come from that side. um I have heard of and I have seen I'm trying to I was trying to think of a good example where I've seen it pushed from product side in my in my sort of experience and I know it's happened I think I said it on code commute and I can't remember the example but um I think like we had I remember well and I'll talk about it a little bit more later but I can remember one where given the product requirements we were software is architected currently in particular with our data model it wouldn't match. So product pressure and then engineering being like it's it's basically not feasible unless we do this. Um now the decision the decision to rewrite I think that product did give the engineering team uh sort of the the go-ahad on making that decision. we had to present our case on it. But um is there a good example where product it's the answer is probably yes. I just can't think of one off the top of my head. So it's not um it's not a matter of like blaming one side or the other, right? There are reasons why this stuff comes up. And so I just wanted to share that historically and from my experience has been mostly from engineering. So, the tricky thing with rewrites, okay, is that um the way I'll be framing this stuff a lot when I talk about rewriting until we make a little bit of progress on this is that um rewrites generally mean like a a sweeping like, you know, start from scratch and build the thing until it's done. Okay. So what's cool about that from the engineering perspective like I was hinting at is that you have this clean slate where you're like we're just going to build the right thing, right? We start from scratch. We know all the problems. We'll we'll build the right thing. And then the tricky thing is that I think from a product side of things, the business side of things, what what customers want is that and this is kind of tricky unless you've kind of uh lived I don't know like worked in like more slightly more mature companies where there is like a customer base and stuff like that because I realize some people watching this might be in startups or maybe they don't have users yet or whatever it happens to be. But if you have um hey Thomas, if you have um you know users and there has been feedback and the products existed and it's like the thing that's generating money for your your company. Um the tricky thing is that after a certain amount of time, just kind of like on the engineering side, we're going to talk about product side of things. After a certain amount of time, there are enough features and workflows and use cases and things built into the product or service that you have that there isn't enough people with all of the tribal knowledge on all of those things. Okay. So, one of the tricky parts here is that I often think in general, depending on your organizational structure, I feel like there's almost always some type of gap between uh product focused people and uh and software engineers. And I I don't say that to point at one side. I just think that in general, we suck at communicating. Like, we have to do better as humans. [laughter] So, we have this gap between two groups of people to begin with. And thank you, Thomas. I do really appreciate that. I'm happy to do these sessions. So, we already have this communication gap. We have groups of people that are are um I don't I don't know, we can still be aligned with business goals and we're have the same mission, but each group, you know, product side of things and engineering side and you can think about other uh stakeholder groups that interact here, they have like overall same goals but different motivating factors, right? Like a lot of the time engineers are focused on the architecture of what they're building, the quality of the code that they're working with, the developer experience, right? Like the things that engineers generally care about. And I'm obviously generalizing, but and then the product side is like, well, users are asking for this. I don't care what language you're rewriting in. I don't care that this class is 2,000 lines long. It it doesn't matter. Like, not not to me and not to the customer. But like I hear you if you're saying that's bothering you, right? But there's a disconnect. The the tricky thing when we bring this all together is that even when it comes to having good communication, right? So let's say you have product and engineering working really well together. Even the product people will have the same issue of this tribal knowledge being maintained where they don't know every single feature that everyone's using. They don't know every workflow. They don't know every hidden context menu that happened to be added in over the last seven years. There's just going to be stuff that goes missing. So even if product sits down and goes, "Okay, we're rewriting. Here's the scope of all the stuff we have to have in here," they're gonna miss stuff just like you would if you were an engineer rearchitecting a system trying to make it perfect the next time. You're not going to be perfect. So I'm going to stop to go to the chat for a sec. Hey Ryan, good to see you back as well. Um, this is going to be a tricky question. So Ryan's asking, "You have any any good place that I can get a good editor config file to be used in Blazer Project?" Would mind sharing what you use? I'm doing what you're talking about and Oh, could use a good starting point. Awesome. Um, so I think there's probably some good repos uh at least like Microsoft probably has some. And the short answer is I don't have one off the top of my head. What I would try because like as I'm streaming here, I'm not unfortunately not uh going to research it. I can I can look after because I'm sure there are some but what I would try it might be a cool experience is like depending on what I'm going to use the AI word I'm sorry but depending on what your favorite AI tool is maybe ask it right say you're making a Blazer project you want to optimize for whatever you're interested in and you want a really good editor config to start with and maybe ask a couple and see what that looks like I would maybe start with that as a initial spot But I do think there are repost that should have it. U I say this because with everyone [laughter] with everyone making repos for markdown files for agent instructions and and scales and all these other things I think thing like basic things like config files if you're a like a .NET developer, Blazer developer in this case. Um there there should be some patterns that are well established. Off the top of my head, I I do not know. So, apologies, but uh Ryan, if you don't find one throughout this stream, uh if I remember, I can try to look after. If not, ping me after and we'll have a gander because I'm sure there's a good resource. Okay, so when we have a clean slate, just to kind of summarize this thought, right, we're starting from scratch. Um you're starting with, you know, nothing from the code and architecture perspective. you're going to build it clean and um on the on the product side of things and like the user experience, you are generally trying to get to feature parity. the uh the business side of things like the product folks that are, you know, trying to define what feature parody is. Um they might actually say, "Hey, I know the current offering that's been around for 10 years has this feature and that feature, but like we actually don't need all of that, right? We're making a conscious decision to not include it." Or um this other thing that can happen obviously there's a lot of things that can happen but one one other thing that comes to mind is that okay you have an understanding of what product wants in this new fancy rewrite that's going to solve everything. you have an idea of what engineering wants and you go hey wait like we actually see a misalignment rate at the beginning but maybe we can get on the same page and agree that if we change our architecture this way and we change some of the user workflows this other way like that actually cleans things up a lot like we can both win out of this from the product and engineering side because we get a nicer design in our architecture and we get a a nicer user experience based on the flows that we want to Awesome. Yeah, please uh send a caveat, send a a request. Uh I appreciate you being here. So, it's a tricky spot, right? And I don't know why we're always so gung-ho about jumping into the rewrite. So, the next thing I'm going to talk about is uh splitting resources because this one there's some some elements of this and I should just put the link in the chat if you haven't uh gone to the newsletter page because if if you don't know like when I do these live streams I'm generally kind of looking at the the newsletter to to get the flow of the conversation. But the when we're talking through this kind of stuff, what I'm hoping people can can get out of this is just like not oh that's Nick's perspective. It is just my perspective but that you can think about things in different ways too or challenge yourself because if you are a software engineer you may have a big bias towards software engineering things. So maybe some of the things I'm saying are already resonating maybe they're not and you still have you know perspective related to software engineering focus but the the next thing I'm going to talk about is like a resource split and I want you to you know challenge yourself to think about things from a different side. So maybe what it looks like from a business perspective or what it might look like from a manager or project manager's perspective. So okay, we're going to do a rewrite. Awesome. So what does that mean? Who's who's working on it? This obviously depending on company size, team size, all this kind of stuff, this can look dramatically different. So we got a bunch of options. Okay. Point is, we only have so many. I'm not going to talk about getting AI to go do a rewrite. You're still going to need a human to to babysit it at least. So, um, we only have so many people, okay? And so, if we want to go start working on going to block people in the chat, holy, get these bots out of here. If you only have so many people and you want to do a rewrite and let's use an example, you have 10 people, okay, on a team that can work on this. Do you take one person? So, nine people stay on the existing thing and you take one person and go put them on the new fancy thing that's going to save the entire company. Well, you could you could do that because it means that the thing that's already paying the bills, right? Has the users coming in that's still well staffed, right? It's not going to fall apart. So, like that's good. And the new thing that you're building, like it at least it's it's getting worked on, right? except it's it's probably going to take a really long time. And I guess because one person's working on it, all that, you know, all those opportunities to be bouncing ideas back and forth, get different perspective and and stick to that plan of doing the right thing like, okay, maybe that's not going to that's not going to fit so well. Okay, so you know what? One person's not a good move. Let's move two people over. Okay. And I'm not going to go through all the numbers from 1 to 10, [laughter] but I want you to kind of play that through in your mind and think about like at what at what spot is it good? Is it a good split to go 50/50? Because that means that you're not willing to comp like compromise on going allin on this new path forward, but it also means that you are going to keep the current thing afloat. And like is that enough people to sustain it? Is that enough people to to build on the new thing to get it done on time? Whatever that is. Do you take everyone do you take everyone off of the old thing and you say only in emergencies? [laughter] Only if our service is crashing and on fire. Only if our product has uh you know a new bug that shows up that's stopping everyone from using it. Only then, only then are we going to put some emergency resource back onto it, but otherwise everyone full steam ahead on the new thing. What's the right balance? Right? Because no matter what, there's going to be a divide in focus. Um, yeah. And then in the chat here, KSG7882 says, "What you think that at what point does maintaining the system start hurting customer experience enough that a rewrite becomes a business decision?" Yeah. So that's an interesting point, right? that um you may have pressure from the business and this obviously depends on um I don't know like the the composition of your teams um who's interacting with what right so when I'm talking about business or product versus engineering um I am sort of distinctly referring to sort of like separate groups of people physically but these these sort of responsibilities can absolutely overlap, right? You could be at a small company and it's it's literally the company is a team [laughter] and so the the product person is also your manager who's also an engineer. But in terms of these roles, right, in terms of these responsibilities, I think you're absolutely right that you could have this situation where the customer experience is so bad. I don't know if I would um I have seen explicitly that from the business side they're like therefore you must rewrite but I think what could happen is if you had a lot of pressure from the business side to be like or even like tech support right customer service being like everything is on fire this is terrible and all this pressure goes back to the engineering team fix it fix it fix it right and the engineering team's getting this pressure of new feature new feature but also fix it fix There's probably this critical mass or this tipping point where it's like, look, we can't, right? This thing is on fire. It's a pile of crap. We just have to like we have to rewrite it. But where where the actual motivation comes from to do it? I think you have different sources of it. Who comes up with the idea, you know, TBD, I think I think it can be any side in my experience, primarily driven by engineering. Ryan says rewrites suck. I'm doing one where I take a pure HTML uh and recreating inside of Blazer. Um and they also suck when you're dealing with new technologies and coding frameworks. Yeah. Well, and so Ryan, I'm not um I don't want to What's the What's the right way to say this? I don't want to say this. So, what you just said, right? Um rewrites suck also when you're dealing with new technologies and coding frameworks. So, if you're going to rewrite something, and I was kind of uh exaggerating a little bit where it's like, oh, you know, we're going to rewrite it. We're going to do it perfect this time, right? It's the silver bullet. We'll do everything right. Well, if it's a new technology and a new framework, do you think you're going to get it right the first time? [laughter] Like, probably not. Um, and that's okay. And that's the reality. That's another factor that ties into this, right? I've seen uh I've absolutely seen rewrites of products in different languages entirely different languages frameworks absolutely everything is different right and it ends up being a decision that is made and it's like look we hopefully at least in my experience it has been we understand what that's going to mean and I will maybe share more detail on that later depending on how things go maybe I won't give the details specifically quickly, but I'll give a little bit more context. Um, and then Joel says in the chat, "Yeah, it's situational. There's no single answer other than it depends." That's 100% correct, right? It's a This is why it's a meme in software engineering. It depends. It depends because it does depends on your context all of the time. And every time I say the word context almost I try to remember every time um I will always encourage people if you do not know uh Derek Co Martin or you don't watch Derek's channel it's called Code Opinion my he is one of my favorite people to watch and listen to talk about this kind of stuff. So Derek Co Martin code opinion and the reason for that is that he does such a good job taking anything you want to debate about software engineering. He does such a good job of it and you could be totally convicted that like I don't know like microervices are the best thing and in your experience they've always worked or you think Rabbit MQ is the best thing that's ever happened to this planet and in your you have a hundred experiences and they've all been perfect with Rabbit MQ and what's really cool about how Derek explains things is that he is so good at going back to it depends context is king right? Your context is going to drive what you're doing and then walk through scenarios that seem like so there's so they feel so obvious when he talks about it because you're like I mean yeah like that is a really good example of like where we wouldn't want to do it and he's like right so why would you say you always should do this or it's the best and there's no other solution. It's like you can't predict every possible scenario [laughter] that you're going to be building in. So you can't say this is always the best or never use this. It's like it just depends on your context. So Derek K Martin code opinion I would recommend him anytime every time to people that want to learn about uh software engineering. And uh I would even take the software part of that off. Um, one of the things that I felt that I learned learned learned learned I don't know terrible timing for that in engineering in university was really to do pros and cons analysis like drop the software part. How do you look at different tradeoffs? How do you do pros and cons? How do you weigh things? How do you do this analysis? Get valid data and then make decisions based on it. Right? That's and I feel that he does a really good job of that. Um, so yes, I do agree, Joel. Situational. Um, and Ryan, back to the the rewrite part. No, you won't get it right. My code is uh so much vanity code right now. [laughter] You'll clean it up. I believe in you. You'll I think you'll no matter what, you're going to learn a lot. So, in the worst case scenario, maybe it's a little bit of spaghetti in the beginning. You will learn so much. So, um, and then Devin says, this is what I mean. these guys watching Code Commute leaving comments on the video being like, "Oh, I'm I'm rewriting stuff." There's Epic Technav. I don't see him in the chat, but he was someone who commented on the video saying he's doing a rewrite. I can't remember the other username. There was another person that said they're doing a rewrite. Guys, [laughter] stop rewriting stuff. Deon says, "We're rewriting from React to Blazer. However, step zero is every bit of cleanup we've ever wanted to do in the current app. So we have an uncluttered starting point. Interesting. Very interesting. Okay. So the resource split is a real thing, right? It's like what is the answer? As Joel said, it depends. And it depends on a lot of different things. It depends how much do you have a timeline? Is there an urgency for this kind of thing? Um you know, is your service is it that like supporting it is actually pretty lightweight? It's not you're not rewriting because it's bugridden and falling apart. you're rewriting because your path forward is not supported by your architecture. Right? There are so many different factors here. So the next time you are talking about a rewrite, I want you to think about this. Right? You might not even be an individual who feels empowered in your situation that you get to make a decision on this. Right? You like, I don't know, I'm not telling, you know, my peers that they have to go work on this. Maybe that's their manager, my manager, someone's boss's responsibility. But I think it's really interesting if you can think through this stuff and try to understand what the trade-offs are. Okay. Um, and then Joel is saying for context, I used to do rewrites of applications as my primary function in banking and supporting the legacy code for 21 years. So Joel has perhaps seen a thing or two. Possibly possibly even three. I dare not say four though. But yeah, like probably seen some stuff. So thank you for sharing that, Joel. Um, okay. So, this thing gets kind of scary because I've seen this happen in almost every rewrite I've I've been part of where there's this point because you go over budget, right? You go over budget because we're okay, we can't as software engineers, we can't even predict and get a twoe sprint, right? You're going to rewrite some software that's been around for eight years. You're going to redo eight years worth of engineering effort. And you think that you can estimate that with any degree of accuracy? This is why it's always overbudget. Just for the record, it's because no one can estimate that. It's it's crazy. It's just it's not going to be realistic. Doesn't mean that you can't. And I I should have clarified this um sooner, so I apologize, but I do not want to sit here and tell you that you should never rewrite. I should have said that earlier, so I apologize. My intention is not to say to never do it. It's just that we always overestimate how much effort and time is involved. Okay? So [laughter] try to bring the perspective so that the next time you're doing it and you're like ah it seems like it's like I don't know like 8 months worth of work if we want to rewrite this application that's taken uh 27 years to put together like it's not it's just simply not going to take that short amount of time. You will be disappointed. Your stakeholders will be disappointed. There's got there's got to be more that goes into this. So, the scary trap that I want to talk about is this point where you're like, we've been investing, right? We we moved everyone off of the the core product onto the new thing. Oh, 10 people went over and they're building the new thing and it's behind schedule and it's falling more behind schedule and like, okay, we're we're now at the, you know, we're coming up on a week out from the original target date and people are saying there's still another year's worth of work. Okay. Well, you pull the rip cord, right? Get out of there. You already have the working product. It's It's been staying afloat this entire full year with no one looking at it except for for Jimmy who had to jump in there to save one fire, right? Like, it's surviving. Customers are still using it and paying for it. But you're one year in. You've had all of the engineers working on this thing. Everyone's time and effort has gone into this thing and it's still a full year out, a full year behind schedule. You stop or you got to keep pushing forward, right? It's only one more year. It sucks, but like we put so much into this. We've we still agree this has to be the path forward. Got to keep going. this conversation happens. [laughter] It sucks. And um I think there are two cases I can like come to mind and I will try to talk about them and two cases that come to mind where we just kept pushing through and they were successful in the end but oh my goodness [laughter] oh my goodness were we overbudget. Oh my goodness was it way more work than we thought. Right? Everything was not as planned the entire time and it went way over budget, way over time, but in the end the software that was built um you know succeeded. Um was it the silver architecture perfect? Absolutely not. Far from it. But we rewrote it. So, um, just as a heads up, I want you to keep in mind that there's probably a point in some rewrite phase where when things are really behind budget, really over budget, my goodness, words. Um, it is Monday. So, when things are really over budget that this conversation comes up where it's like, what should we do? And again, you might not be you may be, but you may not be the person who's in the position that has to make a decision on that, but you might be part of the conversation, right? Like, why why is it going over? Like, I thought you said that this feature and that feature doing this layer in the architecture was only going to take this long and like you're still working on that. And it's like, yeah, but so is Sally and Billy and any other random name I can think of. Like, everyone's behind or like this. there's only one feature that was ahead of schedule. Like everything else is way more complicated. We didn't know that we're going to have this thing come up, right? The other thing is that along the way, you're building this stuff and inevitably what's going to happen is you go to introduce one of the features to meet feature parody and you go, "Oh crap. Oh, we didn't think about this one. Oh, it doesn't fit into the how we designed this stuff." Okay. Well, we gota we'll cut a corner here. We have to get this feature and we'll cut a corner, right? And it could be something that came up as a surprise to the product team like, "Oh crap, we didn't think we needed that hidden context menu, but we definitely do. We need the hidden context menu." Okay. And well, our app doesn't even have context menus. [laughter] We got to go put a design in for that. So, there's just going to be stuff that you didn't plan for. And um if you've been in software development for I I think for any period of time like as your career, you will have already seen things just not going as planned. It's exactly how it pans out all of the time. Things never go according to plan. They go in the direction of the plan, but never exactly the plan. So the plan has to have variability. It has to allow you to adjust. And if you are someone who has not yet started in your career, I'm not saying this to scare you or say like, oh, like then planning is not important or anything like that. It's super important, super helpful. Discussions are incredibly valuable. It's just that things do not go exactly according to plan. You cannot possibly predict everything. There will be something that comes up. And I talked about this in one of my my videos where someone was asking about uh I had uh questions around big tech versus startups. I was talking about in one video planning versus big tech and startups. And like in both cases, you're going to have things that come up that you didn't plan for, right? It's just reality. Devin says, "Our reasons for a rewrite. React sucks. The team is stronger innet." This I'm like check for me personally at least. Um, and then React sucks. The front end needs rethought based on actual usage for versus product uh products original vision and React sucks. Yeah, I'm don't get me wrong, I think that um I think there are people that are really great at working in React. I just I I love working innet. It's just so much more intuitive for me and I I feel very much at home in the ecosystem. So, that's kind of funny to hear, but I I know if anyone is a front-end developer, they're probably like, "Dude, come on. What are you talking about? Like, we know how to build frontends. It's not it's not withnet." But yeah, Joel says, "In high stakes environments, always plan unexpected things will happen." Exactly. Right. Part of your plan needs to be not, oh, let me have a mitigation for every possible scenario. You don't know every possible scenario. I think it's good if you think about some some high-risk scenarios to mitigate for, but your plan should have the ability to adapt. Okay, so anyway, enough on that part specifically. We're going to talk about the solution. How do we solve this problem once and for all and never do a full rewrite ever again? It's the one simple trick that doctors don't want you to know about, right? Um, no. It's uh something called the strangler fig. It's what a cool name. Um, it is coined by Martin Fowler. I wish I could sit here and tell you listen to this thing that I invented. No, if you don't know who Martin Fowler is, uh, go look up Martin Fowler. Um, I think it's a really He's got a cool little story around like why it's called Strangler Fig. I think I tried to put I do have a picture. Maybe I'll I'll flip over. I full transparency. This is an AI generated picture. It literally says Notebook LM on it. But look at this. This is from Notebook LM. How cool is that? It made this like infographic. Can I invigonate it? Can we do that? It's really funny. I'm [laughter] I don't know if it's You can see I'm zooming in just so you know. How funny is that? This is me zooming in. 500% zoom. Okay. Um, can I zoom out? No. Okay. Just This is why I do backend development so we don't deal with stupid stuff like that. Anyway, that's the zoom level you're getting. Deal with it. The idea uh with the Strangler fig is that um Martin Fowler was actually talking about these these plants, these trees. So the concept behind the strangler fig approach is that instead of taking a entire product or entire service and going look this isn't my site Ryan this is Substack [laughter] this is not my site this is absolutely substack I don't have bugs in my front-end code because I don't write front-end code [laughter] that's the only way to to be safe Um yeah uh the idea with this is that instead of rewriting things from scratch, right, and doing an all or nothing approach, you actually do it in pieces. And so in in this newsletter article, again, I will I'll link it again in the chat if you want to check it out. There is a couple of links out to Martin Fowler's site and he has another discussion with a couple of other uh very very wise individuals. But the idea is to do the rewrite in sections. And the way that works is instead of going, okay, well, we're starting from zero and building everything up, you take a section and what you're able to do is you put something like um you can come up with your own terminology for this, but I will refer to it as a facade. Uh so you put a facade layer to kind of split your calling part. By the way, this doesn't have to be web APIs. It could be literally APIs and code. So you put a facade layer and then behind that is your original implementation. So to start you just put this layer and then you start building the new part behind that layer. Okay? So you instead of rewriting everything you say we're going to rewrite this and we're going to do it in pieces. Introduce a facade over one part and then start building the new thing. And then what you do is you start making calls. you start making more and more calls over to the new part. And the idea behind this is that the new stuff strangles out the old stuff, right? That's what this this diagram is trying to show is that instead of taking the, you know, your call path down here to the old stuff, the old roots, we're diverting the call path up into the new hotness, the new goodies up top here. We're going that way. And this new thing is going to get more and more traffic, more and more API calls, whatever it happens to be, until there is nothing going to the other spot. You control that, right? With flighting, however else you're doing it. Um, when I use terminology like this, it's kind of tricky because like I said, it does not apply. I know in the diagram it says microservices. In the article, I try to call out it's not micros service specific. We're just talking about components of a system. So flighting technology whatever it is diverting traffic um and or shifting load right you move it all to the newness and then the other part of the code goes away right there's nothing that uses it anymore get rid of it and you're able to do this sort of call it like peace meal and chip away at parts of your system so that you're not in this position where you're like we have to go do it all at once and you run into this thing where you're way over budget in two years going, "We don't have anything that we can ship." The entire time you use this pattern, you can and should be shipping or or running the service, right? Because you're just replacing pieces of it as you go. Okay. So, um I always like talking about pros and cons of things. Um there is a little bit of guidance in here about how you can do that. I still recommend that you uh defer to to Martin Fowler's uh you know perspectives on this stuff. I I'm not sitting here trying to pretend like I am the authority on this. Absolutely not. Martin Fowler would probably not even say he's the authority on it. But I think he's got a really good the I kind of wrote it here like why I like this. Right. But the idea that I that I do like here is that I rarely ever think that an all or nothing approach is an effective way. Now, if you could do it right, right, if we magically could do the rewrite correctly and we planned for everything and it all just worked, then it may be the more efficient path, right? Because you planned for something, you got it done, and now you got the thing. If you do something like a strangler fig approach, okay, or you're doing other other ways where you're sort of incrementally making improvements, right? Even just uh we're just going to re strangler fig to me is like refactoring almost at like a larger component level. But anyway, um if you're doing these incremental changes versus an all or nothing, the incremental changes will probably take longer because you have this overhead of like, okay, we're maintaining both. We need to, you know, test it live. We're like there's just you have to put the shim layers in. like there's probably more overhead to that, but I think in practice the the all or nothing rewrite is not going to be on track. Spent the whole first half of this live stream saying here's all the reasons why that happens. It's not going to be on track. And so if you acknowledge that if you're doing something like a strangler fig approach, doing parts of a system incrementally, if you acknowledge, hey, look, that might take longer than the original plan, spoiler alert, it's probably going to be closer to being accurate, but you can do it incrementally, right? You get something running the entire time and you get a feedback loop the entire time. You don't wait until the end and you say, "We've built for two years and we finally did it one year late. Flip the switch, send it to the customers." Obviously, I hope no one is doing that, but exaggerating a little bit, right? So when you have this feedback loop the entire time, whether that's for sending traffic to your service or you're shipping new updates to customers and you're using some of the new modules and stuff like that, you can get feedback as you're going, not only from the customers, from the people building it, from the product people working with the engineers on it. There is more of a feedback loop the entire time. I don't care if you are like agile is the dumbest thing ever and that's because you're uh you've been stuck with some version of agile that's not actually agile or you're like waterfall is the dumbest thing ever. How could you do that? In these systems that we talk about when developing software, there is some type of feedback loop. I don't care how big or small it is. There is a feedback loop. In my personal opinion, I really prefer to have a tighter feedback loop. The sooner I can get signal, the more opportunity I have for making decisions. I might not need to do something different, but I have a signal that can help me shift gears if I need to. I really like the idea of incrementally refactoring or incrementally rewriting pieces with a strangler fig approach because of this feedback loop personally. So, um, that's I'm going to pause for a moment. YouTube chat is super delayed, by the way. This is the case on every stream. Um, I'm going to say if you have questions more specifically on Strangler Fig because I'm I'm coming up on the top of the hour and I still want to go through some stuff. Leave them in the chat. Um, I could even make code commute videos for you or if you know, obviously I'll hang around still and uh and answer uh things as I can. But if you do have questions on it, let me know. Um, and I may um, you know, say just go read Martin Fowler's stuff or maybe it's something I can't answer. So, go ahead in the chat. Otherwise, I'll talk about a couple examples from my career. And I have two in my newsletter article and I'll kind of hint at a third one because I sort of brought it up so far. First one was uh before Microsoft and when I was at this uh this smaller startup company, we had we basically had a like a a data problem. And when I say data problem, I don't mean like oops, we screwed up someone's data. I mean we had a a schema for data that just did not scale. and con extra context here. The data is not some like you know huge database or you know um sharded database system that we're running for users or something like that. It's literally just the schema that we use inside of our product that every user has um you know their own instance of. And this data schema like I said did not scale for uh one the amount of D this data schema like I said did not scale for uh one the amount of data we were putting into it. And I'll pause there for a moment because I think it's mentioned in the article. It's a SQLite database. And you might say, "Well, Nick, obviously a SQLite database isn't going to scale." SQLite is crazy performant for just being a little file. So SQLite isn't the issue. It's our schema in the file, not performant for the amount of data that was going in. And then the sort of richness and and the structure that we needed for data was simply not being met by the schema. We had started talking about different ways to sort of like introduce the newness, right? We can start introducing this. We talked about doing like a shim layer into this thing and we started it and then ultimately it kind of came back to like well let's start rewriting. Um, and it was like I can't remember exactly how it panned out, but I remember like they're beating this this [laughter] boat. uh to go do things a certain way and it was like I was I was on the wrong end of that. Um but like we set out to go do it and oh my goodness um it was so much work so behind schedule. This was really all motivated by um you know this fact that we had a data schema that didn't align and then so people were building the new features into the new thing and using this new data schema but everything was new. Everything was new, right? We were designing this new schema and then forgetting about uh domain knowledge just like you know okay schemas in place and it's like that's literally not going to work even though it's brand new because you didn't factor in this this and that. Not going to work. We're building out the UI features and it's like wow this looks good. it feels good and it's like yeah but it's missing AB and C and like without AB and C you're going to have so many users that are pissed off at you and this was just the reality as we were building this thing out in the end the team is totally kickass they worked so hard for so long and they delivered it and it was it was not an effective way to build it just you know would have changed a lot about that but they did And it was awesome in the end. And it took a while after in my opinion to get to what I would call feature par, but by the time they were hitting like feature parody, they were already blowing past in like new awesome capabilities. So in the end, it was successful, just way over budget. I'm going to pause. Uh Baron B says, "How many different categories of standups have you seen exist in practice? new features uh blockers code red how many different uh parents I'm not sure I understand the question how many different categories of standups but then I'm seeing new features blockers and code red so maybe I'm not is there a different word for standup that maybe I'm not getting do you mean like uh people coming together to talk about those things if so then a million but let sorry if you can clarify your question maybe my brain's not turned on yet so I apologize guys. Um, Ryan says, "I feel like I remember you mentioning you use Reream. Am I remembering correctly?" I do use Reream. Is it doing something dumb right now? [laughter] If so, yes, I use Reream. It's often very dumb. Um, SQLite apps. Yes. Um, by the way, like if you have a mobile phone, guess what most apps on your phone use? Um, it's SQLite. So, yeah, SQLite's used a lot. So, that was a fun experience. Uh that is one that is sort of like um solidified in my uh earlier in career time where I'm like oh my goodness like rewrites are are scary business. Um there is one that I will talk about at a high level that is actually closer to a strangler fig type of thing and um you know the it's interesting because if you depending on your zoom level of the system being discussed if your zoom levels at one point you would say that Nick this sounds exactly like a strangler fig like what do you mean it was over budget? Um, so okay, like is the answer that you zoom in more and you do a smaller component to kind of strangle out? Like maybe I'm not saying it's a perfect science or it's going to work every time, but I do think [laughter] I do think if they would have zoomed out further and rewrote more all at once, it would have been much more uh [laughter] overbudget. But the idea behind this one was introducing a new service and uh instead of going okay it's all or nothing we'll get 100% feature parody turn it on and hey like it's it's in business it was truly I don't know what they started with to to start putting traffic through but starting with a very small uh number through but starting with a very small uh number of like scenarios putting traffic through it running it it's working cool okay let's put the next in. Let's put the next in. And then just building out these scenarios. Now, in a situation like this, uh again, we go into it as engineers being like, we have a fresh slate. We're going to use this this good architecture. We're going to take advantage of the fact that in the past we had so much like customization for all these things and everything was a one-off special snowflake. No more special snowflakes. It's going to follow the pattern. It has to follow the pattern. And it does until it doesn't. And then you have a special snowflake. And then keep going. No, no, no, no more special snowflakes. Okay, but just just one more special snowflake until you have a bunch of special snowflakes. And don't get me wrong, architecture is probably still much better, but it's not it's never going to be perfect. It just it's not. So, this again, this has been a very successful sort of a rewrite. Um, sort of like a a strangler fig mixed in there because uh it uses the example of like diverting traffic over and over until you're reduced to almost nothing and then when it's nothing, you kill off the code. It's not being used anymore. Um, just going to go back to the chat. I'll try to message a question. Oh, okay. No worry. [laughter] Appreciate it. uh use with devices and all I hear from my brothers and issues on updates. Um Brian says, "I asked for reream because if you can check we have your stream latency set for when YouTube Oh, interesting." Interesting. There's a stream latency thing. Oh, I wonder if it's on the connection itself for YouTube or if it's actually um like in reream or if it's on YouTube because I actually now that you're mentioning it, I think YouTube on the stream itself, I can set like a delay. I I don't know if it's there's a default or something. I think you can set a delay. So, if someone says something in the chat and you're like, "Nope." And you want to get rid of that. Um there's a delay for it. But I feel like it's working maybe the opposite way [laughter] cuz it's not like I see it and I can do something. It just shows up in the chat. Uh so I'm I'm on the receiving end of when you'd be able to moderate that. But I will check that out. Thanks Ryan. Um the the third example that I'll touch on very briefly because I said languagebased rewrites. Okay. So there is an example of a service and I won't talk about the details of what it is but there's an example of a service where the motivation to rewrite it was actually um you know what this is arguably driven by a a business decision. So the motivation to rewrite it um was essentially so that um it's not one team takes the other team's code and h is forced to use it. The motivation is that um teams come together and have common code. So we're the the goal in that scenario is to is to rewrite common pieces, right? We will come together. We have different scenarios but ultimately there are some common pieces and we should rewrite them and kind of take perspective from from multiple uh from multiple different angles. So come together and rewrite. And then the other part of that uh and I say that that's like maybe more business driven because the I believe the decision for that is business driven even though it seems like a technical thing to go do right sharing your code is a business decision like but but yes it is. And um the second part to that is like it is being done in a language that's not actually [laughter] probably the strongest language for everyone that started in it. And the reason for that is performance. And that's why they picked Python. No, I'm kidding. Um, and it's not C either. And it's not C++. And this is an example of a particular service that is being done in Rust. Well, why Rust? Like, oh, like everything's Rust. In this example, it actually makes a lot of sense. Um, and there was a discussion. How many of the developers working on it are experts in Rust to start? Right? Very, very few. [laughter] What does that mean? It means it's not going to get, you know, off the ground instantly. If you, you know, if you put a bunch of C developers in a room and said build something in C, they'll probably get something up and running in C pretty quick. If you take a bunch of developers that have never used C before and put them in a room, they'll probably still build pretty fast because it's C and it's awesome. But no, they're not going to go as fast. And it's the exact same thing here with Rust in this case. So yeah, the ramp up time is longer. But behind it is like as a business, this isn't something that has a a timeline that's yesterday. Obviously, if the business could snap its fingers and do it, sure. But there's an understanding it's going to take time. And part of that is like we want to take the time, build it in a way and recognize that because there's performance critical pieces, it will need to be in Rust. Could could it have been in C? Sure. Um but it's in Rust. I think it would have likely been the same kind of challenge if it was just in C. So, you know, anyway, kind of interesting because that is I think businessdriven and there was this element of like the language choice. So, um that's that is another rewrite for a whole different set of reasons. Cool. And thanks Ryan. I will check that on reream. I do appreciate that. Um but folks, that's that's it for the stream. So, I hope that was helpful in some way. Um, you know, parting advice for all of you is not, um, hey, Nick says don't rewrite, so don't rewrite. The parting advice is like if the conversation's coming up for rewriting, like try to like I I would always say find incremental ways to do things. I I really stand by that for like most scenarios I can think of is like some way that's incremental will be will be beneficial because you get more feedback opportunities. So, that is that. I don't know. Do we want to go through stuff? Sure. I haven't I haven't tried to sell you guys anything in a while, so let's let's sell you. Uh, no, I got I got courses. I got courses. They're on Dome Train. Um, no, but seriously, all my courses are on domain. Um, if you don't know, uh, because you're not a .NET developer, Nick Chapsis is a, uh, popular YouTuber. Um, makes a lot of really goodn net content and he has domain, which is where there are, uh, industry professionals that come together and make courses. And so I do have courses on domera. I think my courses are part of um, I think they're part of doain pro, but I do have the getting started course. I have a deep dive uh course that kind of follows up to that. And then I actually have some there's a couple other C# courses, but I have some that are there's my getting started one. I have some that are uh actually on soft skills and things like that. So, there we go. So, yeah, it's available on Pro. So, I do recommend if you're trying to learn C, want to check that out. I'm proud of it. Um, this is the kind of content that you would see on my closer to the type of content you see on my main YouTube channel, which is like C# tutorials and things like that. So, um, we will do a quick peek at that, too. Give me one sec. I want to refresh the channel on this other tab and we'll bring it over if my computer won't die. There we go. So, this is my main channel, Dev Leader. Um, I got the thumbnails going where I'm making faces because how else do you make YouTube videos? But no, this channel is Dev Leader. It's primarily C development because uh not only is C objectively the best language has ever been created. It also happens to be my favorite. Um, I'm I'm kidding. But the idea behind this channel is a lot of C tutorials and more recently I've been trying to show usage of AI tools. Um, so if you don't know this, just I need to explain for a second. If you don't know this about YouTube, you've probably picked up on it. YouTube thumbnails are the most important part of a video. Not because anyone wants them to be. Like, I don't give a crap about my titles and YouTube thumbnails. They're the two most important pieces of a video because those are the two things that you see right away, right? you see my dumb face and you're like, "What is this guy freaking out about?" I'm going to pause for a moment. There's an arrow. What's the arrow pointing to? Right? And then hopefully it gets you to click. So, unfortunately, I have to do stupid thumbnails. [laughter] Not what I like to do. I like making the videos. But anyway, um every time I see my dumb face on one of these thumbnails, I'm like, man, why is why does YouTube got to be like that? And it's because that's what people click. So this channel um yeah there's lots of beginner advice and more recently there's a lot more AI tooling and such. Um maybe the other thing I will briefly talk about is I I'll mention code commute. I should talk about code commute. When was this refresh? Give me one sec. Bring this over from the other tab. This is my channel where if you have questions you can submit them to me. You can either do it on um on the YouTube videos themselves, leave a comment, or you can go to codemute.com, you can write in totally anonymously. Um the email that I get says it's from me, so I don't know um who you are, but if you send in anonymously, please leave uh extra context so I can I can help you out effectively. But these are all vlog entries. I try my best to answer your questions. And I personally really enjoy this kind of content because it's uh it's kind of like what I live and breathe in my actual day-to-day life. So, um yeah, it's uh it's very enjoyable for me. So, always happy to try and answer. I do have a couple other YouTube channels. If you're watching the stream right now, you're on the Dev Leader podcast. That's where I interview other software engineers and live stream. And there's also Dev Leader Path to Tech. I have a couple more ré videos to post, but I think I've caught up on ré reviews. And then I will briefly share what I work on which is brand ghost. And brand ghost is the social media. Oh, we got cookies. I will accept all of them. Um it's a social media cross-osting and scheduling platform. So if you interact with me on social media, everything that I post is through Brando. It is uh stuff you'll see in some of my YouTube videos because I will use Brando codebase for different things. Uh I was sharing this dependency injection scanning uh library that I've been building getting a lot of help from co-pilot recently. It's something that brand ghost uses. Um so I do use it and sort of build in public with it even though sometimes people don't even realize but it's a car backend. It's a ASP.NET Core. A lot of fun but this is what I build outside of work. This is my thing and so I like to bring it up in case you're interested. I've had some people that have said, "Hey, I want to try out content creation. Like, how do I do that?" Um, I'm all I and I mean this genuinely if you're like, "Hey, I want to try and like where do I start?" Um, just send me a message. I'm happy to chat with you about it. And Brand Ghost is free to use. So, um, we have a paid, um, like paid tier and everything, but you can use it for free. So, if you just want to get started and you're like, I don't know what I'm doing, send me a message. Happy to try. Um, and I think the other thing that I'll mention, too, is that um, see, even Ryan saying he's got to use brand goes, right? [laughter] But yeah, I I do recommend like, uh, Ryan saying, uh, as I want to start writing more out there. like if you want to get ideas out there, if you want to learn in public, I realize this live stream has obviously, you know, more software developers. The the only re and I'm I'm not let me just go back to my face here for a sec. I'm not um I'm not making this up, right? The only reason that any of us are sitting here, you know, together on this stream is because of learning in public. And so I started Dev Leader, which is what you're watching. um started that in 2013 when I was in my manager position and I was like I don't know what I'm doing and I need to start taking this more seriously. How do I learn like how how do I learn what to do? So I tried consuming things and I was like I should I should try documenting what I'm doing and write this and like I'll make a blog and it's called dev leader because I was a developer going into my leadership position for the first time. That's where it comes from. And so I used it to learn in public but I was misguided I think because once I started doing it I was like oh like no one's I don't have enough people reading my blog or this is hard and I just gave up. Right? It's it's a lot of work to put content out there. I'm not going to lie to you about that. So, I took 10 years off, right? I took 10 years off. And when I got back into it, I said the only reason I gave up is that I couldn't sustain the posting. I like making content. I like being able to help if I can and share ideas. So, I started building Brand Ghost. and it didn't turn into Brand Ghost until a little while in, but it's what I was using the entire time to post my content. So, Brand Ghost is now something that you can use if you're interested. I'll put the link in the chat. I would also remind you too that if you have if you or someone you know has like a small business and they need help with social media, right? They're like, "Yeah, got a business, but like, man, I don't want I don't have time for posting stuff on Instagram and LinkedIn and all that." Brand ghost can be an awesome solution because once you get started with it, we can help you repurpose your content and then it's not like, oh crap, I don't have a post for this week. Spoiler alert, I like recycle tons of content posts. You will learn that you don't have your whole audience seeing all of your content. So, a lot of it gets recycled, but I can focus on the important parts. I can focus on continuing to build brands. I can focus on making more content, making better content. I don't have to worry about rushing to go schedule content everywhere. So, hope that helps. Uh, if you're interested in Brand Ghost, you have any questions, again, reach out to me. Happy to try and help. If you're uh trying to get onboarded to it and you need more assistance, especially if I have a bunch of content, reach out. I'm happy to help. And folks, I think that's it. So, thank you so much for being here. um refactoring, rewriting, this kind of stuff is something that I uh am really into. I like having the conversations about it. So, if you have more questions, just reach out and happy to chat. So, I hope to see you all next week, same time, same place. And have an awesome week. Take care.