Architecture & DesignOvercoming "Not Invented Here" Syndrome

Overcoming “Not Invented Here” Syndrome

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

Contagious NIHS

It is very easy for NIHS to spread through a development community, especially when the lead developer on a project is “infected”. Because of what seems to be an inbuilt tendency to prefer new development over assimilation, it is not hard to convince other developers that no suitable alternative exists, and that component X simply must be created from scratch. There may even be financial incentives involved: a programmer paid by the hour, for example, might well prefer to do a certain amount of wheel-reinventing. A developer whose interests are properly aligned with the business goals of the company, however, is likely to look for the overall best solution, taking time, cost, quality, maintainability, and other factors into account.

Overcoming NIHS in Others: Immunization

You would think, logically, that the open-source developer community would exhibit a fairly high level of immunity from NIHS. After all, the amount of existing software in open source is vast, and growing by the day. Nearly every kind of application you can imagine is available out there under a suitable open source license. Not all of them, of course, are ready for prime-time, but many are, and again the cost to take something that’s nearly there and finish it off must be weighed against the cost of beginning again in each case.

Even open-source developers, though, don’t always know that what they’re creating has already been done, and even if they do know, many things can prevent them from using an existing solution other than NIHS itself. A surefire way to diagnose NIHS is to go through these other causes and eliminate them, one by one. If none of them apply, then it is likely you are looking at a bona-fide case of NIHS! Principal among these causes are:

  • No suitable existing solution can be found, not even one which may be adaptable.
  • A close-to-suitable solution is found, but solving 90% of the problem is not sufficient. In this situation, if the “90%” solution is open source, it may be possible to extend or customize it to fulfill 100% of the specification. If it is not (and the vendor is either unwilling or unable to customize at a reasonable cost), then the potential solution is rejected.
  • A suitable solution exists, but is distributed under a license that is not appropriate for the intended use. (This is in fact how many open source projects get their start!)
  • A suitable or close-to-suitable solution is found, but it is either not designed as a component nor for re-use. In this situation, the work to make the component available for re-use might be more than the work to reproduce it entirely.
  • A suitable solution is found, but one that is not compatible with existing development standards or chosen programming language(s). The wide availability of open source solutions in some languages make this less of a problem for some languages than it is for others.

The key to immunization from NIHS is to first be informed, and then to properly analyze available solutions against suitable criteria. Considering custom development as a solution of last resort is the way to ensure that a better path if not being overlooked.

Overdose of the Cure

One final word of caution: although it is far less common than NIHS itself, it is possible to overdue the “cure”, that is, to overdo re-use. There are situations where it is entirely reasonable to use new, custom development. When a better idea comes along compared to existing components, or one of the "real" reasons we discussed in the list above applies, then it’s not NIHS: it’s just a situation where a legitimate need exists for new software. Where the solution is highly critical or based on a proprietary technique, for example, or where existing solutions are known, and competition simply dictates that a better solution can be created, NIHS is not the culprit.

Over-doing re-use at the expense of stifling competition or denying the opportunity to build a truly better mousetrap is never wise. But, if on the other hand you just need to catch the darn mouse, just go get a mousetrap that will do the job!

About the Author

Michael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at mnash@jglobal.com.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories