“ If something will take less than an hour or 2 to code and test, don’t even bother looking for an existing solution outside of the existing set of libraries you’re already familiar with or using. Just get to work and write some code.”
Beyond that, there’s a big long-term cost to developing everything in-house: consistency. You have unique versions of every single little helper that you’ll ever need, which now all your developers have to learn. And, you need a way to share it among all your applications in-house, and evangelize it, or have more than one version of each of those things floating around. Now you’re looking at a cost of (an hour or two *each developer * each project * each function). How will you mitigate this? Will you create a custom uber-library for just your shop? Will you version it? How will you distribute and organize it? Suddenly an hour or two becomes kind of a thing.
So rather than doing that, why not just use some well-heeled common implementation that’s already out there, that’s already tested, that’s already had the edge cases considered?
So I have exactly the opposite philosophy as you. If it’s something that would take just an hour or two to code and test (assuming I got it right the 1st time, which you don’t always), then it’s simple enough that I have almost no risk from using someone else’s code. I can completely understand it’s purpose, functionality and API with very little effort. I can easily replace it in the future if I need to. And frankly, I’d rather spend my time creating code that adds value, rather than re-implementing some mundane algorithm and writing unit tests for same.
On the other hand, I would think long and hard before integrating some big wonder-module with lots of moving parts and grandiose functionality. Sure, it could solve all your problems, but the first time it doesn’t do exactly what you want, you’re looking at reverse-engineering, or patching, or hacking, or working around… and by that time you’re so tightly coupled with that big thing, you can’t easily just use something else. Because it’s big, and you depend on that bigness as a unit.
Don’t be a brickmaker. Be a mason.