Not Invented Here Syndrome In Software

Person A: “Let’s use that dependency for our requirements.”

Person B: “No, we can do better.”

Person A: “There is lightweight framework for our project. We can use it.”

Person B: “We must not use it. What if it has bugs?”

If you have ever been in a such technical meet, you faced a “Not Invented Here Syndrome”. In other words, you meet a someone who wants to invent wheel again and again.

So we start from “what is not invented here syndrome”. NIH is behavior of resisting to ideas, projects etc created by someone else. There are lots of reasons for that resistance. Confidence, R&D jobs, open source goals, commercial reasons can be some of these. NIH can be occur in many domains. We will discuss about software development and IT in this post.

There is no absolute truth or absolute wrong in software development and IT. So this is valid for NIH also. NIH is two sided situation. One of them is opposite to NIH and other one is support.

In supporting case, you may have strong and self confident development team to crate projects for your domain needs. So you can develop features which meet exactly requirements. Also team can simply do adjustments for changes in domain. This developments give you complete control on product and also IT team know every detail of process. When there is a bug or exception, team will deploy a bug fix in shorter time. Team has know-how on project. Know how equals power.

In against case, you do not have team and time to cover requirements. There are a lot of solutions proven by other users beside. If you develop a new product, it will pass steps like test, uat, bugfix, documentation etc. It is best to use a best practice solution. In that case you can save form money also like with using open source. You will not invent the wheel from start but you have chance to improve that.

It is upon to you and team to face with NIH or not. Both paths are have pros and cons. Criterions like time, money, domain requirements, team etc will effect your decision. This is not a subject of pride, because there is no place for pride in software development.

Thanks for reading.