327. How Do I Evaluate a Third-Party Tool or Library in the Age of AI?

How do I know when to use a third-party tool or library? When seemingly everyone can vibe-code a flashy tool, how do I not get burned? Can I rely on some of these tools or do they threaten my production app? What if the tool has a vulnerability or goes away? How do I evaluate my dependencies? These are the questions we will answer in today's episode of DevQuestions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:04

It seems like everyone is vibe coding apps and tools these days. With code being so easy to write with AI, it's easier than ever to turn an idea into a product. Unfortunately, building that product was almost never the hardest part. Building a secure performant product is much harder. And then supporting it long term is even harder still. These are the areas where a lot of apps and libraries are already failing. So how do you know what tools and libraries to depend on when you're building your own app? Should you build everything yourself, or should you only depend on tools from reputable sources? Let's talk about it in today's episode of DevQuestions. Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about how to evaluate third-party tools and libraries in the age of AI. Now, I don't know about you, but I get nervous anytime I see an app that was clearly vibe-coded. I have seen too many instances of apps that seemed to work only to discover later that they leaked all their sensitive data or that they'd failed the worst moment and were just abandoned. If you are building an app, you probably are going to depend on third-party resources like emailers, PDF tools, data access libraries, and more. So, how do you know what's a good app to depend on and what's not a good app to depend on? So let's talk about what not to look at or not to depend on when validating a third-party library app. Number one, open source. Just because something is open source doesn't make it good. The kind of misconception is, well, if it's ever a problem, I can just fork it and build my own. Really? Really? Have you ever tried that? Have you ever actually done the work of saying, hey, let's test out what would happen if this library suddenly stops supporting the latest version of.NET? Could we upgrade it to the latest version of .NET? Have you tried? Because more than likely, it's not nearly as easy as you think it is. And even if you say, well, we're going to use AI and just have AI do it, it that's even harder because now you have an app that AI is not going to fully read through that third-party system. And so it's going to make some guesses and it's going to create more and more spaghetti code until you ring it in and you won't because you don't know the code itself. And so it just creates a bigger ball of mess to deal with. So just because something is open source doesn't mean it's a good system to depend on. Now, being open source can be a valuable thing and it can be a point in its favor, but don't look at something and say, oh, well, it's open source, that must be good. So don't look at open source as the qualifier for something to be good. There's other things to look at. Number two, don't look at just because it's a product from a big company. There is a whole Twitter account dedicated to apps killed by Google, because Google is notorious. In fact, I've told my team, I said, we will not rely on products from Google because they're just notorious for shutting down good working products. So not going to trust it. Even Microsoft and Microsoft is better, but they still have a number of dead products in their wake. And you might say, well, no, there's bad as everybody else. To be fair, WinForms. WinForms has been supported since.NET 1 back in 2001, 2002 timeframe. That's 24 years. We've had.NET WinForms, and that's been supported that entire time. So they do have a long track record of supporting certain things. Not everything. It needed to die, but it did die. Okay. And then there is the WCF, and there's, you know, Silverlight always gets thrown in there, but that's not really their problem. But at the same time, yeah, it's an app that died because a different big company killed it. So just because it comes from a big company doesn't mean it's going to be around forever. It might last a year or two, or it might last for 20 years. You just don't know. And saying, well, they have mountains of money to support it. Yeah, do they though? Because every time I turn around, it seems like these big tech companies are laying people off and cutting divisions. So while it may seem like they have lots of money, typically that lots of money goes towards shareholders, not towards your particular library that you want supported. So just be careful saying, well, it's a big company. Doesn't mean anything. Number three, just because it has a lot of stars on GitHub doesn't mean pretty much anything. Stars don't pay the bills, they don't indicate quality. They don't in any way give you an indication that this is a good library, except for the fact that a number of people have said, yeah, I want to watch this, or yeah, I think this is an interesting project. Now, when a lot of people say that, it could be good. But I see a number of projects that are bad projects, but they've got great marketing. And all of a sudden they have lots of stars on GitHub. So just be careful. There is a data point, but it's not a deciding factor. Just like open source, it's a data point. It should not be a deciding factor. So what should you evaluate when it comes to a third-party library or tool? Well, number one, does it have a monetization strategy? This is something that people just don't understand. If a tool, if a library, if something you depend on does not have a way to make money, it does not matter how enthusiastic the team is. It is in danger. I'm not saying it's going to go away. It may last for life. You don't have to pay for Linux. It's been around forever. Now, yes, there's pay Linux versions or distros, but Linux. You can that Linux has been around for a long time. It's free. Git, I would expect Git to be free forever. Like there's a number of things that we depend on that, yes, they've been free forever. But that doesn't mean it's something that you should ignore. It is a big red flag when something does not have a monetization strategy. At some point, the people developing it are probably going to get tired. And at that point, the enthusiasm is gone. Maybe their employer used to pay for this. I know a number of packages right now that are starting to figure out monetization now. It's kind of too late, but they're trying, because the fact that their work used to pay for it. It used to pay for their time. It used to pay for their work on the project. Now it doesn't. So what now? Like now all of a sudden there's no money coming in and there's a lot of people saying, I have problems. Please fix my problems. So having a good monetization strategy is really important. It makes me feel good when I can look at something and say, I understand how they make money. Because here's the deal. Yes, I don't like being nickel and dimed, I don't like having a subscription for everything I do. I don't like having to pay hundreds and thousands of dollars just to maintain my life. But at the same time, if an app depends on you continuing to pay, in general, they're going to do things that keep you paying. Now, yes, there's a lot of companies, there's a lot of venture capital, other, you know, uh resources that come in and say, hey, you know what, we're going to squeeze the money out of people. I get that. But when you're looking at a library and they have a way to make money, they want you to continue using their library. So they're going to do things that maintain that library, hopefully. Now they'll also probably try and lock you in, all the rest. There is a balance, but having a good monetization strategy means they're incentivized to keep going. That's pretty important to me because when they're incentivized, they are thinking less about trying to figure out how to make ends meet and more about how to keep you going, which means better systems, means more features, it means being faster, whatever it means in order to make you keep going with their library. Number two, does the creator have a track record of support? So when you're looking at who is creating it, look at their track record. Have they killed a whole bunch of products? This is why when I look at Google's products and they call it a new product, I'm like, nope, not going to depend on it. I haven't used Google's AI. And the reason why? I don't want to depend on anything Google creates, because I have been burned too many times. I just don't trust them. So even though they might have a great app or a great library or a great system, I go, I don't trust that. Whereas other things I've used for years, I go, you know what? Yeah, I kind of trust them because they've been around forever or because I know that they have supported other things. And this is just one more thing. Look at who they are. Look at their track record. And if possible, look for things that have a track record of success, of support, of customers that have been taken care of over time. And then you can look at their products and go, okay, I'm more likely to consider that. Number three, the question you probably should ask right the bat, but do you really need this dependency? That's a question that too often people get caught up in, oh, I need this, I need this, I need this. They never think, do I need this? Or is this just a convenience thing? And there are, I'm a big proponent of actually using third-party libraries. I'm a big proponent of using tools that make your life better. For example, almost practically without fail, if I'm going to access a SQL type database, I'm bringing in Dapper. It's just almost a given at this point because it's a lightweight tool, it's been supported for a long time, it has a monetization strategy. It's a great tool that I can depend on. And it makes my life easier. And I don't have to rebuild that every time. So I'm not going to reinvent the wheel. Even though it's open source, I could probably go and grab the code for it and you know just recompile it myself. Not going to do that. Okay. So there are tools like that that I use. And I'm a big proponent of using tools that are best for different systems. I'm going to talk to Redis. I'm going to use the Stack Overflow Redis tool or Stack Exchange Redis tool. Because it's a proven tool and it's it's optimized and it's they've done all the work that I just don't want to do. And be very careful not to confuse something works with something that's good. Both of those are great examples of they're good, not just they work. Because you know, Dapper, for example, it's practically as fast as raw ADO.NET code. Okay. But yet it's it's so much more performant for me as a developer when it comes to I just get my models out the way I want. I send models in, I get models out. That's so much more efficient than dealing with data tables and all the rest. So that efficiency, though, is really important because I could probably recreate what DAPR does, but it wouldn't be as efficient. So now I have slower code, but it's more efficient for me as a developer. And I have to maintain that code too. Like, be careful you weigh these things. However, there are times where I've seen people bring on a whole new dependency because of one little thing. Don't do that if you can help it. Try and trim that down. Instead of bringing in three different dependencies from three different sources, see if you can bring in from one that supports all three things. Like try and figure out do I need this? Do I even need to create this dependency? And if I do, what's the simplest way of doing it? Dependencies are something that can really hold you back as an application, as a development team. So be very careful what you use. But at the same time, the other side is true too. It can hold you back if you're trying to rebuild everything yourself. And don't just say that AI can do it. AI can build working things, it is not build efficient things, it is not build things that are secure by default. You've got to put the work in to make them efficient. You've got to put the work in to make them secure. You got to put the work in to make it write good code that's clean and simple and easy to read and understand, easy to maintain. Otherwise, what you get is a lot of code that's harder to maintain. And you just create more and more spaghetti that at some point it's gonna come crashing down. So be careful. There's a balance. Taking on dependencies, it's always a risk. You have to weigh the risk of taking one on against the risk of not taking one on or of taking a different one. No matter what you do, there's a risk. So you have to figure out which risk is most palatable. The better you get at honestly evaluating risk, the better your app will be. No matter what you do, you're gonna take on risk. So make sure you take on the right risk. Thanks for listening. And as always, I am Tim Corey.