Show Notes
This week on FounderQuest Josh, Starr, and Ben talk about the quandary of not knowing how to build something until after you’ve already built it. Therefore, once it's built it can be hard to fight the urge to tear it down and build it again taking into account all of lessons that were learned along the way.
The Badgers also imagine a rewrite of Honeybadger using the latest in 90s technology. Trigger warning for Perl developers!
Links:
Full Transcript:
Ben: Oh wow. That's so amazing. Cause I love like the Christmas specials from like Garfield and Peanuts, you know? And so I'm just thinking of a Honeybadger animated Christmas special. That would be so awesome.
Starr: Oh, that'd be fun, wouldn't it?
Josh: That would be the best Christmas special.
Ben: I don't know. The FounderQuest Christmas special might end up like the animated Star Trek series. Right? It might be a total bomb.
Josh: We're all in character, but it's like bad cosplay. What were the moral of the Honeybadger Christmas specialty? Would it be that it's not about the errors you fix, it's about the friends you make along the way?
Josh: Could be.
Ben: I like that. Yeah.
Starr: Okay. Well that's good. Speaking of cosplay, so I got a random package delivered to me to my name from Amazon and I order a lot of stuff from Amazon, so I assumed I just forgotten that I ordered something, so I checked and that's not it. And I opened it up and it's like, the name on the bag inside is like such and such cosplay and so, like, this is going in a very bad direction. I'm not sure I want to open this, but I think somebody had, like, one of, I don't know, one of our relatives or some family member had maybe sent a costume for my daughter or something and just, it's a time of year. The packages just randomly show up. And you're like, "Oh, I don't know who this is from, but it's got some kids' stuff in it."
Ben: We had that same package problem, that Amazon thing because we do a lot of Amazon ordering and so you know, packages around this time of year starts showing up and you're like, "Oh well I guess that was the present I shouldn't have opened. Sorry."
Starr: Yeah.
Josh: You opened the Amazon presents that aren't addressed to you, Ben?
Ben: No, not all the time, just every now and then.
Josh: Just on Christmas, true. One year?
Ben: Just on Christmas time.
Josh: Just on Christmas.
Starr: One year, we did Christmas in my in-laws and so we shipped everybody's packages there and we put their name on it cause it's where they live and everything. But I guess there was some miscommunication because my father-in-law was just starting to start opening everything and he assumed that it was all presents for him. He was, like, thanking us and it's like, "No, actually that's for my brother, that's not for you."
Josh: I could totally see that happening.
Ben: One of the benefits though of being in charge of the Honeybadger official post office box is that I get to also use that for my Christmas deliveries , so all my Amazon shopping shows up there. Yeah.
Josh: That's sneaky.
Ben: Yes.
Starr: Oh my goodness. So what are we talking about today?
Ben: Talking about a big rewrite.
Starr: The big rewrite. I guess we should explain what a big rewrite is, unless, like, programmers know this, right? There's this idea that you build something. You build a product, an application and like you don't really know how to build it until you've already built it. Right? Until then you're just kind of learning along the way, like, what the best approach is to take on things and so then, once you get it done, you actually know how to build it. There's always this really big temptation. It's like, "Oh, I just want to like build it for real now. I'm learning all the lessons," you know, taking into account all the lessons I already learned. And so, yeah, I mean that's my take on the big rig. Right. What does a big rewrite mean to you all?
Ben: Well, you know, that actually made me think of, you know, there's actually a development approach called, you know, you build one to throw it away where people, you know, in the early stages we'll build just a prototype, right? And we are with the intent that we're going to throw it away. But that's not the same as a big rewrite. I think the big rewrite happens when you know you've built this thing over time and it works and it's been working and it's making money but now you look back you're like, ah, I really wish we could redo that whole thing.
Josh: Yeah. You start noticing all the things that you could have done better or you could go back, you make decisions throughout the process of writing it that lock you into certain things or past decisions lock you into things now and pretty soon you find yourself basically architecting for this legacy system where, like, that happened to me this week when I was working on this feature. And I probably would have built it a different way if I could, if I was starting from scratch, but I had to basically bolt it on to what we already had, so the past decisions were influencing how I have to build stuff now, which makes you want to go and throw it all out.
Starr: That's an interesting take on it too, because yeah, you're right. Like, when you find yourself building something and sort of having to do it in a less than optimal manner because he has to sort of, you have to shoehorn it into an existing product. That can be be super frustrating.
Josh: Yeah.
Starr: Yeah.
Ben: Yeah. That's better than I think this sometimes is the cause of the big rewrite desire and that's, I just wanted to write it in a new programming language, right? I don't like that old English.
Josh: I'm just bored.
Ben: Yeah, I want to do something new. Yeah.
Starr: We are redoing everything in react though.
Josh: Even the back end?
Starr: Even the back end.
Josh: Yeah.
Starr: I don't know how we do that but even like Mozilla foundation is working on it right now.
Starr: Well yeah, and they just replaced all of the components, so actually kind of just to do that.
Starr: This was kind of a spur of the moment topic. I remember I logged on to chat and usually the way this works is that the morning we record the podcast, I go into chat and I'm like, "Hey everybody, let's think of what we want to do. Here's some ideas," and like, what topic we want to record about? But you know, I came in to chat today and it's like, it was already, there is this discussion going on, so that saved me some work. I'm really happy about that. But I assumed there was something that triggered this for you all like, so what's going on?
Josh: This is, this is something that Ben and I have been chatting about this week on and off as we've been trying to like solve this bug that came up as a result of some performance improvements we made a few months back to a system. It's to the our source maps processing system or we call it the source map service, which is basically it translates a minified, you bundle your JavaScript and stuff for production source maps. Translate that back into the original source information so that you know where the error happened in your stack trace, in your actual code, your original source code.
Starr: Yeah because otherwise otherwise the Honeybadger error would be like error in line one of your one-line file.
Josh: Yeah, line one column, like 100,000 or something. Yeah, so basically like we've made, so we had to make some performance improvements to the service to fix a performance issue and that introduced a new problem that we had to fix then, which we realized this week. And in the process of fixing it, it was a very simple thing, like, it should have been a very simple change. But just the complexity of the whole processing pipeline and everything and some of the legacy, you know, like I was talking about the legacy decisions we've made. That was definitely in play, like influencing how that was implemented and like it took a lot longer than it should have, basically ate my week.
Starr: Oh, I'm sorry to hear that.
Josh: Yeah, it's okay.
Ben: This was coincidentally, you know, at the same time that the Amazon web services Reinvent Conference was going on. And I always pay attention to that because there are typically new things that come out that we could use or that are just, you know, interesting, because I geek out on that sort of thing. And there were some new announcements that like, "Oh, we could, you know, do what we do this new way instead of that old way . We're using this new thing that just came out." Right? And so, and then, yeah, Josh and I are talking about-
Josh: I was like.
Ben: Oh, yeah.
Josh: It was the perfect storm because we're already frustrated with our past, develop ourselves, like shooting ourselves in the foot and stuff and then Amazon announces all this cool new stuff that we could use to put the world right again.
Ben: Yep.
Starr: I don't know. I don't know, I've got this little theory developing and you guys can tell me if it makes sense to you. When you first start developing a product, you go in with necessarily a very simplified idea of what it's going to work like, right? Because you don't really know, you don't really have a ton of experience in that domain and so you go in and you start with a very simple version and then over time, you learn all these little sort of edge cases and nuances and then you have to refine your application to, I take care of those. And I don't know about you all, but for me like over time I tend to like if I, if I'm not continually just focusing just on a single system, I forget about all those little edge cases and nuances and stuff.
Starr: My understanding of the system or my feeling about how it should work goes back to the original way, which is just like simple, it's got to be this simple thing. I have a feeling that if anybody is to go back and reopen that and be like, okay, well you know, I'm going to make it the simple thing. It's like you're just going to run and smack dab into all the complexity that you forgot about it.
Josh: Yeah. I've done this with things. Yeah, where I have to rebuild it for whatever reason even smaller components and then yeah, I find myself going through all the same things. It's like deja vu.
Starr: Yeah. It's like, "Oh, I should be able to, this is like, what is a hundred lines of code? I should really get this down to 10 easy." Then you go through and it's like, "Oh, I can't take that out. No. That actually does something. Oh huh."
Josh: Yeah. When I rebuilt the gem, I think that's what I'm recalling is like when I rebuilt the gem, I kind of started from the ground up thinking like, you know, it would be worthwhile to start from scratch and rethink things and I mean it was a, I think it had benefits too, but it definitely, like, you find yourself through the same, going through the motions, like running into the same common issues, then finding the less common ones later on as they come out.
Ben: It's kind of like when you have your second child. Yes. After having.
Josh: It's like, "Oh my gosh, I'm a pro at this now, I can just knock it out."
Ben: But you've forgotten all those things that happened with that first.
Josh: Oh my gosh. I've got a second child and I still have the first one.
Starr: Yeah. That's why I don't have a second child. That scares me. It scares me too much.
Josh: Yeah.
Starr: Also, yeah. My child is a freaking like hurricane as it is. I don't know if I could handle another hurricane.
Josh: Yeah, yeah. She does seem opinionated.
Starr: Oh my goodness, yes.
Josh: Yeah.
Ben: Yeah. When you do that big rewrite, you definitely run the risk of missing those corner cases and those little gotchas, you know, that were in the original system that were, have been covered and, and working well, right? I like that phrase. Someone said that legacy code just means code that actually makes you money right? It's out there. It's working. It's good. You know, and then when you build out this new code, now, you're introducing bugs that your forebears solved eons ago.
Josh: Yeah, well that's the, yeah, well that's like the thing with the pipeline specifically too in our system. That's the thing that like it doesn't change very often because it's, you know, we've built it, it's stable and it's, yeah. I mean, error tracking doesn't change a whole lot, like you're processing the data, so we might add features around what you can do with the data in the UI or something but yeah, the pipeline is pretty, it's like, we never have an issue with it really at this point, and so why would we risk setting ourselves back like six years back to when it was like, you know, we were constantly finding things and you know, patching it?
Starr: The thing you were saying, Ben, seems really interesting to me because legacy code is this pejorative term, right? It's like, Oh, I hate dealing with this stupid legacy code, but if it wasn't actually valuable and doing useful stuff, you could just throw it away and nobody would care, right? The fact that it exists and you have to like work around, it means it's actually useful.
Ben: Right. You have to honor that legacy code. You have to appreciate the joy that it has brought to the world, into life.
Josh: Right. And respect the lessons that it embodies.
Starr: I like this. We could get a whole, like a KonMari tidying up thing going on. It's like before you refactor a line of code, before you delete it, you have to thank it for the service it's given you.
Ben: Exactly.
Starr: I like this. I like where we're going with this.
Ben: Totally.
Ben: You know, but at some point you do realize, you know what, there is enough pain in my life with this legacy code that it's worth the pain of doing the rewrite. And that's a really tough call to make and a fraught with peril, but yeah, at some point, you might make it.
Josh: There's trade offs and or you know it might, it might also just not be the pain but is there a financial insight? Could rewriting it actually make, could it change things for your business or would it make it easier for us to go out and you know, scale to the next whatever, 10X size that we could or something like that? Like, that would be huge. I'm not saying that's the case, but you know, you never know.
Starr: You know since you mentioned the big rewrite is analogous to having a second child, like, I'm wondering if all this other stuff you're saying also applies to your children.
Ben: Oh dear.
Starr: It's like you're not doing it. You've got to help us scale, son.
Josh: We're going to go, yeah, we're going to go through this, this episode like minute by minute and pull out all the lessons that we can apply this to child rearing.
Starr: There you go. You're going to help us penetrate the enterprise market, little Timmy.
Ben: Yeah. I think in our case, the big rewrite that we've always envisioned is, you know, changing the policy lifeline, like, how it works and the idea being we want something that can scale bigger than we've ever scaled before and that can be more reliable than they've ever been before. And our current systems scales and been very reliable, you know, so we have these daydreams of, "Oh, it'd be nice if it could do X, Y and Z or it could scale this and that or intervention at all, you know? But the fact of the matter is that it does work really well, so it makes it really hard to justify doing a rewrite.
Josh: Yeah. I think for us for, I mean I don't know if we'd rewrite everything, at least initially anyway, but in the case of like the pipeline, the big reason that I would see that we might consider it would be if we're finding ourselves making more changes to it more frequently, like, say we want to support some kind of new processing feature, like, what was the Android thing you were talking about with some ...?
Ben: Yeah, the symbolication. Yeah.
Josh: Symbolication, yeah, which is like source maps.
Ben: Exactly. Yeah. So that could be, it could be a good, maybe that doesn't require a big rewrite. Maybe it does because it is kind of central to how we fingerprint things and group things or maybe that's something we could split out.
Josh: Yeah. It's just like if we ... Because there's different ways to build a system and like we've definitely tended towards like the monolithic approach and it's we're very small, we've always been very small and we've like really embraced that and done things. It's, you know, the rails way for the most part, but there's more, there's a stage we could build a more like step pipeline, you know, basically that allows you to bolt in new pieces into the middle easier. And that's what's really difficult in the current system.
Ben: Right.
Josh: If we had specific plans where we knew we were going to be doing a lot of development, like, investing a lot of new work in features that are going to be affecting that part of the system and that system is really resistant to change, we could justify it's going to save us a lot of development time in the long run to basically refactored in something that is more modular or something like that. Basically, it's just a refactor.
Starr: Yeah, doing that. It's always like there's always a specter of risk, right, because the dark cloud looming over the big rewrite. I just finished, I just finished the Lord of the rings trilogy reading it for the first time ever except for all that weird encyclopedia stuff at the back, I'm skipping that. But yeah, so I'm like imagining like Mount Doom and all this stuff. And so to me like the big rewrite, it looks a lot like Mount Doom and you're like trying to climb up at or whatever and I don't know. My metaphor really breaks down pretty quickly. Yeah.
Josh: Orcs are like rising out of the ground.
Starr: Yeah. Yeah. And what would the orcs be? Technical debt? I don't know.
Josh: Yeah, something like that. Errors, errors on it.
Starr: So, yeah. I mean, the bigger rewrite's scary because it can go terribly wrong, right?
Ben: Yeah. I had a big rewrite scenario several years ago where we were, it came down to, actually, this is a language thing. The system that we were replacing, that we wanted to replace was built with Perl back when CGIPM was still a valuable way to build web apps and PHP was on the rise.
Starr: So Perl is a programming. I'm sorry. That's me being catty. Probably most people know what Perl is. It's a programming language that people used to use a lot more than, yeah.
Ben: And it, you know, PHP started to eclipse Perl back in the early 2000s.
Josh: And Perl was my first programming language.
Ben: Yeah, me too.
Starr: Oh, really?
Ben: Wait, wait, wait. That was your first programming language?
Josh: Have I betrayed myself?
Starr: Poor thing.
Ben: I was thinking Perl's my first web language, but, wow, first programming language.
Josh: Well, I think, yeah, I did some, OS type stuff, I guess like Visual Basic or something like that.
Ben: Yeah.
Josh: Yeah. I don't really count those though, like, I don't know. I guess it was, yeah, I guess there were a few.
Starr: All right. The Honeybadger health plan does include therapy, Josh. You know, in case like, trauma lasts a long time, is all I'm saying.
Josh: Yeah. Well we can't all have started on COBOL.
Starr: Oh, Oh burn. Oh, who started on COBOL? Is that Ben?
Ben: No, I started on basic, but yeah, I'm pretty sure that that was a dig at me.
Starr: Yeah, I started at basic too.
Ben: Right. I can take it.
Josh: I'm just calling you guys old because you're like five years older than me.
Starr: Yeah. It's all right, millennial.
Starr: Totally cool. No, it's okay.
Josh: No, a Xennial, right?
Starr: Xennial, yeah. Oh, you're still Xennial?
Josh: A Xennial, like that ... I learned recently that there's a micro generation or something like that between gen X and millennial. And that is actually what I think we fall into, because you know how you always said like, you don't really feel quite gen X and I'm like barely millennial. Well it turns out there actually are people, I guess, felt that like more than us just felt that way and they came up with am actual generation for us.
Starr: I think I've heard about that. It's like something about like you basically, you grew up with the internet but you didn't have it your entire life.
Josh: You know what the it, it's called the, the Oregon trail generation is what Wikipedia said it.
Starr: Yes. I like that way better than Xennial.
Josh: That resonates. Yeah, so I definitely-
Starr: I'm an Oregon trail.
Josh: I definitely played at Oregon trail.
Starr: And you ended up in Oregon, so you won. You literally won Josh.
Josh: I really followed ...
Starr: Yeah, I ended up in Seattle, so somehow like I just veered off course a little bit.
Josh: Yeah. But none of us died of dysentery along the way, so that's winning.
Starr: I know because we're so good at hunting for food with those little pixels, the little pixel rifles that take about 10 seconds across the screens so you have to, like ,aim in front of the deer so that it, you know, runs into your ...
Josh: Right.
Starr: Your little pixel bullet.
Josh: I wish I could remember there's a, you'll have to go look this up later because I can't remember the name of it. There's a generation between the baby boomers and gen X and it's got a really funny name but I can't remember what it is but it's like the same thing. It's like ,the people in between people, so it's a lot of generations out there.
Starr: Completely off topic.
Josh: Totally tangent.
Starr: No, I mean I'm going to go even farther off topic but I'm just saying that you know, if you ever get a chance to go to the living computer museum in Seattle, they have all the old systems both from like throughout the entire history of computing. They have a huge room full of systems from the 80s and so you can go play Oregon trail on an Apple II. Yeah. You know, if you bring a juice box, I bet you can sort of surreptitiously sip it while you're doing that.
Josh: Nice.
Starr: What are we even talking about? Oh, a Perl, rewrites, scary stuff.
Ben: Anyway, yeah, where I was going with that.
Starr: Oh, you're telling a story about a terrible rewrite. Sorry.
Ben: I was telling a rocking chair story.
Josh: I'm sorry. I'm sorry, Ben. This all started with Perl.
Ben: I'm just rocking in my chair over here. It's all good. Yeah.
Starr: Wait for us kids to simmer down.
Ben: By the way, I totally identify with gen X. I did play a lot of Oregon trail, but I'm not going to claim the Oregon trail generation because I identify as gen X.
Starr: Yeah, I identify millennial. Ben, I'm sorry.
Ben: Yeah, it's okay., it's all right. It takes all kinds.
Josh: Okay. It's the generation or the social cohort of the latter half of the baby boomers and the first years of the gen X of generation X where it was called generation Jones.
Starr: Generation Jones.
Josh: Yeah.
Starr: Why? Jones Town?
Josh: You'll have to go read the Wikipedia page because I don't have, I don't remember enough to tell you off the top of my head.
Starr: Oh, it's too saucy to say on air?
Josh: Well, no, it's just, I don't remember things very well.
Ben: That'll be in the show notes so we can go there.
Announcer: Okay. Generation Jones.
Josh: Show notes.
Ben: So yeah, the story, I'll just skip the story and get to the punchline, which was like the one of the big risks of the big rewrite is that it just takes forever because you don't remember all those corner cases or all those bugs or you know, someone wants the new feature that you promised them while you're doing the big rewrite, so you have to fact that in. And so this one project that I had, which was just a mess, I just, I kept and like, the project manager kept coming to me and be like, "So you promise me this on this date and we're past that day." So now what? And so I give another date, right? And so we'd slip past that date too and finally I just said, "Look, I'm planting my flag in the quicksand here." And because really like every time I planted my flag, it just disappeared behind, you know, another deadline.
Josh: Yeah, there's a visual there. I just picture that.
Starr: Yeah, but it totally wasn't your fault that you were missing the deadlines because people, like, it was, you're dealing with the quicksand situations, like the situation was changing so much and you had.
Josh: Yeah.
Ben: I don't know cause I was the one giving the estimates, so ...
Starr: I'm trying to give you an out, Ben.
Ben: Well, thanks. But I'll take it. I'll own it. That's my role.
Starr: Okay. Going down with the ship.
Ben: I apologize to my coworkers that I did that too.
Starr: There we go.
Josh: Yeah, you got to be careful with wanting it so bad that you think you could you trick yourself into thinking that it's going to be, you know, easier than it really is. And there's definitely like some denial you can get into there where ...
Ben: Totally.
Starr: There we go.
Starr: I'll take the sting out by saying something dumb I did one time, which was one time at the height of Facebook games popularity, I took down a popular Facebook game for like two hours because they were like-
Josh: Was it Farmville?
Starr: No, it wasn't really that famous, but still, it had a lot of users.
Josh: Nice.
Starr: Yeah. What it was, if they had a really a really stupid, Oh God, maybe they're listening. They had a really, they were really stretching the limits of Postgres and how they had their database set up and they were like, "Oh Starr, go make this changes to the database." And I was like, okay, I'll write a little script to migrate it. And I wrote it and then it's like it takes time to update a big, big database, people, like, it's not instantaneous. And I was a little baby programmer. I hadn't really learned that lesson yet. And also the way they were doing it, made it so they took like about a thousand times longer than it should have. Like the way the database was set up, so yeah.
Starr: Anyway, that's the most hate I ever gotten from any sort of user base is because I took away their stupid little, like, magic game where they like, you know, cast spells on beans or something. Those people are vicious.
Josh: It's rough.
Starr: Yeah.
Josh: They were casting spells on you by the end of that outage.
Starr: Oh, no. That explains a lot. Yeah.
Ben: This is why I stay away from consumer apps. Fair. Business apps, when they're paying you, at least they have a reason they can be yelling at you, right? It's like, "Oh, that's fair. You can yell at me because you pay me.
Josh: Yeah.
Starr: And I never ran a database query again, so I learned my lesson.
Ben: To this day, never touched SQL ever again.
Starr: I have never run it. No, no. Not even for other people's apps, I don't use their databases.
Josh: But if, I mean, in that situation, again, if you're stretching the limits of what your technology can do to the point where you can't deploy a change without risking taking the system down.
Starr: Yeah. It might be time for a big rewrite.
Josh: Right.
Starr: We're going to, let's have a Jeff Foxworthy bit.
Ben: It might be time for rewrite if ...
Starr: Yeah.
Ben: Well, one thing I thought was really interesting, a few years ago, DHH from Basecamp, he had a presentation at Business and Software Conference where he talked about the big rewrite and talked about why they would do a big rewrite. And he gave his justification for Basecamp 2 and Basecamp 3, which is now the current version of Basecamp and basically said, I'm paraphrasing, that what they had wasn't what they wanted to present to the world as their best work. Like, they felt they could do better. Basecamp was out there and it was great, but then they kept having ideas on how it could be better and his ideas didn't fit well into the existing Basecamp and so Basecamp 2 was born.
Ben: And then same thing happened again with Basecamp 3. And they aren't exactly the same approach to the same problem, but they are the approach that they felt was the best at that time for the team they had and the lessons they had learned. And I liked that idea. That really resonated with me, like, you know, if the work that's out there right now isn't what you would consider your best work and you have ideas for what would be better then, that could be a good reason for a big rewrite. Now, in Basecamp's case, what they did instead of what a lot of people do, they throw away the old thing and replace it with a new thing. They didn't do that. They kept the old thing running with a commitment that, you know, we will "run it until the end of the internet", which I think is pretty cool.
Josh: Yeah. I really like that approach. That's really, really good. Yeah.
Starr: It seems pretty stand up. Yeah. Also, man, they would've gotten so much hate mail.
Josh: Seriously.
Starr: They just changed Basecamp, like, you don't have any option to keep it. They would have gotten so much hate from people.
Josh: Yeah.
Ben: Yeah.
Ben: But you know, the downside, the trade off there is they're now running three production systems, right? They have to maintain those things. Obviously, they're not adding new features to the old ones. They're doing that in the new one, but still they have to keep those servers going and keep the customer support people trained on, you know, this is version one way to do that versus, this is version two way to do that.
Josh: The customer support, yeah, being, but then again, like, I think some of the benefits of the legacy system being harder to change in the first place, but the change is where usually the problems are introduced. Also if you're, you know, if you don't have new people coming into the software, the support load is reduced. If you're not signing up new customers or your support comes from new people. There's not going to be as much support. It's going to be like the people that stay on that system longterm are going to be like the diehards that love Basecamp one or the people that just don't care enough to switch off. You know, it's good enough.
Josh: And in that case, they're probably not going to be the people that are bugging support a lot anyway. And then the system itself is if it's been around for 10 years or something, it's going to be stable and if you're not changing it, you're not rocking the boat at all, so maybe it's not as hard to run at that point. I could see the argument there. I can see, you know, if that was in our case like Honeybadger, if we did that with Honeybadger, like I could see it, it would, it's really stable now. Imagine if we never changed it.
Ben: Right. Yeah.
Josh: We could run that for a long time.
Ben: That's a good point.
Starr: I don't know. They could have big sort of retention, like employee retention for programmers sort of effects and I can imagine, it's like nothing makes developers happier than to be like, "Hey, let's do this like Greenfield project."
Josh: Yep. Totally.
Josh: Nothing makes me happier than that.
Ben: For real. Let's do it.
Starr: All right, so we're going to rewrite everything?
Ben: Yes.
Josh: We'll see.
Ben: V2 coming January, 2020.
Josh: It's back to our roots.
Starr: Yeah. They say the 90s are coming back, so yeah.
Ben: We can all moved to Portland.
Josh: Maybe Ben can write a couple of components in basic.
Starr: Only if I get to use some Turbo Pascal, that's my condition.
Josh: Yeah. You can use whatever you want, Starr.
Ben: Then they can have an interface that you'd Telnet into like an old BBS and you have to use, like your arrow keys to go through things, yeah, like an old ASCII or ANSI we have some, like, total art, you know, some ANSI art right in there.
Starr: My God, it's such a beautiful idea, Ben. I'm sad it's not going to happen now, but oh, that's such a beautiful idea.
Josh: We should definitely just open up a Telnet port and do something.
Ben: Totally.
Starr: Yeah.
Josh: Like an Easter egg.
Starr: Exactly.
Starr: We can have sort of like a FidoNet sort of implementation of Honeybadger where you have to, like, you get your errors like a week later because people have been forwarding them.
Ben: Oh yeah. You have to download them all into your offline reader and do it there.
Josh: Yeah.
Starr: Oh, that's a good idea.
Josh: Or you could just log in and you can talk to Honeybadger kind of like, what was the, it was like the one of the first AI bots that was the psychologist?
Starr: Eliza?
Josh: Eliza, yeah. You come and talk to Honeybadger if you're having a bad day.
Starr: That's a good idea. I mean, we could just have a support person on a phone and you could call in once a day and be like, "Hey, did I get any errors today?" And I'll be like, "No, honey, you're good." And go like, "All right, thanks. I can go skiing now."
Ben: That would be awesome.
Ben: I'm just thinking of like all these great landing pages we could do for April fools, right?
Josh: Yeah. We'll have to write these down.
Starr: Yep. Are we, have you said everything we're going to say about rewrites? It sounds like we're reaching a natural conclusion.
Ben: Yeah. I think you should totally do your big rewrite. Do it now.
Starr: Yes. Might I suggest that you're going to do a big rewrite, like, you've got to start it out with some sort of dramatic gesture, right? Maybe fire a gun, maybe look somebody dead in the eye and say like, "Let's do this." Maybe ...
Josh: Press release.
Ben: Yes. Make sure you set a firm deadline.
Josh: Make a dramatic statement of, yeah, what you intend to do and when it's going to be.
Starr: That's a great idea. Yeah. How about pay? No, here's a good idea. This is free consulting for you all. Pay a designer to come up with a video mock up of exactly what it's going to look like and then you know, prerelease that.
Josh: I love it.
Starr: Yeah.
Josh: Okay. Okay. Guys, I think what we're saying here is that you got to plant your flag in the quicksand.
Starr: Yeah. I think there's some Yolo in there too.
Ben: That's right. For sure.
Starr: All right. Well, it's been great talking with you all.
Ben: Likewise.
Starr: Oh, I've got to say, hey, if you're interested in writing technical articles for us about programming, check out our blog, there's a link in the top nav that tells you how to do that. Also, if you like this show, go to your podcast place and you know, give it a bunch of stars and that's it for FounderQuest, so see you guys later and talk to you soon.