October 20, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Overcoming "Not Invented Here" Syndrome

  • April 12, 2004
  • By Michael Nash
  • Send Email »
  • More Articles »

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.



Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel