We originally sat down to discuss distractions and Yak Shaving. What emerged was more like group therapy for a team struggling to cope with a spate of JS dependency upgrades. We also discuss purchasing an ice cream truck. Buckle up!
Starr: So, I learned something amazing. Just before coming on here I learned something amazing. Okay, Beto O'Rourke, the presidential candidate, used to be a member of the Cult of the Dead Cow, hacking group. In, yeah the 90's.
Starr: I know!
Announcer: Three developers. One mission. Build a business to nurture personal fulfillment. It's not stupid, it's Founder Quest.
Ben: It might have to go look for his byline, what the frack?
Starr: I know, I know, right? I used to read their reports from Def Con and all the conferences and stuff. I used to be like, man these guys are so cool, they're so much more mature than I am. I don't know how they got all the money and go to Las Vegas and do things when I'm 17 and have no job.
Josh: That's kinda how you feel about the guy who's running for president now probably.
Starr: Yeah, probably.
Josh: So, I guess not much has changed.
Starr: Oh, speaking of Yaks and blockers and all this stuff, we finally have our pod cast artwork as you saw.
Starr: So we can now actually... This is episode number 6 of Founder Quest.
Josh: Is it? Wow.
Starr: And, yeah nobody's heard it, but me. Really.
Josh: I kinda like it like this, there's no pressure.
Starr: Yeah. Should we just keep saving them to drop box.
Josh: And that's it? I mean like... yeah that's cool with me.
Starr: That's fine they can release them after we're like dead and famous.
Josh: Right, yeah.
Starr: It's like I didn't want to set up the web site because I don't know what colors the art work has in it and you have to have ... you know, you want to have them matched colors and stuff so.
Josh: Yeah, but know we can get the first one out?
Starr: Yeah, now we can start rolling em out. See what people think of em. In slack we've been talking all morning yesterday about all these blockers we have right, because when you're doing development on any sort of bigger project, you have this idea of the real work you want get to, like the feature work, and then you have the things that are preventing you from doing the real work. Sometimes you call that yak shaving because in order to, you want a sweater, but you know you need yarn to make the sweater, then you need wool to make the yarn and you eventually end up shaving a yak. I think that's what I
Starr: Yeah that sounds about right. Is this a false distinction you guys, you think there is a such thing as the real work?
Josh: You mean like does the real work exist, or is it all just yak shaving.
Starr: Yeah, does the real work exist?
Josh: I think you could make a case that it is yak shaving to an extent like anything you would do, would be blocking something else at least.
Starr: The reason I ask is I had this bit of an epiphany when I was struggling through some random webpacked stuff where I was like man what if this is all there really is, like what if this is it guys?
Josh: Kind of like an existential crisis.
Starr: Yeah, kind of, kind of. And it was fine like I was having a good time you know, just doing my webpack updates and everything, but this idea that we have some sort of mythical real work to do.
Josh: Well web development has become, feels like to me its become a lot more complex over the years, like I don't know, that could be an illusion too you know, computers have always been hard. But it feels like the amount of things that you have to do just to do web development in the first place, has increased. I don't know, what you, how you guys feel but that's how it feels to me.
Ben: Yeah, I can definitely agree with that, I mean it's not as simple as just drawing some HTML up on the webs you now, and having people see it, right?
Ben: So, yeah I think when you're building on anything, right, you have to deal with all the things you're building on top of.
Josh: Kind of like when we used to write HTML and then we had to write some PHP in our HTML.
Josh: Yeah, I'm working on our Honeybadger.js or our Honeybadgerjs library for a big 1.0 release finally we've been pre 1.0 all this time, but-
Starr: Oh we're still not up to 1.0 yet.
Josh: No, I'm a big fan of semantic versioning and you don't really have to do it if you're not to 1.0 yet, so, you know that's a good way around it.
Josh: Yeah, the thing I'm working on now is, I've been trying to, I've done a bunch of features, like a feature work on the library, but it always seems to come back to when I have to work on our build tooling, or our CI continuous integration, is where I seem to spend the majority of my time especially since I don't develop this package all the time so I'll let it sit for a while then come back to it and do a bunch of work on it so usually by the time I get back to it, things have kind of moved on in a lot of ways and there tends to be things that I need to kind of troubleshoot to bring up to modem standards again.
Josh: Yeah, and there's a lot fewer of them typically.
Starr: I wonder how big our node module directory is?
Ben: I have back in the dark days where rails three, when you would have to update gems, I remember a number of times where I was like, okay just bundle update, and update everything at once and it was a mess.
Ben: And that's just a mess.
Starr: One thing I'm finding is that because, we use, dependencies, that are from this sort of older time we're actually having some of them becoming sort of, abandon wear, and this is a bigger problem for us right now because I recently needed to upgrade jQuery to the latest major version, but we use jQuery Pjax which is a plug in, to give us this single page like, Turbolinks style behavior on our front end, and it just doesn't work with the new jQuery because it's abandoned, pretty much. So now, in order to update jQuery we have to migrate to turbo links, or some other more modern way of doing things, so it's just a backasswards way of working that's just incredibly frustrating at times because you just want to freakin build features-
Starr: And ship them, but yeah.
Josh: Well I remember back when Pjax was the hotness, that was well before turbo links, and I think it was, was it, it was GitHub that initially...
Starr: It was GitHub, yeah.
Josh: And initially, kind of started that whole way of doing, making kind of normal traditional web apps faster, with the Pjax and that's basically what got picked up and rolled into turbolinks.
Josh: Yeah, I recently threw turbolinks onto my blog. You know it was already fast because it was basically just like HTML pages, but it created a noticeable improvement in the page load times, and all that, so, that was kind of a cool little thing. It's like three lines of code you just throw it in the page and its done. So, my blog is now a singe page app.
Starr: That's.... awesome?
Josh: Well I mean it seems to be kind of the thing to do these days.
Starr: It is.
Josh: I know a lot of people who are converting their blogs to react and that sort of stuff, so I figured I'd have to you know, give it a try.
Starr: I published my personal blog on a xerox machine, so...
Josh: It's kind of similar to Rake and Ruby, or Make even, but it has a bunch of packages, or plugins that have been developed for it, and I've been running into the same thing, where because Grunt is not the new hot build system anymore, there's a bunch of other ones like Gulp, and I'm sure like five others that are even more popular than that now, I keep running into packages that I want to use, but the last commit on them was like 2016, or I'm running across GitHub issues when I'm trying to figure out how, why somethings not working, and I check the date and its like 2013.
Starr: Those are the worst.
Josh: Yeah, so it's like do I use this stuff, because some of it actually works but its, unsupported obviously, but the only other alternative is set up a new build system, and re-do everything, and that in itself is a massive yak to shave, so I'm making yak trade offs. Like which yak do I want to shave, which one is bigger.
Starr: So they would say open source isn't free, and I guess this is one of the costs of open source.
Ben: Yeah I guess the alternative would being that you're stuck with whatever your vendor tries to put on you right? And you know if things are dead they're like, you know tough, buy the new version.
Josh: Yeah, that's true.
Ben: But, I guess, a lot of web developers, don't remember the bad old days of building for a platform like windows, right? Where you only have one choice and that's whatever the vendor decides to give you.
Ben: To give you. Like now, we have all this choice, and all these ways to be able to implement whatever we want, and so, I guess that's the cost, like Starr was saying, that's the cost of open source.
Starr: These problems we have are problems that more established products have, like we didn't have these problems when we were starting out because we didn't have this much code, we didn't have as much infrastructure, anything like that because we just built it all it was all relatively new, so I don't know I think we should maybe just ditch this one, start something new.
Josh: That sounds like a good solution.
Ben: Well you know one thing that's nice about dependabot, the thing I really enjoyed about that, is that it keeps you aware of the dependency changes, so you don't get so behind.
Ben: I think the real pain of abandonware is when you rely on something that hasn't been updated in three years, but you know if you notice, things are moving on, and you're only behind like three months, well that's not as quite as a painful update.
Starr: That's true.
Ben: And yeah, that's what I really like about dependabot, its like you should, I guess, you have to combine that with the discipline to actually take some time to go and manage those updates, like even if it's a simple ruby gem update, right, you have to take a look at the commits and maybe the maybe the change log and see what's changed, and will this break my app if I add this dependency, and that takes time.
Ben: Right, so I guess you just have to be disciplined about it to really save yourself the pain down the road.
Starr: The thing at this point, it might be a little bit of a stretch, but I think we could probably come close to keeping a junior hire busy simply upgrading dependencies, and doing tests to make sure that everything worked, and all that.
Josh: Yeah cross like all our repos, and everything.
Starr: Yeah, cross all the repos, I bet we could keep somebody busy.
Josh: I really like, what you said Ben, a lot of this what we're calling yak shaving here, is really managing, its managing technical debt, and not upgrading our, like pushing things off like upgrading, creates more debt down the road and so when we go and we actually need to get some work done on something and we realized oh, we haven't touched this place, or these dependencies in like a year or two we have to pay some interest before we can actually get to work, and so, I think yak shaving is kind of, you create more yaks with the more technical debt that you have, or you can also call it interest on your debt.
Starr: I'm not saying we shouldn't do all this stuff, but it's kind of like, you're on a treadmill almost, you're running just to stand still.
Josh: Yeah, well, some of these automated tools like dependabot are, I think are really going to help, and they already are helping us with that but as we integrate them more into our development flow, I think that I would expect them to help this problem a little bit because we're not going to get this far behind hopefully, and as long as we're a little bit more disciplined and these tools kind of help us, I think it'll hopefully create less work in the future and less technical debt to deal with.
Ben: On your note of "let's just build something new," I think that is part of the argument behind microservices, right? So if you have a new feature you wanna build, like that blog post you just wrote about the autocomplete.
Ben: And you implemented that completely outside of our main app so you could call that a microservice, if you want, but the dependencies there are much smaller, like the scope of the work is much smaller you're just focused on that one feature, and so, you don't have to worry about this dependency conflicting that dependency, and blah-da blah-da blah, and so yeah I think one of the arguments people have for going now the microservice route is we have all these small services that are all very self contained, and upgrading the dependencies on them is much easier piece by piece, but then of course you have to do that on 20 different apps rather than just one.
Starr: Yeah, that's interesting, its like there's, you're right though because you'd be doing more dependency upgrades, but there might be fewer dependencies per upgrade, so there's less chance of them clashing. Yeah, so, we talked briefly about turbolinks, and stuff, and one thing, this isn't really related to the subject, but it kind of is because I'm hoping that this new thing, this new technology will completely eliminate the need for me to ever have to set up webpacker again, or webpack again, and that is, I'm talking about phoenix live view, in case people don't know, phoenix live view is essentially going to be, turbolinks on steroids.
Starr: Yeah because phoenix has excellent support for websockets, and all that.
Josh: I think that's right, and the thing that really makes it possible is the websocket, support because it does everything over websocket, which is why you can, well it's one reason why you can take advantage of more like real time capabilities, because it's not making as many round trips to the server.
Starr: I mean it's not gonna work for things like necessarily mobile, it's not gonna work for things where you have to have offline access, but you know, I'm willing to never write a mobile app if it means that I can write things in pure elixir and have these beautiful interactive, fast applications.
Josh: Yeah, I don't know, it's the most rails-y thing I've seen, that is purely phoenix and elixir, personally, it's really cool. I could see rails doing this if ruby could support, if ruby was capable of it, but because elixir has those capabilities it's one of the few things that I look at and it's like, ruby really can't handle, it couldn't. I don't see it ever being able to handle that sort of thing, and it's totally unique way to build a web application.
Starr: I don't like it.
Starr: I don't want this future.
Starr: Yeah, as somebody who likes to, work in small teams, work by myself, and build products I really love solutions like that where if not just, so much of the process, and sort of technology that we have now is about sort, of being able to manage complexity and that's fine but you still have to manage it, I rather it just not be there.
Starr: No I don't think we could, like we couldn't build Facebook, like that's ridiculous.
Josh: So I'm wondering are we getting to the point where the tooling is like diverged, where some of the tooling is built for, managing us a massive level of complexity with a massive number of people, working on it at the same time, does a team like ours, really need to use the same tools that, Facebook needs to use for instance.
Starr: That's an excellent question. So, talking about blockers and yak shaving, I think guys, I think I'm about ready to give the mac dust off another shot.
Josh: Throwing in the towel, huh?
Starr: I don't know if I'm throwing in the towel, I love my Linux box for running docker, for doing development on, but pretty much everything that's not vim and a terminal, it's really starting to get on my nerves, and its not that you can't set it up to be nice, but it's like we talked about with all these dependencies, and managing that, you set it up to be nice, once and then over time it just slowly devolves and becomes less, and less, and things just gradually stop working, then you have to go in and figure out, well okay what changed about some new version of the thing to make this not work, and that's fine if that's my job, but I don't wanna have to do that with like, Spotify. I don't wanna do that to be able to put emojis in my tweets.
Starr: You know, that's just, ahh, I don't know.
Ben: Yeah that's where I was when I was using Linux on desktop after several years I was like you know what, when OS10 came out, and I saw the beauty that was the Mac UI on top of the Unix shell, I thought that was just awesome, I knew that was what I wanted to be and I decided, I had [inaudible] after that point, and had the same experiences, you know you always gotta worry about thins that are breaking, and at some point I decided, I wanna do work with my computer, rather than working on my computer.
Starr: Yeah, so I've got a suggestion just for all of us, lets just destroy our computers, and we'll buy an ice cream truck, and we'll go and sell ice cream to the little children, and we'll get to see the smiles on their beautiful faces as they, you know, eat their treats. So much nicer.
Josh: The way you described that, is, is beautiful.
Starr: I know.
Josh: I'm in, yeah, I'm in.
Starr: Alright, I think we have enough content so, should we, should we say goodbye?
Announcer: Founder Quest is a weekly podcast by the founders of Honeybadger. Zero instrumentation, 360 degree coverages of errors, outages, and service degradations for your web apps. If you have a web app, you need it. Available at Honeybadger.io. Want more from the founders? Go to Founderquestpodcast.com that's one word, you can access our huge back catalog, or sign up for our newsletter to get exclusive VIP content Founder Quest is available on iTunes, Spotify, and other purveyors of fine podcasts. We'll see ya next week.
What is FounderQuest?
Three developers building a software business on our own terms.