# NIH - Not Invented Here NIH is the tendency to avoid using code, library, standards, or knowledge from external origins and use something created internaly to the company, team or by the person itself. ## Roots of the NIH syndrome There is many things that can lead to a NIH syndrome. Understanding its root causes is crucial for recognizing and mitigating this counterproductive behavior: ### Ignorance of the outside world Insufficient familiarity with the broader ecosystem contribute to NIH. This gap often stems from a lack of exploration and research into existing tools, libraries, or standards, leaving potentially useful external resources overlooked. ### Other's work value dismissiveness It can be easy to overemphasize the flaws in external solutions while minimizing or overlooking the shortcomings of internal alternatives. This bias can lead to an unfair dismissal of external work, even when it might offer superior efficiency, reliability, or scalability. ### Lack of understanding Lack of understanding of how external solutions work can lead to discomfort or mistrust, as developers may feel uncertain about integrating or maintaining tools they did not create. Without a clear comprehension of the external code’s design, functionality, or limitations, teams might default to building their own solutions, even when existing options are well-documented and reliable. ### Pride Pride in one's work is a natural and often positive trait among software engineers, driving innovation and excellence. However, when pride morphs into a preference for reinventing the wheel rather than adopting external solutions, it becomes a perverse incentive that fuels NIH syndrome. ### The Fallacy of Complexity Equals Value One key aspect of this perverse incentive is the fallacy that creating complex, custom solutions is inherently more valuable than using existing ones. This belief can lead to a culture where engineers who develop intricate systems from scratch are seen as more skilled or valuable than those who integrate and optimize external solutions. ## Drawbacks ### Spending time Developing internal solutions often consumes a significant amount of time and resources. This includes time spent designing, coding, testing, and debugging. In contrast, leveraging existing external tools or libraries can dramatically reduce the time required to achieve the same functionality, allowing developers to focus on higher-value activities or strategic initiatives. The time cost of reinventing the wheel can delay project delivery and increase overall costs. ### Reliability External solutions often undergo rigorous testing and widespread use, making them more reliable. Internally developed solutions may lack the same level of scrutiny and real-world validation. Reliability is a cornerstone of effective software development. When considering the adoption of external solutions versus developing internal ones, the reliability factor often tips the scale in favor of established external tools. [TBD] ### Documentation and Testing Established external tools typically come with extensive documentation and thorough testing frameworks. In contrast, custom-built solutions may suffer from inadequate documentation and testing, making them harder to maintain and extend. ### Community Acceptance Widely-used external solutions benefit from community support and continuous improvement. They are more likely to be updated and refined in response to user feedback. Internal solutions lack this broad user base and iterative enhancement. ### Technical Dept Developing and maintaining internal solutions often incurs significant technical debt. This includes the ongoing cost of updates, bug fixes, and adaptations to new requirements. Over time, this can become a substantial financial and operational burden for the company. ## Mitigation ### Balancing Pride with Practicality While there are instances where building custom solutions is beneficial—such as when a unique, business-specific need exists that no external tool can adequately address—most of the time, relying on proven, external solutions is more pragmatic. Companies must strive to balance pride in craftsmanship with practical considerations of efficiency and sustainability. ### Mitigating the Perverse Incentive To counteract the negative effects of this pride-driven fallacy, organizations can implement several strategies: #### Promote a Culture of Pragmatism Encourage engineers to prioritize outcomes and impact over the complexity of their work. Recognize and reward the effective use of external solutions alongside innovative internal development. #### Emphasize Cost-Benefit Analysis Regularly conduct cost-benefit analyses to compare the potential advantages of internal development versus adopting external tools. Highlight the long-term costs associated with technical debt and maintenance of custom solutions. #### Foster Continuous Learning Ensure that engineers stay informed about the latest external solutions and industry standards. Encourage attendance at conferences, participation in professional networks, and ongoing education. #### Encourage Collaboration and Knowledge Sharing Break down silos within the organization to foster a culture of collaboration. Promote knowledge sharing about successful integrations of external solutions and the benefits they bring. --- Bibliography: - [Not invented here - wikipedia.org](https://en.wikipedia.org/wiki/Not_invented_here)