> If you implement in house then you've just given yourself an extra burden for the life of your project.
If you are doing this work for an organisation, you can also argue that it is professionally irresponsible. You are certainly unlikely to be there forever to pick up the tab for that. Coding in house is a toxic line of thought endemic in mid-level developers who haven't yet had exposure to full lifecycle costs of custom code.
(And ironically the problem of so many crappy libraries is precisely due to people succumbing to NIH rather than uniting around a standard solution.)
From my experience so far, I'd rather inherit an in-house solution to something than a hacked-in didn't-exactly-meet-the-requirements-in-the-first-place third party library. I find the latter cases particularly painful to keep running well when the need to update the original project comes along.
If you're going to pick a third party library, try to make sure you can depend on it to be supported for as long as your project will be. Otherwise it's not much different than inheriting code that's not supported because the original author left the company.
The built-in-house solution tends to have less useless-to-me stuff bolted on in an attempt to be "versatile" but that ends up getting in the way down the line. (This is hardly universally true, though: the built-in-house swiss-army-knife attempt is probably the worst of all worlds.)
While I agree it'd be nice for their to be unification, rather than a fragmented set of varying libraries, the one size fits all solution tends to be a maintenance nightmare. I guess we just have wildly different experiences, but mine is such that adding a third party dependency is typically a major liability and often originates from less experienced developers.
Adding a dependency is a burden. You don't have direct control over the evolution of that code. You have to keep track of the changes. If you're lucky, the library will have a changelog, but that's sorely lacking in most projects. Blindly upgrading will bite you, so if you have a product that can't suffer downtime, you really need audit that code for every upgrade. Good luck if you've determined that the version you have is sufficient, so you've locked it down, but then a security issue is found . . . winding back patches like that can be an exercise in futility. Oh, and then there's the wonderful world of transitive dependencies.
NIH for everything isn't ideal, naturally. But pushing everything out to 3rd party libs has its own set of problems that in many cases are worse. In my experience, a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain.
> a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain
Indeed, but this is hopefully obvious to all of us. My point is that the cost of maintenance is vastly higher than is ever really understood. Most code is written in the context of delivering a project, and here the highest cost is considered to be getting functional code out of the door (even the first set of bugs is often overlooked).
I'd propose the counterintuitive and unpopular view that the cost of development is the tiniest fraction of the lifecycle cost of lines of code when you factor in things like bugs, keeping up with security, adapting to environment changes, modifications due to new requirements, and probably most importantly the multiplying effect of adding new moving parts which makes each piece of code in a solution more expensive to write and maintain than the last.
I'm perfectly aware that this will seem ridiculous and in some ways it is a little aggressive to make the point, but as evidence I would consider how many work years are spent on libraries which contain a tiny part of the functionality that is contained in useful software.
Therefore the trade-off, while being about the right things, is very rarely correctly sized.
If you are doing this work for an organisation, you can also argue that it is professionally irresponsible. You are certainly unlikely to be there forever to pick up the tab for that. Coding in house is a toxic line of thought endemic in mid-level developers who haven't yet had exposure to full lifecycle costs of custom code.
(And ironically the problem of so many crappy libraries is precisely due to people succumbing to NIH rather than uniting around a standard solution.)