Not Invented Here
In my line of work there are always options. Software libraries and tools are plentiful. Software products that help you write software are also quite numerous. If you have a particular need for a particular feature in your own software, it’s very likely you can find another library or tool that will help you write it. Some companies fight this use of external libraries and tooling. That’s called “Not Invented Here”. The reasons used to justify this behavior are all pretty weak. And frankly this kind of behavior doesn’t happen much anymore in software development due to the success of open source.
Don’t Invent Here is the new Not Invented Here
Instead of fighting the use of external tools and libraries some companies now rely solely on them. Companies will go through a rather rigorous process of seeking out a product or vendor that has pretty close to all the features that they want in their own product. This process can take months. It’s difficult and requires a ton of sales meetings and demos. Once a product or vendor is chosen then the next step is to get the engineering staff up-to-speed with this external tool. Now training and skill set improvements are required and that takes months. And in the end you should get the benefit of not having to go through the invention process at all and simply rely on the product or tool to have solved all the hard problems for you. This allows you to stamp out your own product in an assembly line or widget stamping fashion. This is what I call “Don’t Invent Here”.
I admit there are very good reasons for DIH. To get to market quickly it can be the best option in some cases. If the product you’re building is a large deviation from what you previously did and your engineering staff doesn’t have the skill set, an external tool or product can mitigate that by abstracting enough details away that your staff can get moving faster. And in fewer cases there are vendors who have simply solved the problems and made a product that can provide everything you need to build your product. But that is rare to the point of being unicorn-ish.
Your product requires some invention
NIH is often worse than DIH in software product development. However DIH is crippling as well. Your product is unique and can’t be solved by someone else’s product. Which is to say if an external product or tool doesn’t do something, then your software won’t do it either. If a company is a product development company then likely they are writing software that is unique or has unique feature sets. More often than not these unique characteristics can’t be found in 3rd party tools or libraries. This requires invention to make the uniqueness. Sometimes it isn’t related to a product feature. In some cases it can be related to product development. The way in which you write the software can be hampered by DIH because generally the 3rd party vendor has a different perspective than you do on how you write software. If the external tool provides it’s own software editor that is a clear sign that they have a particular way of doing things and to get the maximum benefit of that product you’ll need to do it that same way. But if you must do it another way this will require invention.
In an environment where DIH is used, you need to make Pareto Improvements. There has to be some mixture of DIH and invention to achieve the success of the product. In many cases the improvement will sacrifice a benefit of the 3rd party tool. But that shouldn’t demotivate the need for invention. That is also not making judgement on the value of that external tool. If a product is truly unique it will require invention. Even if it’s not, you are going to do some form of invention. That’s how product development works.
Always look to invent. It doesn’t have to be 100% of your effort, but just know that it will be some percentage.