Build, Buy, or Open Source?! The Software Engineering Challenge [360 Video]

Transcript is auto-generated and may contain errors.

What's up? We're headed to the office. It's Wednesday. Um, I'm going to go to YouTube for a comment or a question, I guess. Um, this question is from William Razer. It says, "When is it preferred to use a dependency to accomplish something versus write it yourself?" Um, this is a classic sort of question to answer. Um, the question that comes up, I guess. And, uh, I'm going to start by saying this is a dangerous one to dive into. Um, because I know already that I'm going to start talking about this. This is the kind of thing where I could list a hundred reasons to do something or to not do something, right? Give different perspectives. And if I miss one, if I miss one, someone's going to say, "Well, no. Everything you just said is wrong because you missed one." And like, I'm saying this because this is like the most common type of thing that happens when sharing things online.

Guaranteed I'm setting myself up for someone to say, "You forgot about whatever and therefore it's all wrong." Um, so full disclaimer, this won't be a conclusive list of every possible reason why. Uh, but I'll dive into it from a couple of angles. Uh, sort of two major ones that come up um depending on the context of the asker. And uh just a friendly reminder that if you want questions answered, leave them in the comments uh or send a message to dev leader on social media. It's my main YouTube channel and uh if you send them in um that way like to different social accounts, LinkedIn is Nick Cosantino um then I'll keep you anonymous so that way you don't have to worry you can write whatever you want. Okay. Um the two major framings that I want to talk about here uh because they're very different.

Um one is if you are building like hobby projects. Okay? Okay. So, you're developing on your own versus for a business because these will be uh maybe similar things to consider but um how you weigh out your options I think is really going to be uh what makes a difference here. Um so uh just for a little bit of framing when we go through this this is like this is typical just like analysis that we have to do right when we talk about software engineering everyone's always like oh it's code code code code code code code code and then you'll see people like me put out videos and content where it's like no it's people skills people skills people skills too uh not just code but then there's also this part like in my opinion the engineering part is all the analysis pros and cons and weighing out options.

Um this is where the engineering really comes out. So when we're let's start with um personal projects and stuff and then we'll get into like uh from a business perspective. So for personal projects um I I always encourage people to think about like when you're building a personal project, what is your goal of the project? Because again this is going to affect how you weigh out your options here. If your goal is to learn things, let's start with this, okay? If your goal is to learn things, then I would say um we're whatever you're trying to learn about, try not to go get off-the-shelf things. So, try not to pull in dependencies. Now, this will seem counterintuitive or maybe opposite from some of the other things we'll be discussing here, but if you're trying to learn about something, uh, I think there is a ton of value in trying to build it yourself.

Um, but that's because the goal is to learn. Now, to give you an example of some times I've done this, um when I was learning how to program, uh earlier on, I was I got like one of the example apps that like I think was I don't I don't want to say it's not common now, but like I felt like was pretty common um was that you get into this state of like, hey, I'm going to build a chat app because this is the first time that I'll be able to exercise writing code that's like um that has like network connectivity and like that's super cool because you go from like showing stuff on a screen to like I can send it to another computer and like that's totally mindboggling. Um that's how it felt at the time at least. So being able to build little apps like this was super cool.

But that meant like you know I have to open up a socket. I have to figure out and understand how to have a socket that listens. I have to have a socket that can connect. Um, and then now that we have that, like, okay, how do I make sure that I can send messages? Um, if it's just text, like how do I make sure that my, you know, receiving end can understand the payload? uh there's so many libraries and frameworks and stuff now that just like completely um you know abstract all this stuff away right like you have there's gRPC stuff there's protobuffs there's there's any there's a million different things that you could do to go sending messages between things and not have to think directly about how do I open up a socket how do I have a listener how do I uh build my my messaging structure in terms of like what the payload looks like you just don't have to think about this stuff and that's super cool.

Um, but at the time because I wanted to learn about this, I built my own thing. Now, was it good? Like absolutely not. That's not the kind of thing that I would put into like a production server, a production app of any kind and say like, "Woo, like look at me. I did it." And like that's what we should ship it because I'm so proud. Like no, I got to learn a whole bunch about connectivity and sockets. Like for example, in some some layers of what we were working with in C, like you could disconnect and there would be no way to know that you were disconnected until you tried to write. There was no like in some situations, it's not guaranteed to be graceful.

So if you wanted to have a chat app and show someone that show something that was going offline, you actually had to like test by sending it bytes and then it would be like hey can't reach it then so you could write something in the background that would do like polling right. So there was there's all sorts of things that you'd have to go build by hand to make that kind of stuff happen. And today I just feel like there's so many options where you just don't have to worry about that. But the goal was to learn. So, it meant uh and I've written about this before. I probably made videos on this, but it's like you you'll hear people say like don't reinvent the wheel. And like for the most part, I 100% agree with that. But this is a situation where it was like I'm I'm reinventing the wheel because I want to learn how the wheel works.

Okay. There were other examples of this I can think of um when I was building again all hobby projects, right? building um like games and it before Unity there was something called XNA and it was a sort of uh game engine for C that you could build um and then like you could actually have stuff run on Xbox. I don't think I ever got something onto Xbox but um but you could use C and build stuff. And for me cuz I'm like I don't want to learn C++ just to be able to go build games. I was like hey I can use X and A. I can use C. This is so cool. Um, and they had like UI frameworks and stuff that you could go use. So, if I just wanted to have a finished game or a more playable game, I probably should have taken a dependency on some UI framework, but I didn't want to.

I wanted to learn how it worked. I wanted to build my own and understand it. So um I had spent a lot of time in Windforms before that trying to like just build uh desktop applications. So I'd spent enough time where I was like dabbling in some weird areas of wind forms or like trying to do custom painting uh of controls onto forms. So getting into like some game stuff was uh you know like being able to have my own UI framework that I could poke around with was like a really cool opportunity for me to learn about. Now it meant wasting or I should I'm going to use air quotes like wasting tons of time building a custom UI framework. I'm spinning all over myself. Um but you know so much time spent doing that. And then you might say, okay, like you spent, you know, over the course of a year, you were building up your own UI framework while building a game.

Like, don't you think that was a waste of time? And the answer would be absolutely yes. If I was trying to get the game out the door, absolutely yes. And why? Because there were other things that could have done what I needed or close enough and saved me way more time. But that wasn't the goal. Right? When I'm building stuff as a hobby, sometimes it's just because I'm having fun and I'm learning. So, for me to go build my own UI framework, it was really fun to go solve those problems. There was no deadline. There was no, you know, shipping value to customers. I didn't have to worry about any of it. It was am I learning? Is it fun? If so, keep building. So there's a million other examples like this that I maybe not a million maybe not even a thousand but there's a lot of examples from my own like personal development where I was doing this kind of thing and honestly like the learning was tremendous.

So there's sort of one angle of this whole thing of like I would not take some dependency because I want to go learn about it and build it myself. So the flip side of this sticking with personal projects is like say I'm go back to the game example just because it's the last one I was mentioning. If I wanted to learn about some other part of putting the game together, say I was really interested in being like, hey, I want to practice being able to ship things, right? I want to put I want to make sure that I can um get it available on Xbox and run it on Xbox. I want to get to the point where I can be working with a controller and spending my time like making like fluid controller mechanics for moving a character around. Like that's what I want to spend time on.

Would it make sense for me to go build my own UI framework? Like probably not because I'm not prioritizing doing that. I'm prioritizing something else. But if I need a UI in my game, like I should I should probably go take some dependency on some UI framework. And the reason is because I don't want to spend time on that. There's tools available that do it, right? If we go back to the chat application stuff, if I was like, hey, I actually want to have a even though it's a hobby project, I want to be able to have like a hosted chat app. I want to get some users onto it or or whatever it happens to be. like my goal is not learning about the socket connectivity. My goal is not learning about the payloads. I want to learn about something else or I want to actually be able to deploy something and focus on other things.

Then I should go take some things off the shelf, right? I should take another dependency. And I realize like I am sort of uh I don't know minimizing or trivializing the decision- making here. But the point being that if your goal is different, it can completely change how you're weighing out the options. I'm trying to show you that given the same type of project, even though it is for personal uh hobby stuff, that I still might completely change my mind. Right. The decision making looks similar, but how I weigh the options is going to be different. And now we're hitting traffic, which is lovely. There's nothing like sitting in the fast lane paying because it's uh proportional to how much traffic there is. So, I sit in this lane and it's the it's maxed out for how much it costs for me to drive in this lane.

And if you're watching, because this should have a 360 video with it. If you're watching, I'm going the same speed as all the other lanes. And in fact, I might get lucky and it keeps moving. But I've been sitting in this part of the highway before where you're paying the max dollar and you're basically parked. There's no advantage to being in this lane. Right now, there's a little advantage. And right now that I'm about to stop, there's none. So, yay. This is why the couple of dollars of of ad revenue on YouTube helps so I can drive to work. Okay. I'm trying to think if there's anything else on the personal project side of things. Um the answer I mean there's probably tons of other things to consider, but I don't know if anything's coming to mind. But hopefully hopefully so far you're getting the the idea behind it, right?

Is like we have to think about what our goals are and then like you have options, weigh out what those options give you, right? You pick something um you're picking a dependency, you're likely, not guaranteed, but you're likely going to shorten the time um to have something working for whatever that dependency offers you. in the game example, UI framework. It could be uh there's like uh there were frameworks and stuff for networking in games, right? So, if we go back to my chat example, like if I wanted chat or I wanted to build multiplayer games and and actually I was doing this as well. I like building like role playing games. Um, and even if they were just text based or whatever, um, being able to have like, you know, uh, you could connect and play or at least like trade or something with um, with a friend.

Not like I had anyone playing the games, but like I just wanted to build the systems that did it. Like for me, I would go build the networking layer of the game myself because it was like there was more this is it's weird I guess, but there was more fun for me in building the game than there was in having a playable game. And that's actually been the case for this game uh like this role playing game that I was building over many years. It's like I've always joked like it's unless unless I retire because I'm rich and I can spend time building video games, this this thing will never finish because the the fun part is not that the game is playable. The fun part is that I get to keep building it. Like I just enjoy doing that. I'm not sure if uh if other people have had this experience even with Lego.

Um, but what I used to do as a kid was I would build the Lego set, like follow the instructions, and then like it would be done and then I would have like a very brief moment where I felt accomplished, like cool, like I did that. And then I'm I'm literally mean in minutes. I would be like, okay, like that's enough. Like I need to I need to take it apart and I need to go combine it with my other Lego sets to go build something else. like I need to be building versus just having the finished product. Um, now that's a very dangerous thing for uh for a business like and this is the whole other second half of this that I'll get into in just a moment, but when it comes to just building fun stuff like no, like I just want to learn and I want to build.

So, I'm going to optimize for that, right? I'm going to spend my time on that. If there were things I hated, like if I was playing around with sockets and networking and I was like, man, like, okay, I got to dabble in this and I hate it, then I'm I'm going to go look for a library, right? And to be honest, at this point, let's assume that somehow I had a bunch of free time on my hands, which would be hilarious. Um, if that ever happened and I was like, "Hey, I want to go back to spending more time building this um like the the RPG, the game, then at this point I might say, yeah, like I don't have any interest in doing so stuff. Like I would much rather go build interesting game systems, right? Like itemization, loot drops, uh, interesting skill mechanics, character progression.

I'd rather spend time building stuff like that than like learning about how like socket connectivity and different messaging like mechanisms work because I've done that stuff before and I'm not interested anymore. I know enough about it that like that's nice and not where I want to spend my time. Okay, let's let's pivot over to the other side of this, which is uh I'm assuming maybe what this person was after. Um sometimes when I get, you know, like single line questions that are kind of left open-ended, I I don't know exactly uh how the person wanted me to focus on the question. So just try from different angles. But when we talk about a from like a business perspective, right? So, you're working on a team. We got to build something and you have this question come up of like, okay, we need to incorporate some type of technology.

Do you build it? Do you buy it? And when I say buy, um, this could just mean taking on a dependency. Sometimes you don't have to buy anything. Other times you do because it is the option. Um, but let's talk about build it yourself. So often, and so like this is going to seem like almost the opposite take that I was just describing, but I would say often you don't want to just uh lean into building everything yourself. And the reason for that on the surface is that it's likely going to take significantly more time and many problems are already solved. Many problems are already solved in different ways. So you have options. For example, if you were like, I need to be able to compress data, right? This is it's a common thing that happens, right? You don't have to go write your own compression algorithm.

You shouldn't you shouldn't need to. You need zip files. Cool. Like there's uh if pick any language and I can guarantee you there's probably more. I can't say guarantee in probably. Let me say I can guarantee you there's going to be more than just one library or package that's available to do compression for zips. Right? So, not only is it like, okay, like I don't want to do this. I don't want it. Like, I don't want to spend the time building it. Oh, man. There's only one option. Like, I guess um it's usually for like for common things, like there's plenty of options. I would say at this point, it's probably pretty rare that no one's like that someone, how do I say this? It's probably pretty rare that no one has done anything in that space. Pick any space. I'll give you a quick example.

So, um I'm building Brand Ghost, which is a uh social media content scheduling platform. If you seen my other stuff online, uh it seems less obvious from code commute. Um but like my dev leader personal brand um or if you follow code comm if you follow code commute on anything other than YouTube anything you see is posted through brand ghost just to give you an example. Now with brand ghost I need to support different social media platforms all of these social med but the ones that we support have uh rest apis for developers. Now I need to ask myself the question of because this is not just a hobby project. This is uh intended to be a business. Do I build it myself or do I take it off the shelf? And for many of these things, if I were to search like how do I post to threads or how do I post to blue sky, how do I post to whatever.

For any single social media platform, there's at least something online. Doesn't mean that it's good, but there's at least something which makes it interesting because then I can go explore and then I can I have options. I can make decisions. I want to come back to the brand go stuff with the social media platforms in a little bit. because it's going to tell a different perspective. But um my point is that there's generally tons and tons of options that we have to explore or at least a couple minimally. So you have the option to take stuff off the shelf. Now one of the questions you want to ask yourself is like do we want to be in the business of owning this. So, if we go back to the compression example, do you want to build and now maintain a compression library? And I don't mean maintain for like I got to get around this bus.

It's like throwing up rocks and sand. Um, do you want to be the one that maintains this or do you want to look for like a heavily supported already existing compression library? Right. For something like compression, you I'm assuming most people would probably make the decision like we don't want to have to worry about that. Like our business is not purely having a compression algorithm. We'd rather just use it cuz it's a piece of functionality, right? Um you have what's let's go back to the chat application stuff, right? Okay, even know let's pick um you need chat functionality in whatever you're building. So you're building a game, you need to ship it to customers. You need chat in the game. Do you go build your own chat infrastructure? Like in terms of the like the the actual low-level messaging like probably not. You're probably not doing that for chat because there's a million examples of chat.

But I'm saying probably and I'm not guaranteeing it, right? Because the reality is depending on what your business is and where you want to focus your resources, you may make a decision where you say, you know what, we do want to own the low-level stuff for chat. And we want to do that because there's either a competitive advantage there or there's some piece of technology that we want to own. Um, and the other thing that I want to throw in there is like maintenance. I want to throw that back in there because if you're taking on dependencies, okay, so you're using some package that's out there. If it's busted and it's a core part of what your business does and there's a break in it, there's a bug and it's critical. Do you say, "Oh guess we're screwed until they fix it." Because if you don't want to find yourself in that situation, it might be something where you're saying, "Hey, maybe we do need our own.

Maybe we need a fork of this. maybe this is something that is actually fine to use and we're going to submit poll requests. We're going to actively uh contribute back to this open-source project, which is a great opportunity. Right? There's there's decisions to be made here. I'm not saying it's black and white and trivial. I'm just saying like these are different angles to think about. You don't just want to like, you know, say, "Well, no, we're not going to use it because um I don't know, uh because of the support thing." You might say that there's different angles of support fixes that you're like, "Hey, we can live with that or we can contribute back to it, whatever." Um but it's a decision that you have to kind of walk through. It's not it's not just a trivial thing. just because it exists, you take it.

Or just because you can build it, you go build it. The um the thing I'm going to jump back to with the brand go stuff um is that for almost every social media platform that we support, almost every single one, it started off by me going and looking for what's available. Okay? And the reason that I want to do this is because if there's a popular social media integration on um their API and it's well supported, right? There's tons of people using it well supported. I don't necessarily want to be in the business of like maintaining API compatibility and like supporting the new features all the time or something like if I don't have to and it's well supported that probably makes sense for brand ghost and that's because there's other stuff there's other value I'd rather be trying to build to offer to customers now sometimes and I if I go back to what I was saying though, sorry.

Like I usually start off by looking, hey, are there popular packages that that do this? And if I'm doing that like that that exploration, um, sorry, one sec. That is right. Um, if I'm doing that exploration and nothing's like showing up, then I'm like, okay, like I'm building myself. And there's been cases where I start by using a package and then I start to use it and then I'm like, you know what? I picked I made the wrong decision, right? And it's because it looked like it was doing what I needed on the surface, but then there's not enough flexibility. Because that's another thing when I go to integrate it. I'm like, hey, this isn't actually going to work the way I want. So I found like with Brand Ghost in particular, I've like I said start with let me see what's available and then most of the time I I I think I can say every time now um I've had to shift back to like rolling my own.

Now, that means kind of sucks because I have to go build it from scratch. It takes more time. Um, if there's bugs, I have to go fix them. It's not just like hopefully someone who maintains this is going to go do it. It's me. Uh, but the nice thing is, and this like this works for us building brand ghost, is like we have full control over it. So if I need to fix something and I need to fix it now, I can go fix it right now. I have that flexibility to go do that, right? I don't need someone like some uh other third party team to like have to sign off on what I'm doing. We just have like ultimate agility uh with that kind of stuff. But it does mean that we have to do it. But that's a tradeoff that we're content with.

So, um, so I was trying to say at the end of the day, I would love to not have to do all of that custom integration because I would rather be looking at other feature sets to spend time on, but so far the way it's panning out, having uh complete control over it is is proving proving proven both um to be helpful. Um, another angle to think about too is like we're talking about taking on dependencies. Not everything's free in terms of cost, right? I think some of the framing that I've been offering up so far has been like, hey, look, there's a a package that you can get online, right? There's another whole layer to this. And I guess sometimes depending on how much time you spent in the industry, this might not have even come up because there's enough free stuff online. But sometimes there's software packages that you'd be paying for.

And now there's a whole other conversation that has to happen because there's a more tangible monetary aspect to the whole decision-m. Now, what's interesting about that is like depending on what you're buying, there could be um support levels, right? So, you could be saying, "Hey, we want to I'm just going to keep going back to the same types of examples. Hey, there's this messaging framework." Uh, and it's really good like a good networking framework. It's you could send messages for chat. Uh, you could also uh integrate it into your games for sending movement and player state and world state. Like, it's really good. It's got real time support, like it's got all this functionality. Um, and now it costs. So, it's not just some free package. Now, you might want to say, okay, well, there's a free version or something that is free that's like this.

Like, why would I want the paid for one? But this just goes back to like having to do pros and cons analysis, right? I'm I'm because these are all contrived examples. I'm not going to make up a million different flavors of these things. Sorry. Work work call. My calendar's blocked. Um, so you have a free like let's say there's more than one free option and there's more than one paid for option. You need to go through the feature sets of what they offer. you need to look through um you know for the free stuff like how well is it maintained like what are the issues like on their let's say it's on GitHub uh are they responding to things are they shipping regularly because that's going to give you an idea of the support it's also not guaranteed the maintainers could just say yeah we're

done with this um if you're going for a paid for solution there might be more confidence in the support level you're going to be getting one sec Just want to see my camera is not charging. Uh, whatever. We'll figure it out. Um, so you might say, "Hey, they have a support package." And like, yeah, it costs money. And sometimes as a developer, when you're seeing the cost of stuff, you're like, "Oo, like, who would who would pay for that?" But it might be a good uh when you're factoring in like the business itself and the value that that adds, it might absolutely be worth it, right? Some of the figures might seem like not not very nice. Um, but it's not necessarily coming out of your pocket. It's like a business decision for d-risking.

And you might be able to get um support levels where you're like, "Hey, if there's an issue, support's going to get back to you within 24 hours or something or um you know, your your asks for fixes and features will be prioritized, whatever." Like I mean there's there's lots of different things here, but um you may want to pick an option like that, right? So the whole point is like and I'm realizing as I talk through this, it's basically impossible for me to try and demonstrate all the all of the differences and nuances, but the point is that you have to go through what those considerations are. This to me is more about software engineering more than the writing code. Code is just like writing code is one part of it. The engineering part to me is about the pros and cons analysis about all the decisions we have to make.

So to layer in like an AI element here when everyone's like, "Oh, AI is gonna um take our jobs as software engineers, like it might replace a lot of the coding for us, which is great. Um, it might be able to help you navigate the pros and cons, but at the end of the day, I mean, at least for now, and I think in the foreseeable future, like being able to to do the analysis on the data that's in front of us to to make a decision, like I think that's the engineering part. But I think I'll wrap it up there. I hope that was kind of a helpful way to to think through these things. So, just to quickly summarize, we kind of looked at personal projects, just trying to call out like learning paths and like if you're enjoying it, maybe you want to reinvent the wheel, so to speak.

I think that can be a really helpful way to understand how things work, have a better appreciation for things. But when it comes time to like you know shipping value to customers business um I think that a lot of the time you need to be asking yourself like do we does does our company want to be or our team whatever want to be in the business of like of owning this? If it's not core to what we're doing then perhaps not right that might be extra work. Um especially if you know problems have already been solved and they're well supported online. Um otherwise it might be something like I was saying where I need complete control over things. Um and that's turning out to be very helpful. But yeah, different ways to to go through the analysis and your situation will be different than the next person you talk to.

So it's not like just because one person says like you watched my video and I said, "Hey, I needed to write my own social media integrations." I'm not telling you to go do that. I'm telling you that if you want to go do social media integration, you should be doing the analysis to figure out if you need to or want to build it yourself. So hopefully that's helpful. Um, a quick note because I'm at the end of the video before I park here. Um, just remind folks that if you want questions answered like this one, leave them below in the comments. You can send in your questions to to Dev Leader on social media. It's my main YouTube channel as well. Uh the videos on that channel are primarily programming tutorials. There's also a resume review series there where you can submit your resume and I will review it.

Um it's all anonymized, so I'm not going to like grill people and flame them. It's all meant to be uh very helpful. If you're curious, like watch one and you'll see. like I don't make fun of people. I try to call out what I think is good, what I think could be improved and how. Uh so like I said, it's all meant to be helpful. And uh otherwise on that channel, I also do live streams. Currently, they're every Monday at 700 p.m. Pacific. They are on topics just like this one, but they're an AMA format. So I encourage and welcome everyone who's, you know, in the chat like ask questions. I will literally um change the whole topic of the of the live stream just to be on questions that you have. So, I would much rather spend the time doing that. Um and yeah, if you're curious about what the topics are on Saturdays, I send out a newsletter.

And I realize some people roll their eyes at that. They're like, "Newsletter?" Man, like that's so dumb. I don't want more email. That's totally cool. Um but if you check out weekly.devleer.ca, CA. It's called Dev Leader Weekly. Um, it goes up like a like a blog post basically. Um, so if you're like, I don't want to subscribe to anything. That's so dumb. Don't subscribe to it. That's totally cool. But you can check out the the topic that'll get posted and then that's usually what the uh live stream on Mondays will be. So, thanks for watching. I'll see you next time.