Latest / DevQuestions with Tim Corey / 089 When Should I Build My Own Instead Of Using A NuGet Package?

Transcript

089 When Should I Build My Own Instead Of Using A NuGet Package? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: When should I build my own library instead of using a NuGet package?
• 0:29
  SPEAKER_01: This is a balancing act you have to hit as a developer.
• 0:33
  SPEAKER_01: So let's talk about it in today's episode of DevQuestions.
• 0:38
  SPEAKER_01: Now, let's talk about really what the difference is between bringing your own library in versus building a NuGet package or taking a NuGet package as a dependency.
• 0:50
  SPEAKER_01: So if you build your own library, you're taking the time to actually do the work that someone else has already done.
• 0:57
  SPEAKER_01: Essentially, you're reinventing the wheel.
• 1:00
  SPEAKER_01: But on the other hand, if you bring in a lot of NuGet packages, then you have a lot of dependencies and potentially a lot of extra wasted space in your application.
• 1:13
  SPEAKER_01: Now, the key here is going to be balance.
• 1:18
  SPEAKER_01: I've heard arguments for all on one side or all on the other side.
• 1:23
  SPEAKER_01: I tell you what, really, if you find yourself in either of those camps where you're always going to build something, or you're always going to use a NuGet package, either way, you're making a mistake.
• 1:34
  SPEAKER_01: You have to evaluate the situation on a per situation basis and make the wisest choice for your application, your situation, your team, and your project.
• 1:48
  SPEAKER_01: So let's talk about the criteria for building a library versus using a NuGet package.
• 1:56
  SPEAKER_01: The first question I would ask is is this the focus of my application?
• 2:02
  SPEAKER_01: Oftentimes people get distracted by building cool libraries or cool um code that does the job of some kind of peripheral piece, but it's not really the focus of the application.
• 2:16
  SPEAKER_01: Well, if it's not the focus of the application, why is it taking so much time away from the focus of the application?
• 2:24
  SPEAKER_01: You gotta balance out and say, okay, is it worth taking our focus away from our primary goal in order to accomplish this other piece?
• 2:33
  SPEAKER_01: Is investing that much time worth it?
• 2:36
  SPEAKER_01: Okay, so that's the first question.
• 2:38
  SPEAKER_01: Is this the focus of my application?
• 2:42
  SPEAKER_01: Number two, and this is gonna sound weird, but how much are you willing to pay for this feature?
• 2:48
  SPEAKER_01: And you may say, Tim, I'm not willing to pay anything, that's why I'm writing my own code or using a NuGet package.
• 2:54
  SPEAKER_01: But you are paying either way.
• 2:58
  SPEAKER_01: What I mean by that is your time is valuable.
• 3:02
  SPEAKER_01: And so if you decide, hey, I'm going to use a NuGet package, you are going to use less time on that feature.
• 3:11
  SPEAKER_01: But if you decide, nope, I'm going to build that myself, you've got to ask the question, how much am I willing to pay?
• 3:19
  SPEAKER_01: So is it two hours?
• 3:21
  SPEAKER_01: Is it four hours?
• 3:23
  SPEAKER_01: Is it eight hours, two weeks, two months?
• 3:26
  SPEAKER_01: What is that feature that you're going to build yourself?
• 3:31
  SPEAKER_01: How big is that investment going to allow be allowed to be?
• 3:35
  SPEAKER_01: Because oftentimes people just don't evaluate that question.
• 3:39
  SPEAKER_01: And so instead they just dive right into doing it, doing the building without thinking through, is this worth it?
• 3:47
  SPEAKER_01: If you're gonna step back and said, hey, you know what?
• 3:50
  SPEAKER_01: I am going to pay eight hours for this this um replacement for a NuGet package, this this custom code.
• 3:59
  SPEAKER_01: Okay, well, if it takes you two weeks, then is it worth it?
• 4:05
  SPEAKER_01: Well, you'd say, no, what is not worth it?
• 4:07
  SPEAKER_01: Well, then evaluate that up front so you know, okay, I'm going to spend eight hours on this.
• 4:13
  SPEAKER_01: And if you blow past eight hours, say, you know what, it's just not worth it.
• 4:17
  SPEAKER_01: And don't get caught up in sunk costs, and we've already spent some time here.
• 4:22
  SPEAKER_01: Cut your losses, use a NuGet package.
• 4:26
  SPEAKER_01: So, how much time am I willing to pay?
• 4:28
  SPEAKER_01: Now, you may say, Well, Tim, I'm unemployed, so my time is free.
• 4:33
  SPEAKER_01: It's not free.
• 4:35
  SPEAKER_01: You only have so many hours of the day.
• 4:38
  SPEAKER_01: You could spend those hours with your family, you could spend those hours studying C sharp, you could spend those hours looking for jobs, you could do a lot of things with time.
• 4:50
  SPEAKER_01: So just saying, well, my time is free, that's not really true.
• 4:54
  SPEAKER_01: You're going to take away from other categories in order to use it on this library or this bit of code.
• 5:02
  SPEAKER_01: So you have to evaluate how much time are you willing to pay for this?
• 5:08
  SPEAKER_01: How much of a um a chunk of your time are you willing to donate to replacing what another NuGet package could do?
• 5:18
  SPEAKER_01: Okay, now if you're a business, this is pretty clear because every employee is associated with a price tag.
• 5:26
  SPEAKER_01: You get paid at a business, hopefully.
• 5:29
  SPEAKER_01: If you don't, then re-evaluate.
• 5:31
  SPEAKER_01: But you get paid at a business, and so let's just say you get paid twenty dollars an hour.
• 5:37
  SPEAKER_01: Well, then if it's going to take 10 hours, that's$200.
• 5:43
  SPEAKER_01: Is that feature worth$200?
• 5:45
  SPEAKER_01: Versus if you say it's gonna take me a thousand hours of between you know three people plus deployment and all the rest.
• 5:53
  SPEAKER_01: Well, that's twenty thousand dollars.
• 5:58
  SPEAKER_01: Is that feature worth twenty thousand dollars?
• 6:01
  SPEAKER_01: You might look at that and go, well, no, I've got a New Year package that could save us twenty thousand dollars, maybe even eighteen thousand dollars if you say that well, it's gonna take some time to implement.
• 6:12
  SPEAKER_01: Okay, so you gotta evaluate that realistically, whether you're actually getting a salary or not, because time is valuable.
• 6:21
  SPEAKER_01: Now, number three, you need to look at how important is this piece.
• 6:28
  SPEAKER_01: So if you are putting something in that's really important or really vital, you need to have a different criteria for evaluating it versus a maybe trivial piece.
• 6:40
  SPEAKER_01: For instance, if you're putting in logging, I highly recommend that you use a NuGet package.
• 6:48
  SPEAKER_01: Quite frankly, CeraLog is a great option.
• 6:50
  SPEAKER_01: There are others out there as well, nlog, log4net, but one of those options is really important to use.
• 6:58
  SPEAKER_01: And the reason why is because of speed.
• 7:01
  SPEAKER_01: Because logging is a very important part of your application.
• 7:06
  SPEAKER_01: It's important not only that it's fast, but also that it is unobtrusive, that your application does not crash because your logging has a problem.
• 7:16
  SPEAKER_01: Your logging needs to not affect your application as much as possible.
• 7:21
  SPEAKER_01: It needs to have a low memory footprint, it needs to have very fast operations, it should probably be asynchronous so it doesn't hold up a thread.
• 7:30
  SPEAKER_01: There's a lot of things it should do.
• 7:32
  SPEAKER_01: And it's a lot more complex than just writing to a text file or writing to a SQL Server.
• 7:39
  SPEAKER_01: Okay, so the idea that you would treat your logging solution the same way as you would treat some non-trivial P or trip, you know, some trivial piece of your code is not the right idea.
• 7:53
  SPEAKER_01: You want to give more importance to the things that are more important, the things that are more critical to your application.
• 8:01
  SPEAKER_01: So that will change the criteria.
• 8:04
  SPEAKER_01: So asking the question, how important is this piece, should adjust how you look at using a NuGet package versus using your own library.
• 8:16
  SPEAKER_01: Next up, how complex is the solution?
• 8:20
  SPEAKER_01: This is one I see a lot that in some ways makes me chuckle, in some ways it makes me cringe.
• 8:25
  SPEAKER_01: Because often people will look at a solution and go, yeah, I could do that.
• 8:31
  SPEAKER_01: Take a step back and look at it.
• 8:33
  SPEAKER_01: Really evaluate the complexity of a situation.
• 8:38
  SPEAKER_01: One big one, one good example is authentication.
• 8:41
  SPEAKER_01: Again, I'm going to highly recommend that you use a NuGet package for authentication.
• 8:47
  SPEAKER_01: Use a third-party system, do not roll your own.
• 8:52
  SPEAKER_01: Because the fact that's a highly complex and incredibly important part of your application.
• 9:00
  SPEAKER_01: So you shouldn't be writing the code for that on your own.
• 9:05
  SPEAKER_01: Because the vendors and the people who have built authentication systems, they have spent hundreds and thousands of hours and have had teams of people pour over solutions.
• 9:18
  SPEAKER_01: They've had evaluations, they've had people review that, they've had people try to break it, they've had lots of patches and fixes and spent tons of time on making that a good solution.
• 9:33
  SPEAKER_01: You coming in and deciding I'm gonna write my own means that you are throwing away thousands of hours instead of saying, let's recreate this wheel.
• 9:46
  SPEAKER_01: That's probably not a wise idea.
• 9:48
  SPEAKER_01: So if the solution is complex and your application depends on it, maybe you look at leaning more towards a NuGet package rather than building your own.
• 10:01
  SPEAKER_01: Now, number five, how much of the package are you using?
• 10:05
  SPEAKER_01: So this is one again, I see uh quite often where people will bring down this complex package, this large package, and then use it for one tiny feature.
• 10:17
  SPEAKER_01: Uh this is an example from C sharp, but jQuery used to be a big uh been abused for this for a very long time.
• 10:26
  SPEAKER_01: It was a big deal because what would happen is people got so reliant on the jQuery library that they started to really forget how to use vanilla JavaScript.
• 10:37
  SPEAKER_01: And so they'd bring down jQuery.
• 10:40
  SPEAKER_01: And at the time it could have been quite large because of all of the you know iE6 and 7 issues and all the rest.
• 10:47
  SPEAKER_01: So the library got larger and larger, and they would bring jQuery down just for selecting elements.
• 10:53
  SPEAKER_01: Well, you can do that with vanilla JavaScript, you can save that whole download of the jQuery library, you can not put that into memory.
• 11:02
  SPEAKER_01: You don't have to have that library at all in order to just select elements.
• 11:06
  SPEAKER_01: So if you're using a small piece of a package, maybe evaluate is there a better package out there where I can use just that piece, but that's mainly all the package is, or should I build just that piece and save myself even how to bring any packages down into my software?
• 11:28
  SPEAKER_01: And then number six, what does the support level look like?
• 11:33
  SPEAKER_01: Now, when I first say that, you probably are thinking about just NuGet packages, and that is important.
• 11:38
  SPEAKER_01: Looking at the NuGet package to see, hey, has this been around for a while?
• 11:42
  SPEAKER_01: Does this have a team to support it?
• 11:44
  SPEAKER_01: Does it have a business model that will sustain it beyond just a user's goodwill?
• 11:50
  SPEAKER_01: Okay, that's important to evaluate.
• 11:52
  SPEAKER_01: But on the other side of it, what's the support level look like for you writing it yourself?
• 12:00
  SPEAKER_01: Because let's just say you're a one-person shop.
• 12:04
  SPEAKER_01: Okay, you're running an application that has 50,000 lines of code, really small, but 50,000 lines of code.
• 12:12
  SPEAKER_01: Well, if your features are going to add another 5,000 lines of code, that's another 10% of an application you need to support.
• 12:21
  SPEAKER_01: If you are right on the the cutting edge or the the you know, just on the edge of falling off a map when it comes to how much work you have just to support what you do already, adding one more thing to support might push you over.
• 12:37
  SPEAKER_01: So your support level is important as well.
• 12:41
  SPEAKER_01: If you don't have the resources to not just build that feature, but support it long term, that can be a problem.
• 12:48
  SPEAKER_01: So again, going back to the idea of how much am I willing to pay, it's not just a one-time payment.
• 12:55
  SPEAKER_01: That is the big payment up front.
• 12:58
  SPEAKER_01: But then you also have that payment of over time, I will have to support this feature, I will have to improve this feature, I will have to upgrade this feature.
• 13:08
  SPEAKER_01: Am I willing to do that?
• 13:10
  SPEAKER_01: Do I have the opportunity to do that?
• 13:13
  SPEAKER_01: So those are the six questions I think through.
• 13:16
  SPEAKER_01: And as you notice, I didn't give you a firm answer.
• 13:20
  SPEAKER_01: There isn't an answer I can give you where I can say, this is what you do all the time.
• 13:25
  SPEAKER_01: These are the questions that you have to look at for your situation.
• 13:30
  SPEAKER_01: Some of these answers are going to depend on your organization.
• 13:34
  SPEAKER_01: How many people are working on the project?
• 13:36
  SPEAKER_01: How much time do you have to work on the project?
• 13:39
  SPEAKER_01: What are your constraints?
• 13:41
  SPEAKER_01: Um, what's your level of skill in certain areas?
• 13:46
  SPEAKER_01: That's going to be important.
• 13:47
  SPEAKER_01: How much do you have as far as long-term support?
• 13:52
  SPEAKER_01: Those are the kind of questions you have to answer based upon your team.
• 13:57
  SPEAKER_01: And so it's going to change from company to company, even the exact same project, the right answer, and I put right in quotes because you have to make the choices right for you, but the right answer is not necessarily one specific answer.
• 14:16
  SPEAKER_01: You might choose one or the other, and it might be okay to choose either one.
• 14:20
  SPEAKER_01: But the answer is best for you, even if you're building the same exact solution as another company, might not be the same right solution for that other company.
• 14:31
  SPEAKER_01: Because it's more than just about even the software you're building or the package you want to use.
• 14:37
  SPEAKER_01: It's about the environment, it's about the time frame, it's about what you've already done, it's about where your team is at, how big your team is, how technical they are, and so many other variables.
• 14:50
  SPEAKER_01: So by asking these six questions, that will help you hone in on what you think is best for any given situation.
• 14:59
  SPEAKER_01: Now, I will say that you don't want to just look at NuGet packages and think they're bad.
• 15:08
  SPEAKER_01: I hear companies do this.
• 15:09
  SPEAKER_01: They say, oh, NuGet packages are dependencies and they bloat your application and you don't want them.
• 15:16
  SPEAKER_01: That is a poor take because it's it's not taking into account the big picture, it's taking into account one specific situation.
• 15:25
  SPEAKER_01: Some NuGet packages are bad.
• 15:28
  SPEAKER_01: Some NuGet packages will bloat your application.
• 15:31
  SPEAKER_01: But that's not all.
• 15:33
  SPEAKER_01: In fact, we used to have in.NET Core a much larger framework.
• 15:39
  SPEAKER_01: I'm sorry,.NET Framework.
• 15:40
  SPEAKER_01: We had a much larger framework than we do in.NET Core.
• 15:44
  SPEAKER_01: Part of that had to do with a lot of workarounds and just kind of bloat over time.
• 15:48
  SPEAKER_01: But part of that was the.NET framework tried to be a Swiss Army knife.
• 15:53
  SPEAKER_01: It tried to have a tool for every situation.
• 15:57
  SPEAKER_01: Well, when.NET Core was rewritten out of.NET Framework, the designers said, you know what?
• 16:04
  SPEAKER_01: You're not going to use all these features all the time.
• 16:07
  SPEAKER_01: So instead of integrating those right into.NET Core, what they did was create NuGet packages.
• 16:14
  SPEAKER_01: And they created a small core and then said, if you need a feature, you bring it in instead of us embedding it into the framework.
• 16:24
  SPEAKER_01: So.NET Core, you may have three, four, five, eight, tenet packages from Microsoft installed.
• 16:33
  SPEAKER_01: That is not bloating your application.
• 16:36
  SPEAKER_01: That is actually making it slimmer than if it was in.NET Framework.
• 16:41
  SPEAKER_01: Because.NET Framework had all those things plus more installed.
• 16:46
  SPEAKER_01: So you can't just say, oh, NuGet packages bloat your application.
• 16:51
  SPEAKER_01: They don't always do that.
• 16:54
  SPEAKER_01: It's about what do you need?
• 16:57
  SPEAKER_01: So don't look at this in a very binary yes or no.
• 17:01
  SPEAKER_01: You gotta look at this in more of a sliding scale where you have to evaluate each one.
• 17:08
  SPEAKER_01: Now, yes, NuGet packages can hold you back from upgrading.
• 17:13
  SPEAKER_01: So when.NET Core came around and people started wanting to move their.NET framework projects to.NET Core, some libraries weren't up to date and weren't being maintained.
• 17:26
  SPEAKER_01: And so that held back companies.
• 17:28
  SPEAKER_01: In fact, dependencies are more likely the cause for holding back a project from upgrading than the actual project is.
• 17:38
  SPEAKER_01: So, yes, that can be a problem.
• 17:41
  SPEAKER_01: And that's one of the reasons why you want to evaluate every NuGet package because you want to find the balance between taking a dependency or creating your own dependency that you have to do the work to upgrade on versus allowing somebody else to do that work.
• 18:00
  SPEAKER_01: There's gonna be a balance there, okay?
• 18:03
  SPEAKER_01: But you've got to think through every situation and hit that balance appropriately for every single situation you come across.
• 18:12
  SPEAKER_01: At the end of the day, you're gonna find that you probably should have, you should have probably quite a few NuGet packages installed, but not maybe as many as you might think.
• 18:23
  SPEAKER_01: Okay.
• 18:24
  SPEAKER_01: Again, more than none, less than all.
• 18:28
  SPEAKER_01: That's what you want to hit is find that middle ground and really evaluate each one to know, yes, this is important versus you know what?
• 18:37
  SPEAKER_01: We can do this ourselves and figure out that balance.
• 18:40
  SPEAKER_01: Okay, so that's my my answer to the question of build versus download.
• 18:45
  SPEAKER_01: Thanks for listening to this week's episode of Dev Questions.
• 18:48
  SPEAKER_01: Have a great day.
• 18:49
  SPEAKER_01: And as always, I am Tim Corey.
• 18:52
  SPEAKER_00: Thank you for joining us for this episode of Dev Questions.
• 18:55
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 18:58
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share dev questions.
• 19:06
  SPEAKER_00: You can also send your questions to questions at imtimcore.com.
• 19:11
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 19:18
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcorey.com and enroll in the course.