The response you are almost always going from most manager-types is something like:
"It's not worth it, it works now, and it will cost time to change."
And in general, this is valid. However, this is not always a valid argument, because the core issue surrounding "Not Invented Here" syndrome is not whether things work or don't work, but that technology is being pointlessly re-written, wasting company hours, and detracting substantial value from the product being delivered.
You need to determine if Not Invented Here is actually taking place before deciding what to do. The internal tech may have been written for a reason.
Signs that the Tech is Rewritten for a Reason:
- The tech you are selling is also the product. If you are a database vendor, using MySQL code, no matter how much time it will save, is a dangerous idea for many reasons.
- The internal tech is well-maintained and effectively addresses shortcomings of the off-the-shelf solution, while still providing comparable base functionality.
- The tech improves the productivity of the entire development team, and new developers are easily sold on why it is in use.
- There are other examples where the company has successfully adopted other external technologies.
- Your business would be immediately and seriously impacted if the OTS solution were discontinued or broken.
- The business is so large that it has the resources to write high-quality tools at a low cost (for example, Google may be able to write a database that costs less than a $1000/seat MS SQL license)
In other words, the team understands the drawbacks of re-solving already-solved problems, but judiciously made exceptions where it made sense from a business perspective.
Signs of "Not Invented Here":
- Seems like everything is internal, and there are excuses for everything: "uh, it was too slow", "uh, it's Microsoft, we hate Microsoft", "uh, it looks really hard to use", etc.
- For cases where external tech is being used, you hear "yeah, well it stinks and we plan on writing our own eventually".
- The owners of those components don't have other jobs they are capable of working on.
- You see most new developers coming in with a widely-accepted skill-set, but it takes considerable time for them to ramp-up to the internal tooling
- After careful analysis, it becomes apparrent that switching from the OTS solution to a custom or other OTS solution in the "what if it's discontinued!" scenario would have minimal business impact. For example, if
String.Join() were removed from the .NET Framework, re-implementation to a custom
StringJoin() method would be trivial.
In other words, NIH is the pattern of failing to stay objective and realistic in cases where external tech is being used instead of one's own code.
When tech is rewritten for a reason, bringing up your concerns should be praised and appreciated by your superiors. It should have been a careful decision when the tech was implemented, and reviewing the decision occasionally is good for the business. Things do change over time and you may have a valid point. If you can provide numbers about time wasted in the past, projected costs to switch, and other information, you could (in theory) make a case for switching.
Understand that given your experience, they may not agree with your numbers, but regardless, they should at least hear you out. It may take time to gain respect.
If the conversation can't even be brought up, even if you're being polite, it might just be "Not Invented Here". In which case, it is most likely a personality or political issue that you probably cannot fix easily. Working in an environment that is heavily bogged down by constant reinvention is toxic to the developers and the business. Run.
(Side note: In most companies, there is always an element of NIH, but it's at a tolerable level, and as long as they regularly review their code and practices. In the long term we are all guilty of it to a degree, but it never becomes an issue.)