What is it?
"Not Invented Here Syndrome" is a slightly tongue-in-cheek name for the tendency of both individual developers and entire organizations to reject suitable external solutions to software development problems in favor of internally-developed solutions. Closely related to the "let's re-invent the wheel" syndrome, NIHS can be seen in intensities ranging from a mild reluctance to accept new ideas all the way up to a raging software xenophobia. NIHS can be defined as a situation where an external solution is rejected only because it was not internally developed - in other words, there are no other factors that dictate an internally developed solution would be superior.
Origins of the Syndrome
Most people naturally find it more enjoyable to speak than to listen. The same is true in software development. Most developers would rather be known as the hero who developed the UI framework that the whole company now relies on than simply the guy who made the suggestion to use Tapestry, for instance. Reading code is never quite as satisfying as writing it.
If we're honest with ourselves, most of us find it at least a little bit hard to admit that the other guy had better idea than we did, or did a better job (or at least as good a job) implementing it than we could have done.
There is also a certain amount of "herd instinct" driving NIHS in some organizations. If it has been the practice of the organization to develop all new software internally, it may be easier to go with the flow rather than introduce the relatively radical idea of bringing in all or, worse, part of a new package from "outside". Many companies in the software industry fall prey to this cause of the syndrome. They have in-house development resources, they reason, why should they not utilize them, instead of trusting important development work to others?
The existence of legacy applications or libraries can also create an ideal breeding-ground for NIHS. "Our internal developers have laboured for years developing this massive library suite with functions and methods for everything from the kitchen sink on up, then we're darn well going to use it!" Never mind that a superior version of the same functionality is now built into every standard Java runtime being shipped, for example, or that a better version can be downloaded for free from apache.com - this is "ours". Just like developers who practice refactoring can find it hard to throw code away in favor of a better approach, organizations can find it much harder, even in situations where the ongoing maintenance of the obsolete behemoth becomes an albatross around the neck of the company. While externally this attitude seems unreasonable, it is very often simply accepted as the way things are done in some organizations.
Even organizations or developers with an open mind to using external software may simply be unaware that what they need is already available, often for free (at least free in the sense of not requiring licensing costs).
Open source projects in particular often suffer from a lack of exposure, so a developer may have made an effort to find an existing component for a given project, only to come away convinced that what is required simply doesn't exist, leaving the developer feeling quite justified in creating it from scratch. This is not so much NIHS as it is simple lack of information, and many resources today exist to help overcome this lack - sites such as Freshmeat and Sourceforge, for example, that list and index many thousands of available free and open-source software packages, not to mention indices of commercial software.
Symptoms of NIHS
The primary symptom of NIHS is a rash of re-inventing wheels. Secondary symptoms, though, include large amounts of wasted time and money, along with the corresponding loss of opportunity. Developers who are busy chipping stone into a round shape are not available for other functions, such as implementing better security, optional but desirable features, and documentation. This opportunity cost alone often reaches significant amounts, but is seldom taken into account.
NIHS is often found in organizations where no experience exists with component-oriented development, and where re-use is not regularly practiced. Once the benefits of re-use and components are grasped - particularly by project leads and other decision makers - it is hard for NIHS to get a serious hold. The tendency then becomes to look first for an existing solution, and only reluctantly create something internally once thoroughly convinced that no existing solution exists that can be easily re-used or adapted.
Developer, Cure Thyself!
As with other ailments, the first step in curing NIHS in ourselves is to admit there is a problem. Some organizations and individual developers seem quite content to re-invent the wheel over and over, congratulating themselves on their innovation at the same time.
Becoming more aware of what is already available, however, cannot help but shake our belief that "if you want it done right, do it yourself." Many developers, too, take too much of a perfectionist attitude when considering components for re-use. They look at the available alternatives, and dismiss them for various minor faults. "The doc is not adequate", or "it's not an efficient algorithm", we might hear. The faults may be quite real - but are they truly significant enough to justify starting from scratch? A developer must, of course, take a careful and considered look at components being considered for re-use - but if they do 90% of the job, is it really more effective to re-invent that 90%, plus the remaining 10, or would it make sense to contribute the final 10% to the existing component? Would it be as much fun? No, almost certainly not. Would it be more efficient and cost effective? Quite likely yes.
IE 7
Firefox 2.0
