Not Invented Here Syndrome

Recently I have made some choices on IP I needed to re-use and some I decided not to re-use. This got me thinking about the general topic of reuse in system-level design.

Most will agree with a non-specific statement that reuse is a good thing, but the details tend to be a bit more ambiguous. Clouding the reuse question are occasional infections of NIH Syndrome (Not Invented Here), even if something is available to be reused and would potential save a tremendous amount of effort sometimes individuals or organizations don’t reuse it just because they didn’t create it.

Looking back at some of the projects I’ve been involved in, sometimes good decisions were made and sometimes the decisions were somewhat questionable. Looking at the high-level question, “Should I implement this myself or use an existing implementation?” On the surface the question appears to be a fairly straightforward, however as with many choices the devil is in the details.
Many factors play into the successful reuse of a piece of IP. The key questions that are worthwhile to think about:

• Is the IP related to my own critical differentiating capabilities?
• Is the available IP well-tested and robust?
• Will having a better, more targeted implementation of this IP significantly effect the quality of results I can achieve?

These questions lead to tradeoffs and decisions that make engineering interesting. I don’t believe there is one answer for all situations, or even that an answer will be constant for a given situation over time.

One enlightening example of choosing not to re-use comes from a project I was exposed to a number of years ago. A group was creating a high-level model of a very complex system. They decided to model the system in C++ and decided to create the simulation infrastructure from scratch. They decided not use standard TLM or even SystemC as a starting point for their modeling. I believe their decision was driven by the first question above. They felt the implementation of the model would be a critical differentiating capability, but they didn’t temper that against the available IP that could be leveraged and the effect on the quality of results they achieved.

After a number of years they did achieve their goal of a working model. In looking at what was created it was interesting to see that they ended up creating an infrastructure for modeling communication, timing and hierarchy that matched very closely what was available in TLM and SystemC. In an informal post mortem it was realized that leveraging the available modeling IP in TLM and SystemC could have saved significant resources without sacrificing the quality of the results they were trying to achieve.

I believe in this case, as in many cases, reuse was a very complicated decision that needed to be considered based on a number of criteria. Ultimately re-using a piece of IP inappropriately can lead to added costs and delayed or failed projects just as quickly as re-implementing a piece of IP that could have been leveraged. A little time upfront effort to think about the impact of reuse decisions we are making can provide tremendous returns in the quality and timeframe of what can be delivered. Re-implementing something doesn’t necessarily mean you’ve fallen victim to NIH Syndrome, but it is an indication of a decision that should be well justified.