[brian-armstrong]

It's great to someone express this point. Though it's hard to beat the convenience of dropping someone else's library into your codebase, each new dependency adds more security surface area and bloat to your application. I wish people considered this balance more carefully.

In general I think a littlw NIH is a good thing. Even if there exists a library that does what you want, it might also include much more that you don't need, and perhaps the kernel of what you want fits into a small function you can write and vet yourself.

[bcherny]

An idea of open source is that it's very likely that your own implementation is buggier, slower, and more poorly specified than the existing state of the art open source implementation.

https://en.wikipedia.org/wiki/Wisdom_of_the_crowd https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[hinkley]

Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities?

I'm dealing with a bunch of people now who did something like that. At the time they made these decisions they might have had good reasons, but now they're doing other stuff and the custom things they wrote are a huge liability.

Don't write it unless you intend to own it.

[jfoutz]

I think a good heuristic is, is it your business?

I'd try really hard to avoid implementing address verification. Unless i worked at UPS or FedEx.

I'd try really hard to avoid implementing spellcheck. Unless i worked on Word.

If it's a core to survival thing, yeah, you should probably roll your own. If you can't beat OSS state of the art, well, you've got a problem.

The other heuristic i think is generally good, go for a couple of big dependencies over a whole bunch of small dependencies. Coping with the interaction between 3 huge libraries is so much easier than 100 tiny libraries.

[hinkley]

Sure, I use this one too. If it's not your core competency buy it from someone else.

[toast0]

At the same time, depending on external contributions has risks.

My rule is don't introduce code unless you intend to own it.

If it is big, hard to follow, and has crazy dependencies, maybe you don't want to own it.

[chetanahuja]

"My rule is don't introduce code unless you intend to own it."

Or more accurately, you do own it. Whether you intend to or not. All its bugs are your problem now. Each upgrade to the next version, with all those new bugs and features are your problems now. Any bug that other people haven't noticed yet, they're solely your problem now. Any extra code that your use-case didn't really need but opens up more surface area for hackers, it's your problem now.

[Chris_Newton]

Even if your code is better than the OSS alternative now, are you going to be able to maintain it at that level, given all of your other responsibilities?

If someone was able to produce better code in some way before, despite any OSS alternatives available at the time, why would anyone assume they could not also maintain and develop that code more effectively than the same OSS community and projects in the future? That makes no sense.

A lot of developers seem to make dubious assumptions today about the quality of something they could import compared to the quality of what they could build in-house. There’s little reason or evidence to support a lot of those assumptions, but people continue to make them regardless, because hype and inexperience are things.

If you’re talking about a huge OSS project with many contributors, quite a few experts involved, well-established infrastructure and funding, and so on, then sure, it’s a tough thing to beat. I couldn’t set up and maintain a new operating system with the same capabilities as something like Debian or FreeBSD, and neither could any other small team.

But most OSS isn’t like that. Lots of OSS projects have only a single main developer, or maybe a small team of contributors, and those people may or may not be as skilled, experienced, dedicated or simply available as your in-house team. Lots of OSS projects effectively get abandoned, sometimes even well-known ones with lots of contributors, major commercial backing and a large user base. Lots of OSS projects are highly unstable, and if you depend on one that needs constant updates to keep it working, that’s an overhead of its own. There is precious little evidence that OSS quality is better in general than something a good team could have built in-house.

And even if none of those things were true, your own in-house development would still be focussed on your specific needs and priorities, instead of trying to be a generic tool with potentially a lot of functionality (and risk) you don’t need, and potentially being steered in a future development direction than doesn’t meet your needs as effectively.

Don't write it unless you intend to own it.

The flip side of that is that if you do want to own it, writing it in-house may well be a better option.

Obviously there has to be a balance, and reinventing the wheel (or a sports car) for every project isn’t necessarily a good use of time and resources. Bringing in a good external tool or library that solves a problem for your project effectively can be a huge win, particularly if it’s in an area that isn’t a core part of your own project.

However, I believe the current culture in some parts of our industry is crazily biased towards bringing in external libraries to do every little thing. That is a very dangerous trend that we must challenge, because we’re writing an awful lot of awful software as a result.

[true_religion]

True, but Javascript libraries tend to be pretty small and deal with well-known concepts. Many experienced dev's have seen a router 10x by the time they've come to React-Router, and the entirety of the source code can be read in a single day.

If you both (a) have experience and (b) have read and understood the entirety of a library, then you are in the best position to claim that you can do it better in house.

The prevelance of libraries doing the same thing in Javascript shows that alot of people have different ideas, and due to culture decide to open source it instead of keeping it in-house.

Other communities do the reverse. There are probably a million homebaked Java frameworks that will never see the light of day because people in Java land don't think that MVC is so extra ordinary that they need to release their in-house needs specialized framework.

[douche]

One of the weaknesses of Javascript is its absolutely terrible standard library. In comparison to languages with solid, comprehensive, "batteries-included" standard libraries, you spend a lot of time re-implementing basic functionality. Or you import jQuery, or LoDash, or underscore, or use pieces of Ember or Angular, or React, etc, etc. Or some bastard abomination of all of those.

[bcherny]

I'd argue that's a strength. Note how scala is modularizing its standard lib in Dotty, and TypeScript is doing that same for stdlib typings.

Standard libs are great, but they need to be modular. If they're modular then they are versioned separately from the language, and at that point there's no difference between a well specified and maintained lib (eg lodash) and a stdlib.

[karmajunkie]

>> Don't write it unless you intend to own it. > The flip side of that is that if you do want to own it, writing it in-house may well be a better option.

An unspecified question is "What is the cost of ownership?" (which you alluded to in discussing the size of the project.) I've written plenty of code that could have been replaced by a library. I've put out OSS projects that I actively discourage people from using because the function of the library was so straightforward that its just not worth the dependency (even if its my own, completely flawless code ;) ) Moreover, in most of these cases the code churn even over several years is almost zero. That's a metric that should be looked at a lot more often when evaluating dependencies.

To your point, the cost of ownership is completely negligible in most cases, and all developers are doing by including a new dependency is saving a small amount of time up front with a heavy backside cost.

[brian-armstrong]

Not all open source is the same. The language you use might come with an open source standard library which is likely very high quality. On the other hand, piping in a few dozen packages from github or npm does not come with the same sort of quality, and here the "crowd" could actually just be a single developer

[slavik81]

It's much easier to implement something for your application than something for a library. You have a specific problem in a specific context, but the open source library must solve a general problem in thousands of contexts.

[jkkramer]

As programmers, we suffer from various maladies. NIH is one, laziness and shiny-chasing are others. As in life, balance is needed. Don't forget the cost part of cost/benefit analysis.

[leepowers]

This is very true for a wide range of applications and projects and is definitely required in many contexts (for instance - don't roll your own crypto). But for simpler components, such as a router, it may preferable to write a small focused class instead of creating a new dependency.

[hinkley]

I would agree with this except that I know that 95% of everybody is laughably awful at tasks as simple as reliably parsing or constructing a URL.

The class of difficult problems that you rightfully include crypto into is a lot wider than people want to admit to themselves. Hell most people and a number of programming languages I have worked with can't fathom the idea that other spoken languages might put words in a different order than your native language uses.

[Chris_Newton]

You make a reasonable point, but can the current join-the-dots culture of software development and having fewer “developers” who can actually perform basic development tasks themselves really be entirely unrelated?

[hinkley]

It's the "smart" ones who are the worst, unfortunately.

But I think there space for both the cut and paste crowd and the deep knowledge folks. In most industries the tool makers are separate from the users. The latter aren't worthless or subhuman because they don't do the former.

In most industries there's a place for fast people and there's a place for perfectionists. Tooling is not a volume business but needs a very low failure rate and good support.

We just haven't sorted ourselves into camps yet, but I think the era of stackoverflow is the beginning of that process.

[Chris_Newton]

In most industries the tool makers are separate from the users.

True, but I’m not sure software development is one of those industries.

Someone who makes pencils is not necessarily an artist, and vice versa. They require different skills and have different goals.

But where do someone who draws with those pencils, someone who makes colour-by-numbers books, and someone who uses the pencils to fill in those colour-by-numbers books fit into this analogy?

[douchescript]

Yes, but if my version only has the features I need. Then it's lighter and most probably faster. Since OS tends to support a smorgasbord of usecases it's more often than not bloated and unnecessarily complex when used.

[SwellJoe]

NIH is also kinda what leads to the proliferation of so many very similar, but slightly different, modules in npm. everybody thinks they can solve X problem better than the previous dozen people who solved it. Maybe it's driven by ego, maybe a sincere belief that their new way is better enough to justify a whole new project (and the division of talent available for solving that problem), etc.

There used to be a feeling in OSS that forking was a solution of last resort. Now, with the process of writing software becoming much more focused on micro-libraries (and the tools for using those micro-libs getting better enough to make it not so painful), the barrier to entry on writing a new library to solve a specific problem is often very low. Routing is not a huge problem. A single developer with some experience can build a reasonably complete one in a week. So...here we are. There's, what, a dozen popular routers? All mostly the same. Maybe one or two use promises, and maybe that seems much more modern, so they get some uptake. But, with one developer behind them, and maybe a couple of occasional other contributors, you have little feedback pushing for stability. The same desire that led to wanting to write a new router (to use the latest technology and ideas) is the same desire that leads to breaking changes.

I'm feeling particularly overwhelmed by the size and...um...inconsistency in quality, of the npm ecosystem. I really have very little of the NIH drive. I'm perfectly happy to put together Lego projects from off-the-shelf components, when possible (my business partner brings enough NIH to the table for both of us). But, I barely know where to start in node. NIH seems to have been elevated to a religion.

[brian-armstrong]

There's a big difference between acting on NIH for your own project, and acting on it and then publishing it. It takes a considerable amount of work to prepare code for general use. On the other hand, if it's used in a specific way within one codebase, that may actually make much more sense than reaching for a library that is designed to do that one thing and a dozen others.