$4.4 NON-TECHNICAL OBSTACLES 75 The NIH syndrome An often quoted psychological obstacle to reuse is the famous Not Invented Here("NIH") syndrome.Software developers,it is said,are individualists,who prefer to redo everything by themselves rather than rely on someone else's work. This contention (commonly heard in managerial circles)is not borne out by experience.Software developers do not like useless work more than anyone else.When a good,well-publicized and easily accessible reusable solution is available,it gets reused. Consider the typical case of lexical and syntactic analysis.Using parser generators such as the Lex-Yacc combination,it is much easier to produce a parser for a command language or a simple programming language than ifyou must program it from scratch.The result is clear:where such tools are available,competent software developers routinely reuse them.Writing your own tailor-made parser still makes sense in some cases,since the tools mentioned have their limitations.But the developers'reaction is usually to go by default to one of these tools;it is when you want to use a solution not based on the reusable mechanisms that you have to argue for it.This may in fact cause a new syndrome,the reverse of NIH,which we may call HIN(Habit Inhibiting Novelty):a useful but limited reusable solution,so entrenched that it narrows the developers'outlook and stifles innovation,becomes counter-productive.Try to convince some Unix developers to use a parser generator other than Yacc,and you may encounter HIN first-hand. Something which may externally look like NIH does exist,but often it is simply the developers'understandably cautious reaction to new and unknown components.They may fear that bugs or other problems will be more difficult to correct than with a solution over which they have full control.Often such fears are justified by unfortunate earlier attempts at reusing components,especially if they followed from a management mandate to reuse at all costs,not accompanied by proper quality checks.If the new components are of good quality and provide a real service,fears will soon disappear. What this means for the producer of reusable components is that quality is even more important here than for more ordinary forms of software.If the cost of a non-reusable,one- of-a-kind solution is N,the cost R of a solution relying on reusable components is never zero:there is a learning cost,at least the first time;developers may have to bend their software to accommodate the components;and they must write some interfacing software, however small,to call them.So even if the reusability savings r=- and other benefits of reuse are potentially great,you must also convince the candidate reusers that the reusable solution's quality is good enough to justify relinquishing control. See[M1995] This explains why it is a mistake to target a company's reusability policy to the potential reusers (the consumers,that is to say the application developers).Instead you should put the heat on the producers,including people in charge of acquiring external components. to ensure the quality and usefulness of their offering.Preaching reuse to application§4.4 NON-TECHNICAL OBSTACLES 75 The NIH syndrome An often quoted psychological obstacle to reuse is the famous Not Invented Here (“NIH”) syndrome. Software developers, it is said, are individualists, who prefer to redo everything by themselves rather than rely on someone else’s work. This contention (commonly heard in managerial circles) is not borne out by experience. Software developers do not like useless work more than anyone else. When a good, well-publicized and easily accessible reusable solution is available, it gets reused. Consider the typical case of lexical and syntactic analysis. Using parser generators such as the Lex-Yacc combination, it is much easier to produce a parser for a command language or a simple programming language than if you must program it from scratch. The result is clear: where such tools are available, competent software developers routinely reuse them. Writing your own tailor-made parser still makes sense in some cases, since the tools mentioned have their limitations. But the developers’ reaction is usually to go by default to one of these tools; it is when you want to use a solution not based on the reusable mechanisms that you have to argue for it. This may in fact cause a new syndrome, the reverse of NIH, which we may call HIN (Habit Inhibiting Novelty): a useful but limited reusable solution, so entrenched that it narrows the developers’ outlook and stifles innovation, becomes counter-productive. Try to convince some Unix developers to use a parser generator other than Yacc, and you may encounter HIN first-hand. Something which may externally look like NIH does exist, but often it is simply the developers’ understandably cautious reaction to new and unknown components. They may fear that bugs or other problems will be more difficult to correct than with a solution over which they have full control. Often such fears are justified by unfortunate earlier attempts at reusing components, especially if they followed from a management mandate to reuse at all costs, not accompanied by proper quality checks. If the new components are of good quality and provide a real service, fears will soon disappear. What this means for the producer of reusable components is that quality is even more important here than for more ordinary forms of software. If the cost of a non-reusable, one￾of-a-kind solution is N, the cost R of a solution relying on reusable components is never zero: there is a learning cost, at least the first time; developers may have to bend their software to accommodate the components; and they must write some interfacing software, however small, to call them. So even if the reusability savings and other benefits of reuse are potentially great, you must also convince the candidate reusers that the reusable solution’s quality is good enough to justify relinquishing control. This explains why it is a mistake to target a company’s reusability policy to the potential reusers (the consumers, that is to say the application developers). Instead you should put the heat on the producers, including people in charge of acquiring external components, to ensure the quality and usefulness of their offering. Preaching reuse to application r R N = --- See [M 1995]