4 ms·

Is there a name for the opposite of NIH syndrome, where programmers only use external libraries and frameworks, and are totally allergic to the notion of writin

by yen223 8y ago

Is there a name for the opposite of NIH syndrome, where programmers only use external libraries and frameworks, and are totally allergic to the notion of writing in-house code?

dbkaplun 8y ago
For me, reusing widely used code that's heavily tested is preferable to the liability of handwritten code. If I'm given the opportunity, when possible, I'm going to choose the former.
- alexandercrohde 8y ago
  I suppose nobody really invents anything in-house in one sense. You reuse the hardware, the OS, the drivers, the network, cloud storage, IDE, source-control, JIRA, a programming language, several libraries, databases, at least one framework, and on top of all that you may have some sprinkles that are "your application." I think the question is always, how smart an engineer can you be to reuse the maximal amount possible to deliver a good experience quickly.
  - deleted 8y ago
    [deleted]
- cle 8y ago
  It needs to be a deliberate decision based on use cases. Depending on your business, it may be more valuable not to relinquish control of important functionality to third parties.
- yen223 8y ago
  That's a good default to start with, but that's not the whole story. Every system has its own sets of constraints, and its own sets of goals. Those constraints and goals don't necessarily align with the assumptions made in the library you're using, because it's rare to have a library that does precisely what you need. When you can't find a library that meets your needs, you have two choices: 1) roll your own solution, or 2) find a library that does something similar to what you want, and coerce the library into a form that suits your needs. Neither are pleasant options, but I find #1 tends to give a better outcome in the long run. You know what your system constraints are, so you're in a better position to design around them.
  - jamra 8y ago
    I feel like the problem comes down to people not willing to read the docs. Reading the freaking manual helps understand if your tools are precise enough or configurable to solve your problems. Then reading the source code (if possible). Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.
    - Risord 8y ago
      On the other hand time required to read and _understand_ the source can be often very compareable to writing specific solution to your problem. Which all comes down to one biggest bottle neck of our industry: sharing understanding of solutions.
  - ng12 8y ago
    In theory, you're absolutely right. In practice, this is the argument used to defend egregious NIH syndrome.
    - sanderjd 8y ago
      And this is the argument used to defend the opposite. Personally, I've found egregious NIH more pleasant to work with than dogmatic anti-NIH.
Tade0 8y ago
If you say "leftpadding" then I'm sure that at least the front-end community will understand. Or perhaps not, because there's a chance people already forgot about the left-pad incident.
- jimjimjim 8y ago
  leftpadding. i like it. it sums up the trash heap that is node_modules.
gok 8y ago
I call that dependency-oriented-program-engineering (DOPE)
olooney 8y ago
“Slave is an Ephebian word. In Om we have no word for slave,” said Vorbis. “So I understand,” said the Tyrant. “I imagine that fish have no word for water.” Terry Pratchett
- tylerhou 8y ago
  I understand the point you’re getting at, but humans have a word for air? If fish really did have language, they would at least have a word for air, which would mean that they would also probably have a word for not-air: i.e water.
andrepd 8y ago
From Wikipedia >The opposite predisposition is sometimes called "proudly found elsewhere" (PFE) or "invented elsewhere".
megaman22 8y ago
Never Invented Here. Or maybe duct-tape programming.
c3534l 8y ago
I've heard HackerNews call it Never Invented Here.
fanf2 8y ago
If it’s commercial software, then BTF = bought the farm

by yen223 8y ago

Is there a name for the opposite of NIH syndrome, where programmers only use external libraries and frameworks, and are totally allergic to the notion of writing in-house code?

dbkaplun 8y ago

For me, reusing widely used code that's heavily tested is preferable to the liability of handwritten code. If I'm given the opportunity, when possible, I'm going to choose the former.

alexandercrohde 8y ago
I suppose nobody really invents anything in-house in one sense. You reuse the hardware, the OS, the drivers, the network, cloud storage, IDE, source-control, JIRA, a programming language, several libraries, databases, at least one framework, and on top of all that you may have some sprinkles that are "your application." I think the question is always, how smart an engineer can you be to reuse the maximal amount possible to deliver a good experience quickly.
- deleted 8y ago
  [deleted]
cle 8y ago
It needs to be a deliberate decision based on use cases. Depending on your business, it may be more valuable not to relinquish control of important functionality to third parties.
yen223 8y ago
That's a good default to start with, but that's not the whole story. Every system has its own sets of constraints, and its own sets of goals. Those constraints and goals don't necessarily align with the assumptions made in the library you're using, because it's rare to have a library that does precisely what you need. When you can't find a library that meets your needs, you have two choices: 1) roll your own solution, or 2) find a library that does something similar to what you want, and coerce the library into a form that suits your needs. Neither are pleasant options, but I find #1 tends to give a better outcome in the long run. You know what your system constraints are, so you're in a better position to design around them.
- jamra 8y ago
  I feel like the problem comes down to people not willing to read the docs. Reading the freaking manual helps understand if your tools are precise enough or configurable to solve your problems. Then reading the source code (if possible). Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.
  - Risord 8y ago
    On the other hand time required to read and _understand_ the source can be often very compareable to writing specific solution to your problem. Which all comes down to one biggest bottle neck of our industry: sharing understanding of solutions.
- ng12 8y ago
  In theory, you're absolutely right. In practice, this is the argument used to defend egregious NIH syndrome.
  - sanderjd 8y ago
    And this is the argument used to defend the opposite. Personally, I've found egregious NIH more pleasant to work with than dogmatic anti-NIH.

Tade0 8y ago

If you say "leftpadding" then I'm sure that at least the front-end community will understand. Or perhaps not, because there's a chance people already forgot about the left-pad incident.

jimjimjim 8y ago
leftpadding. i like it. it sums up the trash heap that is node_modules.

gok 8y ago

I call that dependency-oriented-program-engineering (DOPE)

olooney 8y ago

“Slave is an Ephebian word. In Om we have no word for slave,” said Vorbis. “So I understand,” said the Tyrant. “I imagine that fish have no word for water.” Terry Pratchett

tylerhou 8y ago
I understand the point you’re getting at, but humans have a word for air? If fish really did have language, they would at least have a word for air, which would mean that they would also probably have a word for not-air: i.e water.

andrepd 8y ago

From Wikipedia >The opposite predisposition is sometimes called "proudly found elsewhere" (PFE) or "invented elsewhere".

megaman22 8y ago

Never Invented Here. Or maybe duct-tape programming.

c3534l 8y ago

I've heard HackerNews call it Never Invented Here.

fanf2 8y ago

If it’s commercial software, then BTF = bought the farm