Not Invented Here

... also known as NIH, or NIH syndrome.

Could somebody please post a clear definition of NotInventedHere?

A company, to establish its position in the industry pecking-order, might ignore Library X, created by an inferior company. The dominant company might then waste internal resources building Library Z'. It has many of the same features as X, and might overlook the features that truly made X superior to Z'. That company might then promote Library Z' as "the One True Library, as invented by The Worlds Greatest Software Company".

Instead of just downloading Library X and getting their job done.

I'm sure we can all think of examples of this activity in progress...

In fairness NIH diagnosis is often confounded by modern patent issues. Often NIH is an existential threat to the existence of a company if the alternatives are owned by competitors. More over if you intend to extend the X above you may find that you do need to re-invent, is it not better to do so up front, instead of bolting on a non-solution. Even if X will eventually dominate attempting to invent X' is an essential component of the free market at work which may in fact help keep X from becoming to entrenched to soon . Would we have Windows if there was no OS2? Was windows a example of Microsoft NIH? What of Mac OS ? Should they give up or does Apples existence help force Microsoft to keep 'innovating'. Please no flame wars about APPLE v MS my point is that NIH is only an Antipatern if your only reason for not adopting it is that you have a staff that needs the work. --MarcGrundfest

I understand the concept of reinvention, but don't understand the connection to NotInventedHere. It has the ring of an idiomatic phrase that nobody knows how it came into existence.

: I always understood it as an oblique reference to the supposition that any code NotInventedHere is not as good as code that I (or we) wrote.

Who hasn't encountered one of those treasured colleagues who, on hearing the phase: "Hey, I've just spent three years working on exactly the same problem, how about we sit down together and talk about integrating our solutions?" (or something vaguely similar) covers his/her ears and starts humming tunelessly to him/her-self.

This is obviously very closely coupled (and we all know how bad tight coupling is!) to the ProgrammersHugeButDelicateEgo? pattern which can also cause a huge waste of time and (albeit "only" the company's) money.

The product of NotInventedHere is ReinventingTheWheel which wheel unfortunately is often square, without spokes, or squeaks like heck.

The pattern can also lead to a paradoxical situation. If the pattern is applied in its strictest sense, it effectively excludes its own use. The NIH pattern has obviously been used many times before by others and may not be re-used. This would actually be of benefit in that it would thereby be self annihilating. Unfortunately, we are all so flexible that the pattern is never so applied and therefore remains dangerous.

-- RobertPhillips

The cure for NotInventedHere is obviously UseSomeoneElses. (a.k.a. SwipedFromTheBestWithPride)

A closely related pattern is TakeItOrLeaveIt, where the producer of an abstraction is responsible for its rejection by a potential customer by blandly stating, "This will solve your problem. Don't bother to reinvent the wheel." -- KentBeck

May I suggest that NotInventedHere has begun to infest the Patterns literature itself? See the PatternOfBabel. -- PeterMerel

Unfortunately, nobody seems to really recognize - and, what's more - appreciate the power and beauty of the NotInventedHere pattern. ;->

If you comply strictly with it, it can do wonderful things for you:

It allows you to spend several months programming a parameter marshaling layer to shield application developers from the difficulties of CORBA.
It justifies spending even more time on writing a general purpose library (containers, strings, etc.) in order to stay independent of third party library vendors.
Providing important software components like these significantly improves your visibility within the organization, your efforts will be rewarded and your name will be praised - though not necessarily by the application developers who have to use your stuff...
It pads your résumé with those critical research & Computer Science topics in such demand in labs without deadlines.

Obviously, the NotInventedHere pattern can lead to ExtremeFrustration.

I do not use this NotInventedHere thing. I choose my own path and never use anyone else's ideas.

That's too bad. IsaacNewton said, "If I have seen farther than others, it is because I have stood on the ShouldersOfGiants."

And he said it in a letter to RobertHooke, one of his greatest scientific rivals. Hooke was a dwarf.

("If I have not seen as far as others, it is because giants were standing on my shoulders", as seen on Usenet.)

I think you could well describe the company that I work for as a WheelFactory; we've spent the last 10 years writing our own versions of things that already exist. Our stated reason for doing so is that the standard thing isn't quite what we want, or it has some bugs. But then we go and write our own thing that has different bugs and different limitations, except that in addition to it being crappy, it sucks away our own development time as we are forced to maintain it.

But that's not news; every WheelFactory does that.

The really weird thing is that within the product team individual developers will write a module that someone else already wrote. This is done with little apology, and no-one talks about it. (I've even done it myself.)

I think this happens because developers are afraid to learn how to use someone else's module. They fear that they might not be able to figure it out, and so instead of trying they just dismiss the past work ("That's cryptic crap! My thing will be much better!") and start again in the name of ReFactoring or ReWriting. But then it's not better, and if they'd taken the time to understand the thing they were replacing, maybe they wouldn't have decided that it needed replacing in the first place. But they won't evaluate the results of their work unfavorably, because it's their work and they at least understand it better than what someone else wrote.

This is an example of NotInventedByMe, a fairly large (almost complete) subset of NotInventedHere.

How do you distinguish between when a module is being rewritten and when it's being reinvented?

-- RusHeywood

A rewritten module

Passes all the same unit tests and then some.
Is a demonstrably better solution to the problem addressed by the original (substitute your value for 'better' here). No, it doesn't count if the problem is "I can't understand the interface to this/it's not written the way I'd write it/It doesn't make very good coffee".
Makes the developer of the original module go "Ooooo, why didn't I think of that?"
Has fewer lines.

A reinvented module

Has different (but maybe fewer) bugs.
Behaves differently (but NOT more correctly) with boundary cases.
Had code that does things differently for stylistic reasons rather than function. Compare various versions of strcpy() with K&R strcpy().
May support some lame excuse to have more lines.

-- StevenNewton

Re: "it doesn't count if the problem is 'I can't understand the interface to this'": it does count if the problem is 'Nobody working here understands the interface to this,' or (even worse) 'The interface to this is so bad that writing to it takes more time than reinventing it.' Reinventing tri-cornered wheels is generally a good thing.

"Not invented here" can mean not originally designed for the use to which you would now have me bend it. Or not designed with our problem domain in mind. Or their square peg not wanted on our round hole project.

In this situation, though, the term "Not invented here" doesn't really apply, as there are two distinct inventions, not one invention recreated independently by two inventors.

One possible defense of NotInventedHere practices is this: sometimes the knowledge of how to write the code is more valuable than the code itself (or its results). In that case, writing the code from scratch is the surest way to formulate and test your knowledge of how to write the code. -- EdwardKiser

So then it appears that many developers do not like to write about their design and code ideas in PlainEnglish (for fear of what?), but they like to rewrite their ideas about an already implemented system in code, and apparently for the same reason that one might write in PlainEnglish (to find out what one thinks). What does this mean? -- WaldenMathews

Few programmers know how to refactor their code. Without refactoring, you don't have the ability to put new knowledge into an already implemented system.

Most programmers would rather write programs than write about programs. Expressing ideas in code rather than in PlainEnglish has many benefits, including formality and the ability to run and test the code and compare it to the other implementation. -- KrisJohnson

I have often intentionally reinvented other people's modules. It's one of several critical evaluation strategies that I use to determine whether a module really performs as advertised (in some cases, the reinvented module can be used to regression-test the original module). While I familiarize myself with the existing module, I develop a parallel implementation with an emphasis on the exact tasks I require the module to perform. Sometimes, the parallel implementation never leaves my brain, but it nonetheless exists. The total time spent in this fashion ranges from minutes to hours, but never more than one work day: after at most one day, one of the following should occur:

The replacement module under development gets sufficiently near completion that it turns out to be better (whatever "better" happens to mean in the specific situation). This tends to happen only in trivial cases, but this case is often useful to illustrate to non-technical people (managers mostly) who have been begun to believe some of the more outrageous lies told by people who sell code modules. If it takes an hour to rewrite (and test, and demonstrate) the code, it's probably not worth $500, let alone $50,000; if we'd have to rewrite our software license to use it, then somebody had better be paying us to even look at it.
The replacement module project heads toward some kind of disaster (Hey, this is harder than it looks!), and it is quickly abandoned. Interestingly enough, this case does not always result in choosing the existing module that the replacement is supposed to replace - sometimes, it becomes obvious that anything like this module must be avoided at all costs.

I often work with the special case of security software, where it is necessary to prove to my peers that the code implements some security policy. In that environment, if I used someone else's code, I'd have to read and completely understand (and defend!) the entire code anyway, so using other people's code doesn't actually save a whole lot of effort. -- ZygoBlaxell

Nearly all FreeSoftware is NotInventedHere software. NonFreeSoftware? vendors have been going out of their way to develop replacements for FreeSoftware for years. Sometimes economics and politics override technical issues and even common sense.

At a previous job, NIH meant "Let's implement our own TCP/IP protocol stack in our embedded system because... uhhhh... we have strict memory limitations and... uh... we don't want any extraneous code from the Berklee sockets library eating it up". Translation: This looks cool. Rather than build on it, lets dissect and reinvent it so we don't have to idolize the original inventors. :-) -- MichaelLeach

Re examples, what did Intel do with the Alpha chip that they bought from Compaq?

Remember the Knights Who Say... 'Ni'! in MontyPython and the HolyGrail? I just have to share this vision I just had of CowOrkers running around in strange costumes saying, muttering or sometimes shouting NIH!

I found this fabulous quotation by someone who obviously had the same idea: "Bravely reimplemented by the knights who say 'NIH'."

I was brought in on a project around December 2001 at the behest of a large consulting conglomerate (they're having legal troubles now - hint, hint, wink, wink). My duty was to implement, in VisualBasic 6, a COM component that interfaced with FileNet for use by their ASP developers; they, of course, were in a different group. The excruciatingly painful part of this project was that the IvoryTowerArchitect? was flown in and insisted that all COM objects must accept and return a single String - of XML. Never mind that I was wrapping an already existing COM object model - FileNET - that, quite frankly, wasn't that bad to begin with. No, on top of this stupidity, I was going to wrap the wrapper in an XML interface because, to quote their oh-so-great architect, "This is the way the industry is going. XML will provide complete flexibility."

I tried to explain to them that their ASP developers: a) understood COM and could use it quite easily, b) didn't really understand XML or XSLT. They didn't hear me. In the end, I wrote the entire ASP application that interfaced to my wrapper of a wrapper because the ASP developers they'd hired couldn't cope.

This was a blatant instance of NotInventedHere, but for different reasons. Because this consulting company was billing their client millions of dollars, they had to justify their existence somehow. The project would have been 60% shorter, 100% easier, and required 50% less staff if we'd have just used what was provided by FileNET (and Siebel, and a host of other off the shelf packages).

There are two cases where NotInventedHere isn't a problem:

What you're trying to use simply does not do what you need and you can't find a suitable, already developed, alternative.
What you're developing simply doesn't exist yet.

Without exception, however, people seem to use the more common reason: To look busy. What a shame ethics is a lost concept. -- JeffPanici

There are plenty of connections drawn between NotInventedHere and ReinventingTheWheel, but one does not necessarily follow from the other. NotInventedHere could just as easily lead to the selection of an inferior but already implemented solution just because it came from this tribe. ReinventingTheWheel always involves the decision to implement (again). You can reinvent the wheel for reasons having nothing to do with tribalism, and you can reject a foreign contribution without deciding to directly implement an alternative. NIH is pure rejection, purely politically motivated. RTW can be a private choice to experience implementation firsthand for the learning experience. NIH is the worser, in my view. -- WaldenMathews

I think ReinventingTheWheel has as negative a connotation as NotInventedHere. I hear it used when someone is recreating something because they are unaware of the existence of the thing, or due to a (probably mistaken) belief that they can do better than all the other wheel makers. NIH refers to tribalism and possessiveness, whereas RTW refers to ignorance and arrogance. I don't hear the term RTW used when there are good reasons to create a similar-but-better thing; it is always used as a criticism. -- KrisJohnson

In Defense of NotInventedHere

You control the API and the implementation.
Your version might have unit tests and might be more reliable.
You will be able to iterate and evolve the system over time to meet changing requirements.
The existing implementation might be in a different language or on another platform.
You only need 1% of the functionality provided by the commercial library.
You plan to introduce a competing product to the library.

-- AsimJalis

Further defense:

The origional may be so badly documented that it's easier to write a new version than to learn the existing version

-- AndyC

Then you should always use OpenSource instead of ReinventingTheWheel.

-- GuillermoSchwarz

I think you may be missing the point...it's all about parochialism, aka "us-and-them-ism" and was (maybe still is) best exemplified by hardware/software manufacturers who typically used this phrase to justify using their own products in-house, no matter how inferior to a competitors...

-- Matt Bennett (abstract@webone.com.au)

It strikes me that these are defenses of ReinventingTheWheel, rather than defenses of NotInventedHere. In that spirit, I'm a bit surprised not to have encountered "licensing issues" on these lists of defenses... For example, in commercial development, I am extremely careful about the ways in which I might build GPL'ed code into our systems, and would usually rather ReinventingTheWheel than integrate ViralLicense? OpenSource.

-- AidanCully?

Oh dear. It's sad that as of 2010, there are still code shops and developers that believe in keeping source code secret and would increase certain project risks to maintain secrecy.

The valuable asset is never the source code itself, but the expertise that surrounds it.

My ex, an IBM Systems programmer on the '81 PC Team, used this term all the time to repeat management. (they thought it was a good thing.) I'm sure Gates agrees. -- Chris Belcher

See OldCodeRusts.

In my experience, NotInventedHere often means 'I refuse to take responsibility for the decision to use something I don't completely understand and which I might get blamed for later if it fails.' In other words, it's a way to PassTheBuck?.

PassTheBuck?? It sounds like the reasoning you're describing is, "If I am going to take responsibility for this decision, I am not going to make a decision I believe may be overly risky or wrong.". That's not evading responsibility, that's taking it.

To the derogatory comments about tribalism on this page: to quote myself, "It's easy to be dogmatic when you're right and everyone else is an idiot." Some tribes are at least partially justified in building things from scratch, considering that they have had success in the past with their own code and failure in the past with third-party components. This may lead them to make the wrong decisions about projects with circumstances different from the ones they're used to, but it's not an entirely ignorant or bigoted decision, it's just their best guess.

In my experience the real tribes are the WeShouldBuildIt? tribe and the WeShouldBuyIt? tribe. Depending on the organization and the context of a project, one is right and the other is wrong, but that doesn't matter: they always say the same thing. If the project succeeds, whichever tribe won control early on will laud the victory and claim it is an example that their view is always right. If the project fails, the other tribe will pooh-pooh the failure and demonstrate how it failed just like all projects that did not do it their way. However, learning rarely happens and almost always, the same people will be saying the same things in the next project, regardless of the outcome.

Come to think of it, that's probably a more general antipattern, reminiscent of PixieDust, but "NotInventedHere" is a catch-phrase that I have heard associated with it quite a lot.

-- GlyphLefkowitz, re-inventor of several wheels and future inventor of the Fusorama home fusion-energy appliance

What I've learned so far:

The vendor relationships, support availability and responsiveness are at least as important as the product itself and often far more.
Nearly all complex integrations will require an enhancement or fix from the vendor, or a workaround.
avoid ThirdParty non-open-source solutions: we can never figure out what they're really doing
building it ourselves is will take us further than we might expect
do not to let ThirdParty classes and interfaces permeate the code.
- Keep them confined to one package and hopefully only a few classes.
- Wrap them in a pluggable interface, at least.
our future needs really aren't what we expect
switching from one solution to another is very expensive regardless
we never have this discussion when there's an obviously superior answer

The most obvious examples I've worked with have been O-R database mapping tools, functional testing frameworks, and Web application presentation layers. It's really tough.

Any framework that I could buy (or obtain as FreeSoftware) usually is designed to solve much bigger problems that what I have. In order to address our simple needs today, the development team may have to learn a complex product which isn't tuned for solving the simple problems.

On the other hand, if we build it ourselves, it is easy today, but in the future we can easily imagine it growing in weight and complexity until it is every bit as hard to wrap one's brain around as the ThirdParty solution, and maybe isn't as good because it was built by people who are not experts in that domain.

It is in these BuildOrBuy discussions that I feel we are most confronted with BigDesignUpFront. Because the cost of changing usually is very high, we are inclined to avoid our best practices and design for the future. We should notice that we're doing this, and do our best to keep the code extra clean around ThirdParty software in order to hopefully keep the cost of switching down. Unfortunately, it isn't always easy to see where we've become tightly bound to the solution or how to keep our integration with that solution flexible. Often, it isn't until we're really suffering and want to switch to something else that we see where we've gone astray.

-- EricHerman

This is an interesting discussion. I think AppleComputer designs their APIs in a way that aids these type of BuildOrBuy decisions. They usually have both a "basic" and a "complete" API surrounding a particular technology. The Basic API is designed to be easy to use, so you can make a quick prototype and meet the common-case requirements. This API wraps the Complete API, which exposes all the available options and techniques for using the technology. The particular example I have in mind is the QuickTime movie API. The Basic movie API allows one to create a basic movie player in a half dozen screenfuls of code, using calls that take few parameters. The Complete API then exposes alternate transport mechanisms, large structures full of options, fine control over event handling, etc. Other library vendors would do well to follow this multi-tier API model.

other wikis: http://en.wikipedia.org/wiki/Not_Invented_Here

CategoryAntiPattern JobSecurity CategoryMetaphor CategoryDevelopmentAntiPattern