Not Invented Here: history repeating

Hold my beer, I can do it on my own!

NIH (Not Invented Here) syndrome is often considered an opportunity to prove to ourselves that we can do the same thing, but better, faster, nicer, and more secure than the original. According to Wikipedia, we can summarize NIH syndrome as:

Not invented here (NIH) is the tendency to avoid using or buying products, research, standards, or knowledge from external origins. It is usually adopted by social, corporate, or institutional cultures. Research illustrates a strong bias against ideas from the outside.

Sometimes NIH is considered a shortcut of NIHS (Not invented here syndrome).

Buy vs build - the management problems

When deciding to either buy software or build it in-house, staff management must take care to not follow NIH syndrome. While it may not be obvious when looking from the perspective of staff and chief level management, NIHS is quite a big part of the build decision. Developers may want to prove that they can do the job well.

NIHS can lead to not only expensive, time-consuming tasks, but may require managing hidden costs like maintenance. Other hidden risks from build decisions that may show up in the future are Bus Factor and Technical Debt.

Pay vs create - person’s dilemma

Similar to staff+ management decisions problems about what to do (buy vs build), people also often reach a dilemma: pay someone else or do something on their own. That dilemma is not only limited to software development but also to research, standards, or knowledge that others may provide for a price. In software development, this problem is more visible, because programmers love to prove themselves.

The time spent on developing, improving, or maintaining the created software is not usually taken into account when validating the price someone else asks us to pay for getting something ready to use.

Not invented here < reinventing the wheel

The syndrome is often considered an alias for reinventing the wheel. Those two terms differ in many layers. The meaning of the first is threatened in a pejorative sense, while the second is more in an ameliorative sense.

As an example of NIH syndrome: developers create a new internal framework for the company, instead of grabbing the existing and well-tested solution available on the market.

Reinventing the wheel led the PHP community to create the Composer package manager, the JavaScript community created NPM, and later Yarn. A lot of awesome projects started by reinventing some tools from one community into another. The same goes for programming languages which adopt features from different languages to evolve.

Consider reinventing the wheel a positive version of NIH syndrome.

Should I be scared of NIH syndrome?

In the PHP community we usually say:

Every programmer must write, at least once in a life, his/her framework

While the tone is sarcastic, it also highlights an opportunity to learn something new, prove ourselves, and give back knowledge to the community. While being unaware of failing into that syndrome may be dangerous and lead to other problems like low Bus Factor scores and high Technical Debt, being aware of possible problems and issues allows us to follow reinventing the wheel.

Now you know the basics about what NIH syndrome is and how it can affect you, your team, or even the whole company. While it may lead to improving your skills, knowledge, and experience, it may cause you other problems if you’re not careful to avoid its trap.

If you want to learn more about the Bus Factor, check out this article: