
Ask HN: Opposite of not invented here? - mmsimanga
I am familiar with the [not invented here syndrome](https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Not_invented_here) because I get to see it at play quite often. It is my nature to understand an environment before I start making changes but sometimes this analysis phase goes on too long. Here are the reasons I can think of to explain my reluctance to start coding:<p>- I don&#x27;t want to add more technical debt on top of existing technical debt<p>- I am not keen to maintain code and have to answer questions from every Tom, Dick and Harry<p>- I think there is a smarter solution so I spend time writing half solutions then stopping halfway after realizing my solution will have shortcomings<p>Does anyone regularly go through these motions, if yes how do you overcome them? I realize there probably different ways to describe these emotions including procrastination, fear of failure but I genuinely love simple elegant solutions and when I feel there too making weak points in a system I get reluctant to jump in.<p>[Edit] formatting
======
blt
> _I am not keen to maintain code and have to answer questions from every Tom,
> Dick and Harry_

This seems like the wrong attitude. Software development is about writing and
maintaining code. If you need to solve a problem that is not cleanly solved by
an existing library, it's your job to write the code, maintain it, and help
your co-workers use it.

Remember, the people who wrote those open-source libraries are humans like
you. They had enough confidence and experience to feel comfortable releasing
their work to the world, but they are not super-geniuses. You can confirm this
by looking at the source code of a typical open-source library :).

Personally, I prefer to avoid third-party libraries that impose a lot of
structure on my code. My ideal third-party library is one that implements a
single, complicated function (or family of functions), like solving a linear
system of equations. In these cases using the library is an obvious choice. In
cases where the library (framework) forces you to change the architecture of
your application, you should think deeply about whether or not it's worth it.

I guess the overall message is: take ownership of your work.

------
rubiquity
In large enterprises you see the opposite of NIH. There isn't a name for it
but it's something to the tune of "You never get fired for choosing IBM."

I remember constantly fighting for the right to develop the important software
in-house rather than trying to cram them into a Salesforce app or buy some
[x]-as-a-Service that does 60% of what you need and gives you 0% competitive
advantage or intellectual property.

There's reasons for both approaches but you should never be too far in either
direction.

~~~
dasmoth
For the organisational form, I've heard "never invent here."

~~~
endophage
Wikipedia says "proudly found elsewhere" or "invented elsewhere" are commonly
used. I've heard the latter one before.

[https://en.wikipedia.org/wiki/Not_invented_here](https://en.wikipedia.org/wiki/Not_invented_here)

~~~
dasmoth
Neither of those are quite strong enough, I think. Some organisations have a
great reluctance to build anything new even when there's a clear need. Hence
_never_ invent.

------
romanhn
As pointed out in another comment, analysis paralysis is the term you're
looking for here. One strategy to get past it is to timebox the analysis
phase. For instance, give yourself two days (or however long is reasonable) to
spend on research, but no more. At the end of the two days your should either
have a clear answer or you will have run out of time and need to make a
decision based on imperfect information. Realize that information is always
imperfect and most times the options won't impact the end result in very
different ways (otherwise the answer would've been clear), so there's a lot of
benefit to just getting started. Decisions can be reversed as well, so nothing
is final.

"A good plan violently executed now is better than a perfect plan executed
next week." \- George S. Patton

~~~
Mz
_" A good plan violently executed now is better than a perfect plan executed
next week." \- George S. Patton_

Thank you. I had never heard this. My ex was career military and he always
said "Sometimes, a ninety percent solution now is better than a one hundred
percent solution later." That appears to be what filtered down into military
culture from Patton's remark. (FWIW: My ex's first duty station was a former
Patton unit.)

For the OP, I will add that I find some of the following rubrics generally
useful:

1) Assign X amount of time for research or thinking on it. Pick a date/ time
when you will decide/execute. When that date/time arrives, you are done
researching/cogitating. It is time to do something.

2) Take a break between thinking/researching and acting. Do your research
before lunch and execute after lunch or do your research late in the day and
execute the follow morning after sleeping on it.

3) Track performance metrics. Get hard data and see if your actual performance
is really as bad as you think it is. Often, very competent or knowledgeable
people have endless criticisms of their own work because they are more aware
of defects or potential defects. Mediocre performers often think they did
better than they did because they are oblivious to how bad it is. The solution
here is objective measures of performance. Humans are tremendously bad at
figuring out how well they are doing based on subjective feelings or opinions.

4) Anything worth doing is worth doing badly. In other words, partial
solutions are better than no solution. Though, to be fair, this is basically
another take on the Patton quote and the military rubric I am familiar with.

Best.

------
valbaca
"premature optimization is the root of all evil"

I think you're conflating NIH with "willing to write code that isn't
absolutely perfect."

I think your paralysis is coming from perfectionism.

We all want to build the Eiffel Tower and Mars rovers, things meant to be
temporary but end up being elegant and lasting for much longer than ever
intended.

None of us want to build things like the Tacoma Bridge, things with inherit
flaws that are disasters.

But in the end, remember, most of what we build are really just kitchen tables
and midrange houses. We should take pride in our work and do our due-
diligence, but in the end, we have to ship code.

~~~
mmsimanga
You comment does strike a cord with me. At the end of the day it is about
shipping code.

~~~
brianwawok
At the end of the day its about solving problems. No one pays a programmer to
"ship code". If that problem is solved by someone elses code, use that
perhaps.

~~~
namenotrequired
My favourite cases are those where that problem is solved by removing code.

~~~
brianwawok
I feel so proud of - line pull requests. Especially if I added a test too.

------
brianm
I am familiar with the idea (and have felt it in the past), but the best
approach I have found for most places (less than 10k engineers on staff) is,
"be very careful that you only invent things that are core to your needs."

The greater internet population will move faster than your internal team, and
your beautiful snowflake will be supplanted with a better OSS option much more
quickly than you expect if it is not a core driver of what you are doing. Your
time and attention will necessarily shift to the core once the non-core is
good enough. Therefore, you are almost always better off contributing to
something external for non-core software rather than reinventing internally.

So, if it is core to what you do then build it yourself and maintain (possibly
shared) control of it. If it is core to what you do but is not
differentiating, open source it and drive to create a real community around it
(so that it is the thing that keeps getting better, and you already use it!)
If it is core and differentiating, then you are talking product strategy and
there is no pat answer :-)

(edit, minor grammar fix)

------
mindcrime
Sounds a little bit like Analysis Paralysis[1], although I'm not sure I'd
exactly call that "the opposite of NIH".

[1]:
[https://en.wikipedia.org/wiki/Analysis_paralysis](https://en.wikipedia.org/wiki/Analysis_paralysis)

------
aristus
The opposite of NIH is Tinker Toy. You just glue existing bits together. This
can work, but usually only on problems that have been solved before, and
therefore have OSS software available.

A good example I experienced personally is data pipeline / job management. Six
years ago there wasn't much out there, and at Facebook they developed
DataSwarm. Today there are many decent OSS choices out there, including
AirBnB's Airflow, Oozie, and Apache NiFi which was developed by the NSA.

------
pjlegato
The opposite of "not invented here syndrome" is "the new shiny."

In this condition, organizations culturally select new tools over older ones
simply because they are new, get a lot of buzz among a certain userbase, and
make extravagant promises of solving major problems with a tiny fraction of
the amount of work that previous solutions required, due to some magical new
technology or insight that the old school way of doing things didn't have.

Of course, in almost all cases "the new shiny" does not actually solve the
problem with less work; it simply shifts the work around some -- frequently by
moving upfront work into technical debt, unmaintainability, and non-
extensibility. The usual net effect is to multiply rather than reduce the
original problem -- but this is deferred into the future, so it's not usually
noticed by "new shiny" enthusiasts and communities for some time.

The canonical example of "the new shiny" is NoSQL, which promised to simplify
the design and scaling problems associated with relational databases. This is
true when your app is tiny, but at any scale and after any amount of time,
both of these problems become much worse. You just don't notice until much
later, because the work has been shifted from upfront work to amortized work.

~~~
mmsimanga
Ah I get where you are coming from. New projects often get more funding and
attention than enhancements to existing software. Is the software I am
developing actually solving the problem (the new shiny in your words) or
adding another maintenance layer.

~~~
pjlegato
Partially. It's also about perceptions. People who are having a problem love
to believe that there is a magic silver bullet solution out there somewhere --
one that will let them have to do a lot less work than the Old Way. It also
makes them feel superior to the ignorant followers of the Old Way.

Install library X or buy app Y and all your problems will magically go away,
and you're awfully clever if you realize this is the case, versus the
unenlightened who continue to do things the Old Way. This is the basis of most
sales and marketing techniques.

------
gwbas1c
Frameworks and 3rd party libraries do not solve problems. Programmers solve
problems.

Understand the problem you're trying to solve. Do you need a complicated
dependency injection framework when establishing a design pattern is a better
choice? Do you need a complicated ORM when a few pages of data-access code is
a better choice?

Remember, 3rd party libraries aren't free: They have bugs, they need to be
updated, they need to pass muster with the lawyer, ect. When you need to
update a 3rd party library, it might cause regressions. Complicated frameworks
can sometimes take a long time to learn to use _correctly._

Another problem that some people explained is that 3rd party libraries can
often force particular design decisions into your product, or require that you
reference them all over your product. If this is the case, make sure to think
carefully about your design patterns and make sure that the library pushes you
towards patterns that are appropriate for what you're building.

Thus, you need to make sure that the 3rd party library is easier / cheaper /
faster than whatever you can write, given the disadvantages that I explained
above.

------
geebee
I've heard the phrase "never invented here" syndrome, but that doesn't seem to
be what you're getting at. That term refers to a kind of disfunction where
people are so terrified to the NIH syndrome that they'll shoehorn into an
existing application, no matter how much contortion is required, simply to
avoid developing their own code base.

~~~
mmsimanga
That is an interesting angle. Part of my problem is that I work in a huge
corporate company that has been around around a while so has quite a number of
legacy systems. I am loathe to introduce new layers of complexity and that
does sound like "never invented here" as you describe it.

~~~
phhlho
I would agree that adding a new layer of complexity is to no one's advantage.
A strangler application that becomes symbiotic with it's host can be a
terrible thing.

I think the key angle to always consider: how will this new thing reduce
overall complexity, now or over time? Maybe it means biting off a smaller
chunk of the problem then you would like to keep the overall system sane. Or
on the flip-side, keeping the new thing under wraps longer and running it in
parallel with so you can thoroughly vet it before attempting to replace it.

And sometimes, you just have to decide that you won't be the person to try to
'repair' an application, particularly an old and stable one. Make the point
change necessary for your need, call it a day and look for better
opportunities elsewhere within the environment.

------
no_protocol
Do the best you can today. If someone has an issue with the result, either
they'll fix it or you'll have the opportunity to fix it yourself.

Live with the shortcomings until you see a demonstrated need to fix them.
Usually by that point, you'll have a better idea of how to get around it as
well. You'll avoid doing extra work early.

~~~
mmsimanga
Thanks for the advice.

------
ajeet_dhaliwal
If your team is filled with not invented here types and you resist that they
make think you're lazy. That's my experience, and I can be lazy but I like to
think it's in a good way.

------
kazinator
Prior related discussion:
[https://news.ycombinator.com/item?id=9112885](https://news.ycombinator.com/item?id=9112885)

