
Not invented here, revisited - jstanier
http://theengineeringmanager.com/growth/not-invented-here-revisited/
======
turbinerneiter
From my personal experience, NIH corresponds to the need to DIY to proper
understand. I often feel like I can't decide between options unless I at least
built a super-basic, minimal version of the functionality. The other aspect is
this idea of mine that technology is ready for primetime as soon as it can be
easily reproduced. People in our field have a sense of elegance - like every
problem becomes trivial once you find the best abstraction. And there is this
"do one thing an do it right" idea.

How many bugs do fix by removing complexity that is unnecessary for your
special case?

------
yen223
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
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.

~~~
yen223
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
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
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.

------
ivan_ah
IMHO, the only valid reason for "roll your own" is if the application needs
50x+ performance than what would be possible using existing solutions (as is
the case described in this blog post). Otherwise follow the rules:

The three rules of software development:

1\. Don't write code as there is a library that already does exactly what you
want to do

2\. Don't write code because you can combine several libraries to do what you
want to do

3\. Don't write code because there is some mega-framework, one subset of which
does what you want to do

------
buchanae
> NIH highlights situations where engineers side with reinventing the wheel
> due to a belief that building technology in-house will be better, quicker
> and cheaper than using an existing solution

In my experience, it's more like "due to an uncontrollable urge that building
technology in-house will be more fun, more interesting, more pleasing than
using an existing solution" :)

...not that I'm completely innocent in this respect.

~~~
doctorpangloss
> due to an uncontrollable urge that building technology in-house will be more
> fun, more interesting, more pleasing than using an existing solution

Indeed, retention is valuable.

------
mathattack
To explain the bias around NIH, I use the D and D analogy of “pursued by
people longer on intelligence than wisdom”

------
jimjimjim
so, why do people make their own children rather than look for orphans first?

~~~
jazoom
Probably similar reason for NIH syndrome. It's theirs, they made it and they
have a reasonable idea how it's going to function. Also, if it breaks, they
have no one to blame but themselves.

------
carapace
"Somebody else has had this problem."

------
cm2012
As a marketing consultant, my biggest advice to clients is to never, ever
build anything custom. Use Zapier to connect things, Segment to manage data
flow, Shopify/Weebly to build the site, use Sumo to test site changes, etc.
Building things custom just delays projects so much, especially in marketing
where you don't even know if a project will achieve the goals you want.

