Indietro

ⓘ Not invented here




Not invented here
                                     

ⓘ Not invented here

Soprattutto nellambito della cultura anglosassone, con not invented here, indicato anche con NIH o con sindrome NIH, ci si riferisce a quellatteggiamento culturale sociale, aziendale o istituzionale che spinge ad evitare di utilizzare ricerche, normative, prodotti o conoscenze già esistenti a causa delle loro origini esterne e dei loro costi. Il termine è normalmente usato in senso peggiorativo.

Le ragioni per non voler utilizzare il lavoro degli altri sono molteplici e possono includere il timore di violazione di brevetti, la mancata comprensione o la mancanza di volontà nel riconoscere il valore del lavoro degli altri, la gelosia, o la semplice guerra per il dominio sul territorio. Come fenomeno sociale, questa filosofia si manifesta come una mancanza di volontà di adottare unidea o un prodotto perché proviene da unaltra cultura, dando vita ad una forma di tribalismo.

                                     

1. In informatica

Nellambito della programmazione ci si riferisce generalmente alla sindrome NIH come la tendenza a reinventare la ruota cioè a reimplementare qualcosa che è già disponibile basandosi sulla convinzione che lo sviluppo autonomo sia intrinsecamente più idoneo, più sicuro, più controllato, più veloce e meno costoso che utilizzare implementazioni già esistenti.

In alcuni casi viene reimplementato un software con le stesse funzionalità di uno già esistente magari utilizzando semplicemente processi di reverse engineering solamente per consentirne lutilizzo con una diversa licenza software.

Le ragioni in favore dellapproccio NIH comprendono:

  • Unentità esterna al proprio controllo è un vendor lock-in e una minaccia costante per le imprese, proporzionale alle ripercussioni causate dalla perdita del supporto per le correzioni e i futuri aggiornamenti.
  • I componenti o i servizi di terze parti a volte non sono allaltezza delle aspettative quando è necessaria alta qualità.
  • Le soluzioni chiuse possono essere percepite come ostacoli ad una eventuale futura flessibilità del prodotto finale.

Alcuni approcci specifici in grado di attenuare queste problematiche:

  • Una soluzione esterna può essere presa come base per la propria implementazione, anziché essere utilizzata direttamente as-is.
  • Il controllo di una soluzione esterna può essere assicurato in caso di problemi con gli sviluppatori originali, ad esempio cercando di ottenere il suo codice sorgente