Summary

---

The symptoms of NIH Syndrome:

• A desire to control every aspect of the application code because of a lack of trust in other programmers.

• Not using external code and libraries because of an unnecessary fear of:

  • Poor performance

  • Unknown learning curve

  • Minor missing functionality

  • Debugging difficulties

  • Affect on deadlines

• Duplicating code and work internally that has already been accomplished externally.

• Heavy reliance on internal development because of the belief that all facets of software engineering can be accomplished better internally.

To prevent NIH Syndrome:

• Use middleware and open source to reduce development time.

• Balance the time spent evaluating external solutions with the savings they provide.

• Be sure the appropriate level of technical support is available as a reassurance that the external solution will not cause undue problems.

• Understand the benefits and disadvantages of code snippets, standard libraries, run-time libraries, active libraries, and frameworks.

• Use .NET to expand the available external solutions.

• Use the Strategy, Adapter, Bridge, and Façade design patterns to provide encapsulation and abstraction of external libraries to allow easier integration and smoother replacement when necessary.

To cure the effects of NIH Syndrome:

• Do not allow internal code to become a sacred cow, protected for no valid reason.

• Do not be afraid to remove internal code in favor of better external code.

• Perform any transition to external code one step at a time using standard refactoring techniques.

• When possible, change or wrap the external interface to conform to internal standards.

• Apply workarounds carefully, and remove them as soon as they are no longer necessary.

• Use testing liberally to verify external code works as expecting and perform regression testing when changing implementations.

---