How Long Could Our Company Survive Without Us?

Show Notes
Links:
How to Build a Blog in 15 Minutes with Rails
Lindy Effect
Programming is a Pop Culture
Laugh Factory
Star Trek Next GenerationBigelow TeaWallace and Gromit & Wensleydale CheeseCOBOLAngular 1 vs. Angular 2 ThoughtWorks Technology Radar 
Full Transcript:
Starr:
All right. I guess we're going to be talking about tech churn today, and by that, I guess we mean the sort of turnover, right? Like you have an app, you build an app, and it's not just done. I remember when I was freelance or like people ... I know these clients who weren't in technology and they would just expect that you build this app and you hand it to them and it works. Sort of like a house or something. It's like you built the house and you expect the house to sort of stay standing up.

Starr:
But with software, it seems like you build the house and then you have to sort of keep a crew of carpenters on hand to make sure it doesn't just fall down in a couple of weeks. Because dependencies are always changing. And I don't know. Standards are always changing, there's security issues, and stuff like that.

Starr:
So I guess this week we're going to be talking about that sort of stuff because at this point, it takes a fair amount of work keep Honeybadger ... I'm not talking about running, right. We can go away for a week and it's going to stay up. But if we went away for a year, we would come back and things ... I don't know. I feel like we couldn't just do that. Does that feel like a fair assessment?

Josh:
I think it's partially fair. There's some parts of our system that operate ... I mean that haven't changed for a long time. And there's some that are constantly changing or trends we have to keep up with. 

Ben:
I think we couldn't go away for a year on the client libraries. Because every different language has its own schedule for releases. GO just had a release recently that changed error handling. And then on top of the languages, you have frameworks. React had some changes to their error handling recently. So that in particular I think we're affected by.

Ben:
But the core of Honeybadger, I think we could probably go away for ... I don't know. Two or three years before we had really have to change things. Because we picked a lot of boring technologies when we started. And those ... Like for example Postgres doesn't change a whole lot from year to year. I mean, yeah, it's good to upgrade to get new features that come down pipe, can you get better performance and bug fixes and things like that. But generally speaking, Postgres doesn't change a whole lot. And so you can stick with that for a few years.

Josh:
We host this meetup in town here in Vancouver, Washington called Vancouver Full Stack. And this last one, my brother, who's also named Ben, gave a talk on ... It was titled, I think, Building a Rails Blog 15 Years Later. And so it was kind doing the same thing that DHH did in the famous blog in 15 minutes video that got us all into Rails.

Starr:
Oh, yeah. That was like a huge deal back then because it was ... Nowadays, it's super common. It's like you done with some of your framework, you run some generator, and bam, you have some sort of working, basic web application like a blog. But back then, that was unheard of.

Josh:
Yeah, you basically either strung it together yourself out of a bunch of PHP or Perl or whatever files. Or you used WordPress or Typekit, maybe, as I recall. Was that the pro version?

Ben:
Oh, yeah.

Josh:
Yeah.

Josh:
So yeah, that was huge. Like being able to bootstrap your own relatively custom application.

Ben:
It was a movable type. That's what you're thinking about.

Josh:
Movable type, that's what it is.

Josh:
It was interesting, though, going through his talk, not a whole lot has changed in Rails as far as building a block in 15 minutes. I think the generators generate a little bit more code for you now. Actually, they're a little bit more explicit about ... So they put the code in your controller instead of just hiding it in the framework. But other than that, there was not a whole lot that has changed with Rails as far as the basics. Which I found really interesting because it's like how it's been 15 years. Because I think it was 2005 that that video came out, if I recall correctly.

Josh:
And of course, I mean, Rails has gotten a lot better since then. But also it has kind of just quietly done it's work for a lot of people, I think during that time. And they just had to upgrade it and ... You have to keep up on it. But compared to some of the other tech stacks that you could choose that aren't around anymore-

Ben:
The funny thing is that Rails itself, it's been around for long enough. But it's funny that you should say not much has changed. Because if you were around back for Rails 2 and upgraded to Rails 3, that was huge. And the upgrade from Rails 3 to Rails 4 was also nontrivial. And it hasn't been as bad like 5 to 6.

Ben:
But there some pretty big adjustments that happened in Rails. But yet, even still, the philosophy has changed not so much. The approach of building apps has barely changed. Like you said, it's a very similar of how it was back in the beginning. So I think that says a lot about the vision and the foresight that they had with baking in the original stuff in the framework.

Starr:
It's an interesting-

Josh:
Right, and I mean like-

Starr:
It's an interesting case. I just wanted to say it's an interesting case because with Rails, I have a feeling that ... How long ago was it? 15 years ago, you said?

Josh:
Mm-hmm (affirmative)

Starr:
Between 15 years ago and now, I imagine there's no code in the framework that is still there that was there 15 years ago. Or if it is, it's like a line containing a closing bracket or something. And yeah, from the standpoint of your brother trying to make the blog app, it seems very similar. And so I wonder ... It's almost as if you could say that Rails, the framework, the actually code of Rails, has had a huge amount of tech churn. But its certain aspects of like user interface have been made a bit more sort of stable.

Starr:
So in terms of a basic blog, and sort of functionality you need for that, the user interface that Rails presents in order to create this blog is pretty similar to what it was 15 years ago.

Josh:
Yeah, the user interface is pretty much the same. And a blog is the simplest Rails application you can build. That's why you chose that, I'm sure. As a straight example-

Starr:
Yeah, and I just want to be clear. By user interface, I'm stretching that a little bit. I'm meaning like all of the sort of public ... The things that a programmer would use in Rails to make the blog. So all-

Starr:
the methods that you call and the generators and ...

Josh:
Yeah, yeah.

Starr:
Yeah. And the fact that it's like they're still called controllers 15 years later.

Josh:
Yeah. Well, of course, I mean, Rails has obviously changed a lot over 15 years. And it does a lot more now than make a blog. Back then it was mainly like ... The feature set was a lot slimmer. It was building REST applications. It does a whole host of other things now with action cable and some of the real time stuff. And a lot of stuff has been added to it.

Josh:
But I think there's different kinds of churn in there, too. Because from a tech churn standpoint. Because yeah, obviously, you're going to have to upgrade ... There's going to be churn, the software that you use as it matures and as it goes through upgrade cycles and stuff, you're going to actually have to migrate things.

Josh:
But 15, 20 years, that's a long time. If you chose something that was not quite as stable even from like a foundational standpoint, you might be moving between different frameworks within that time to stay relevant or to keep up with the pace of change. So I think from that standpoint, Rails still holds up as far as being potentially a little bit lower maintenance.

Ben:
So did your brother get his blog made in 15 minutes?

Josh:
It wasn't 15 minutes. It was a little bit longer than 15 minutes but he got it made. Also he got to-

Starr:
He didn't make the framework, so he's not going to be as fast at it as a DHH would be.

Josh:
Well, and there was a live audience so we had some banter. I made up a lot of snarky jokes about Rails and JavaScript. So I introduced the talk as Ben Builds a Blog and React on Rails.

Starr:
That's a weird open mic night at the Laugh Factory, I've got to say. That's a weird standup routine.

Josh:
Because that's what ROR stands for, you know, these days.

Ben:
React on Rails.

Josh:
Yeah.

Josh:
But yeah, but we did ... I don't think the original talk had ... I don't know if it was TDD, but it got around to actually running some tests for it, too. Which was cool so ... There were some new people there. I think they got a lot out of it.

Ben:
Okay, but did he use TextMate?

Josh:
No. He used VS Code.

Ben:
Because that's-

Josh:
He used VS Code on Linux.

Ben:
That was an interesting-

Josh:
While giving a live coding presentation.

Ben:
Well, that's brave, right there.

Josh:
Yeah.

Ben:
That was an interesting side effect from that DHH video. Like TextMate and the Mac, actually exploded, in terms of web developers using them. It was kind of surprising. Interesting experience.

Starr:
Yeah. Similarly like I was ... I have here ... Audio listeners cannot see this but I have my mug of Earl Gray tea. And I remember that I started drinking early gray tea when I was in high school because I really liked the Next Generation, like Star Trek, the Next Generation. And so I was like, I wonder how much value ... Or how much, I don't know, Bigelow, the tea company's stock went up when Next Generation came out. And suddenly all these nerds are ordering Earl Gray tea everywhere.

Ben:
Well, I heard that Wallace and Gromit say it's Wensleydale cheese.

Josh:
Really?

Ben:
Yeah. The story that I heard was like they were basically going to shut down, but all of a sudden Wallace and Gromit came along and everyone wanted Wensleydale cheese.

Starr:
Wait, did they eat that or something or ...

Ben:
Yes.

Starr:
I've never seen it. Is it a movie? Is it a TV show? I don't know.

Josh:
They're like a Claymation show. Yeah. It's a guy and his dog and they love their ... What? Their tea and cheese-

Ben:
Cheese and crackers, yeah.

Josh:
-and crackers, yeah.

Ben:
You got to check it out. It's great.

Starr:
Oh, maybe I should get some cheese and crackers for my tea.

Josh:
I'm surprised you haven't seen it Starr. I think you'd really like it.

Starr:
Yeah?

Josh:
Yeah.

Starr:
I'm just thinking of all the fun our listeners could have listening to me each crackers.

Ben:
And I had to recommend Wensleydale cheese. It's delicious.

Starr:
Oh wow. You just bumped their stock by another 10 points. Time for me to go-

Josh:
I think-

Starr:
-time to run this little pump and dump scheme.

Josh:
I think ... I have an alternate theory that Ben is the one who saved the cheese. Sounds like you're a pretty big fan.

Ben:
I am a big fan.

Starr:
One thing that you mentioned early on, Ben, is that the aspect of Honeybadger that experiences the most tech churn in terms of us having to update things, is the client libraries. Like the bits of the libraries. I was going to say the bits of code, the people inserting their apps, but they're a lot more than bits of code. They're actually libraries.

Starr:
And these things have to hook into go, and react and view, and all these stuff. All these frameworks to sort of seamlessly pull out error information. And these frameworks are changing all the time. And so we're constantly having to update them.

Starr:
So it's like do you guys think that it would be a bad business decision for us to just become a COBOL focused company? Like we throw in-

Josh:
Just embrace it.

Starr:
Yeah, we just put everything on COBOL.

Josh:
Embrace the stability.

Starr:
Embrace the stability, that's right.

Josh:
Yeah. Well, I mean Rails is kind of the newest. The webs COBOL is becoming itself ... I just give us another like 10 to 20 years and ... I mean, we're not going to change, right. We're going to be using the new Rails in 20 years, right?

Starr:
Oh, totally. I hope so. I mean, that'd be great.

Josh:
Yeah.

Ben:
I mean, we like to joke about COBOL, but there are still plenty of apps out there running in COBOL. And I think-

Starr:
That's what I'm saying. I'm not joking. This is a business opportunity, Ben.

Ben:
I'm just saying. Bit pick some, if you're a developer and you're looking at what am I going to build on? One of the things you should consider is what does my stack look like longterm? Am I going to be able to be around 15 years from now and still doing this thing. If you chose Rails, that was a risk in 2005. Not so much a risk today since it's been around 15 years.

Ben:
But if you chose Angular One, well, that didn't work out totally well.

Josh:
You've been through a few.

Ben:
Part of the real bugaboo about tech churn is that when you have to pick a technology to build on, you have to try and predict the future. And no one's very good at that, right. So I don't think there's a solution out there except for trying to in with eyes wide open. Or just pick something that's been around forever. So yeah, let's just switch everything COBOL. I'm down with Starr.

Starr:
All right, thank you. Thank you. I've got one other person on the COBOL train, leaving the station. Yeah, I think-

Ben:
The Fortran.

Starr:
Fortran, okay. Going way back.

Josh:
Leaving Fortran for COBOL. I mean from a ... Like it might actually work for us so-

Starr:
Fortran is dead. Fortran's dead. I'm doing everything in COBOL now.

Josh:
Fortran ... Nothing ever dies, Starr. There's someone still doing Fortran.

Ben:
Lots of someones.

Josh:
Yeah, you're right. It might work for us because I think one of the reasons companies tend to not stay on ... because there's not as many developers that are learning, training for that, right. So if we had to hire like 100 developers, COBOL will probably not be a good choice for us in a competitive developer market, I would imagine.

Starr:
That's true.

Josh:
Now being a small company that hires like once a year seems ... At kind of our current pace ... It's a little faster than that. A couple times. Maybe that works for us. Maybe we can stay on the old crusty stuff. And we can just find everyone who's interested in working on that.

Ben:
What I think is how you can choose what kind business you want to have based on what kind of choices you make.

Ben:
Like, for example, O'Reilly. They thrive on churn, right? The more new technology-

Starr:
Yeah, the book publisher.

Ben:
Exactly. They publish books about technology so-

Ben:
-new frameworks, new languages. Yeah, exactly. But yeah. Lets have that, right?

Ben:
But someone like I don't know, a hospital. They're like, no, lets just stick with the old stuff for a long, long, long time. And we'll just train people if we can't find them to hire them.

Starr:
I mean, lets be honest, churn has a whole different connotation when it comes to a hospital. You want very low churn at your hospital.

Josh:
Full disclosure, when we first started this conversation, I completely thought we were talking about business churns, so ... yeah.

Starr:
I like to keep you on your toes, Josh.

Josh:
To clarify my statement about how ... I think choosing technology like potentially things like Rails, could potentially lead to lower tech churn. We're not talking about technical debt, to be clear. That's a slightly different topic, I feel like. 

Josh:
So churn is not necessarily the same thing as debt. Because you filled out that tech and different systems definitely have different properties as far as how that debt is managed over time.

Ben:
Both do have that issue with dependencies, right? The dependencies you choose and especially if you have more dependencies, you're going to have more churn to deal with. Because they're all on their own schedules on how they release stuff. Back to what I was saying, pick your dependencies carefully, right.

Josh:
Here's a random thought. Maybe this has something ... It has a lot to do ... Like technology and the amount of churn that it experiences could have a lot to do with the platforms that it's built on.

Josh:
So for instance, like server-side technologies. We've had TCP/IP and HTTP and all the base technologies. They change but they've been around a really long time. And server frameworks, in my experience, they don't change quite as rapidly as, for instance, like a client site applications because browsers have gone through a lot of upheaval. System IDs and continue to today. Browsers are constantly changing little things that affect the developers that build on those platforms everyday.

Josh:
I feel like it's a little bit more on the browser side but not the server side.

Starr:
Yeah.

Josh:
Do you think that's a fair statement?

Starr:
That is an interesting aspect to this. Because I almost wonder, like in Rails and stuff, there was a ton of churn, you did have to ... There were tons of things changing around 2006, 2007, and onward. But early ... It's like there's this flurry of everybody rushing to try and figure out how to do things and to build a system that will sort of catch on. And then eventually there are parts that gets to be accepted and then things slow down.

Starr:
And it's not to say there's never churn. It's like yeah, sure, you've got to upgrade your gems and stuff like that for security patches and whatnot. But the amount of turnover in code and stuff that happens in Rails land nowadays is much, much, much less than happens in like JavaScript land.

Starr:
I'm not sure that that's anything innate having to do with Rails versus JavaScript except that there's just a lot more people building single-page, front-end heavy web applications these days.

Starr:
And so we're sort of in this process of that sort of getting thrashed out. Because right now, it's a lot better than it used to be, right? Because five years ago, everybody was using ... there were 20 different package managers for JavaScript and nobody knew who was going to reign supreme. But now, it's like, well, there's still a lot of them, but ... Webpack seems to be kind of the big kid on the block now. And I don't know.

Starr:
So yeah. So maybe we're just seeing this weird sort of feeding frenzy. And so the trick to minimizing tech churn is to avoid the feeding frenzy. Like hang out in the sort of shallow type pools.

Josh:
Yeah. Yeah, ThoughtWorks is the consulting ... Is that Martin Fowler's consulting company? I want to say.

Starr:
Yeah.

Josh:
They have this thing called the technology radar. It's a report that they publish, I think it's twice a year. But I was looking at it recently, it's kind of interesting because what it is is they get all of their senior technologists at the company together in a room with a whiteboard for I don't know, a day or two or something. And they all hash out all the technologies that they've been using, they're excited about, they've seen recently.

Josh:
And then they put together this ... Basically it's like a radar map of all these technologies with different quadrants in terms of whether they would like one to ... Like they think they're ready to adopt, whether they're just kind of observing them, whether they think that they're not a good idea and they would actively avoid them.

Josh:
The interesting part about it, in terms of this discussion, is like seems they have a process where like actually figuring out when it's actually time to start embracing something. And I feel that probably has ... Like that plays into it. Is this thing ... Is it widely adopted enough to be here for the longterm? Versus is it one of these technologies that is kind of just still ... It's one of the predecessors to the ultimate one. Or it's a flop.

Ben:
Yeah, one of the concepts that I like that's related to this is called the Lindy effect. And that's the idea that something that has been around for a long time will likely be around for a long time. So the longer something sticks around, the longer it will be around, right. So ...

Josh:
Hey, good news for the Badger.

Ben:
Exactly, like yes, we are much more likely to be around a couple years from now than someone who starts the same service a month ago, right?

Josh:
Mm-hmm (affirmative)

Ben:
By the order of this effect.

Ben:
So I think one strategy that you could take is just like, okay, I'm not going to look at anything until it's been around for a year. I am not even going to touch something that's brand new. But you lose that first mover advantage that can come with picking the technology that does stick around early in the life cycle.

Ben:
But if you're a risk averse, there's nothing wrong with hanging back and using the tried and true until someone else stubs their toe on it.

Josh:
You could still go play with it and stuff and learn about it. Just you don't need to go all in in production with it.

Ben:
Right. Okay, good thing about tech churn is that it keeps us all employed as software developers.

Starr:
That's true.

Ben:
Like Starr was saying, you can't just build the house and it stays standing, right? You got to have those carpenters on hand to always be wielding those hammers. So as a carpenter myself, I really appreciate that aspect of tech churn. Are we-

Starr:
So one thing that sort of is coming to mind continually as we're having this conversation is there was this great essay written a while ago by ... I may mess up his name, Reginald Braithwaite? 

Starr:
Anyway, it's called Programming is a Pop Culture. And the reason I was thinking about this essay is because I was wondering, as we're discussing this stuff, could we just be discussing shoulder pads? Or skirt length? It's like okay, we could be ... If you want to be safe and sure that nobody's going to give you weird looks or anything, it's like yeah, you can wear the sort of fashion that's been around for a while. But if you want to be cool and have everybody want to be on board with what you're doing and stuff well you got to pick these hot, new things.

Starr:
So basically, in this essay, he's talking about how so much of the stuff that we, as developers, argue about is essentially sort of trends, in another word, fashion. But at the same time, there's this weird thing where developers being in general sort of factually oriented and used to dealing with mechanisms of things and stuff. It's like we like to argue as if we're talking about things being objectively better. But-

Josh:
We like to turn things into science.

Starr:
Yeah. It's like oh, everything is ... It's obviously, objectively better that you build a React app than you build a Rails app. Like those two things are ... Like it's the next step in evolution. But in fact, we're just talking about sort of trends.

Josh:
Makes sense.

Josh:
Yeah, I thought it was interesting at that talk about the Rails blog 15 years later. I mean, there seemed to be people there that had obviously not ever seen that talk much less kept up with Rails over the years. And they were interested in, really? Doing all of this and you get a blog? They were impressed by it. I'm like, this has been around for a long time.

Ben:
Are you saying they were impressed by how little work they had to do?

Josh:
Yes. Because I mean, if you went through some of the more modern curriculum ... I mean, a lot of code schools, they do teach Rails or another backend framework or whatever. A lot of them do focus on the front end or on the newer technologies. And a lot these technologies, they weren't built for the solo developer with the idea that you're going to be able to do an entire application yourself.

Josh:
And so a lot of these technologies like React, for instance, built by Facebook for massive software teams. And the idea is that it's one part of the system. And it's up to you to go and pick all the other components that you're going to use to piece together the ultimate thing, which is probably going to be amazing if you know what you're doing.

Josh:
But if you're a newcomer, I can see how challenging that would seem to think, I'm going to start from scratch and build a complete application. Say, I wanted to start my own software as a service as a new developer. And I just learned all the latest things. I could see that being kind of daunting.

Starr:
Do you think that, in some ways, the situation we're in now sort of mirrors the situation we were in sort of around 2002-ish. Back then, it's like you went to whatever the equivalent of a code school was. I guess university or whatever. And you got out and you're basically going to be going into whatever the equivalent of Facebook back then was. I don't know like IBM and you're going to be programming Java. And you're going to be part of a big team and you're going to work on some little aspect of this Java code base and you're not going to be building things just completely by yourself.

Starr:
But then Rails comes along and everybody's like, "Oh my God, I can build a blog by myself in 15 minutes. I don't have to have a team of 20 people." And so now people get out of code school, they go to Facebook, they work with a team of 20 people on some tiny little feature.

Starr:
And so this message of being able to build stuff just by yourself is actually cool. Although I guess it's not as bad as it was in Java times.

Josh:
Yeah. Well, it seems like this is not something new. Like you said, the whole Java, people aren't typically going out and building their own companies off of Java single-handedly, probably.

Starr:
Yeah. Let's be clear, I have no illusions that we're not still in Java times. There's still a lot of Java-

Josh:
Yeah, that's where we're saying that too. You're like, yeah. A lot of this hasn't really changed, it's just Rails has come along and other technologies like it have come along, I think maybe in a response to that. These technologies are geared towards slightly different audiences. They're geared towards smaller, potentially audiences that have more limited resources or they want to build something themselves or be able to do it start to finish.

Josh:
One of the reason a lot of people will still ... Even today, people will say like, "Well, Rails is good. It's really good for prototyping." Or for doing the rapid prototyping thing because you can accomplish so much with it in such little time.

Josh:
And then they'll say, "Where it falls down is as you grow and you have more people working on it and you have more of this churn happening on your application, that's where really it tends to shine less." I think the benefits of starting with something that's like Rails is that you can accomplish more with your resources.

Starr:
You know what this reminds me of? People want to build applications as if they're going to be scaling to millions of users simultaneous. I've also fallen into that trap.

Starr:
This reminds of that Mark Twain quote. It's like ... I forget exactly what it is. But it's about, it's like, "There's no poor people in America. We're just temporarily embarrassed millionaires." Yeah, so it's like, don't worry, I'm going to have a lot of money. So I need to plan for a life as if I was going to have a lot of money.

Josh:
Right.

Josh:
And I guess make life a lot harder on yourself now so that you can make sure you're set up for that billionaire life?

Starr:
Yeah, yeah. Exactly.

Starr:
And there's one lesson I've learned I guess fairly recently. Which is that immediate gratification is kind of under-rated.

Josh:
Yeah.

Starr:
Because like-

Josh:
There's no billionaires that didn't make their first dollar.

Starr:
Oh, there you go.

Josh:
Right.

Starr:
There you go.

Josh:
So if you're hung up on what technology to choose and you're not considering something like Rails or Laravel or whatever it is that won't scale ... That's not embraced by Silicon Valley or whatever, how many people have those aspirations but never get to the first line of code or the first customer or whatever.

Starr:
You got to tell me, honestly, did you make that up?

Josh:
Yeah. Well, as far as I know. I might have heard it somewhere.

Starr:
Oh my gosh. You're just like ... You got that. You got F That Money. Like you're just a machine! You're coming up with all these amazing phrases.

Josh:
What can I say. I don't know. I do hear things and then ... You never know. You can never be sure where you incorporate things from. But that's my knowledge. I'm not quoting stuff.

Starr:
Well, you know what? We're publishing this podcast and that counts. So anything you say here automatically-

Josh:
You heard it here.

Starr:
-copy-written so nobody else can use that. That's Josh's for his series of motivational books.

Josh:
I was pretty stoked about F That Money because I Googled it and I couldn't find it used in that context anywhere. So as far as I know, that was one of my original thoughts. Which are few and far between. So ... Maybe it wasn't the only one.

Starr:
Wow. It looks like we're coming up on time. Is there anything else you'd like to add to the conversation, anybody?

Ben:
Nope.

Josh:
No, I'm good.

Starr:
All right. Well, I guess that's all we have to say about tech churn. So, yeah. I guess we solved that one. You're welcome, everybody.

Starr:
So this has been Founder Quest. You've been listening to Founder Quest. If you would like to, I don't know, write for us on our blog, not Founder Quest blog, HoneyBadger blog, we herd people to do Ruby tutorials and stuff like that so check that out at ... Go to HoneyBadger.io and click on our blog and then there'll be a link right for us in the top nav. And you'll learn all about that. If you'd like to give us a review on iTunes or whatever. I always say iTunes. It's like Apple Podcast now. They rebranded it.

Josh:
Yeah, I did that, too.

Starr:
It's ridiculous.

Starr:
Just go and do that, please. Please don't feel like I have to ask you to do that. You are a free agent. You have autonomy and I want you to trust in yourself to make those decisions.

Starr:
And in the meantime, that has been Founder Quest. 

Episode source