La sindrome “Not Invented Here”…

Salve gente.

In qualunque campo si lavori normalmente si tendono a preferire le cose fatte in casa a discapito di quelle provenienti da fuori.

Gli anglofoni chiamano scherzosamente questo comportamento “sindrome NIH” e ciò non è sempre dovuto alla qualità della cosa “aliena” con cui si deve interagire.

Talvolta si tratta di puro campanilismo, altre volte “paura dell’ignoto”, altre volte ancora si tratta di semplice sfiducia a priori nelle cose prodotte da altre persone.

Infine ci sono casi in cui tale atteggiamento è dovuto alla onnipresente pigrizia: “non ho voglia di imparare quella cosa (e quindi ne parlo male)!“.

Le reazioni possibili al dover integrare qualcosa di esterno sono svariate, talvolta illogiche e non sempre giustificabili in modo plausibile.

Casi reali

Una situazione abbastanza comune in ambito programmazione consiste nel dover integrare codice altrui, magari trovato sulla Rete o fornitoci da qualche collega.

Miracoli a parte, solitamente il codice importato non può essere integrato immediatamente e perfettamente, per cui ci vuole un po’ di restyle/refactoring affinchè il nuovo si amalgami – o non si discosti più di tanto dal – vecchio.

E qui ci si può davvero lasciar prendere la mano…

La sindrome NIH è sempre lì che aspetta: si inizia sistemando qualche nome di variabile, si passa ad aggiungere qualche commento (superfluo) e si finisce poi col bofonchiare a causa del codice importato che è scritto male, che non è ottimizzato, che non è portabile (anche se il progetto magari non è pensato per esserlo), non segue le best practices, eccetera eccetera.

Non è inusuale, al culmine della sindrome, pensare molto male di – e sproloquiare amabilmente su – chi ha originariamente scritto quel codice, anche e soprattutto se non lo si conosce.

Iniziano i problemi

Se la sindrome NIH è in atto, al termine della fase di integrazione/merge, il codice risultante non avrà probabilmente nulla a che fare con quello originariamente importato: si ottiene cioè codice nuovo, solo “liberamente ispirato” a quello importato.

Il codice integrato, orrido o splendente che sia, è probabilmente stato testato e collaudato. Riscriverne anche solo una parte può comportare il buttar via la saggezza ivi contenuta. E quando ci si accorge di questa cosa, è sempre troppo tardi…

La sindrome NIH può emergere anche quando si butta troppa carne sul fuoco: non è insolito optare per integrare in un colpo solo tutto il codice nuovo (“così facciamo prima”) e poi doversi mettere a riplasmarlo, cercando di stanare e sistemare contemporaneamente tutti i problemi e i bug che emergono.

A metà del lavoro, normalmente, ci si lascia prendere dallo sconforto, ci si lamenta di quanto poco integrabile sia il codice esterno (dimenticando che lo si è buttato tutto nel calderone) e, infine, si prova a migliorarlo…

In questi casi sarebbe invece opportuno integrare il codice procedendo per piccole tappe successive, ognuna delle quali controllata adeguatamente.

In altri termini la fase di merge’n polish (io la chiamo così) del codice dovrebbe seguire quello che in termodinamica è noto come processo quasi-statico: si avanza lentamente e in maniera accorta, in modo che si possa sempre tornare agevolmente sui propri passi al minimo intoppo (“processo reversibile”).

… e continuano!

Un altro problema tipico della fase NIH applicata al codice è il rischio concreto di overengineering: se non ci riesce di parlar male del codice importato, ecco che “per far qualcosa” (o per dimostrare di essere altrettanto “validi” rispetto all’autore del codice che è stato integrato) lo si addobba come e più di un albero di Natale.

Si comincia con l’aggiungere una feature non richiesta ma “che potrebbe servire un (lontano) domani” e, se non si sta attenti, si arriva in breve ad un accrocchio che potenzialmente fa anche la pizza, ma che sarà con molta probabilità così complesso dal risultare non manutenibile o, peggio, non vendibile.

Opporsi alla sindrome NIH

La sindrome NIH, come detto, è una fissazione, qualcosa di psicologico che scatta improvvisamente anche in persone all’apparenza molto disciplinate.

Di solito serve un bel po’ di autocontrollo e qualche aiuto-imposizione dall’esterno…

In un team di sviluppo, una prima soluzione sta nella bravura e nel polso fermo del Program Manager che deve essere in grado di identificare ed imporre al sottoposto, affetto della sindrome NIH, uno stop al suo inutile spunto “sovra-creativo”.

Questo genere di soluzione d’emergenza deve però essere accompagnata da qualche genere di accordo metodologico fra gli sviluppatori, che permetta di evitare situazioni in cui il merge di codice ricordi una somma di mele con pere.

Non si tratta di concordare per forza lo stile di codifica o altro (sarebbe il top ma è molto difficile da realizzare): basta quantomeno mettersi d’accordo su come integrare le cose, chi lo deve fare (non è una cosa così scontata come pare) e cosa si può fare per evitare il prodursi di una sindrome NIH.

Talvolta basta che due sviluppatori (o comunque due persone che devono interagire fra loro) si parlino anche solo per qualche minuto per debellare la “paura dell’ignoto”, una delle cause della sindrome NIH…

A tal proposito, un esempio semplice e facilmente applicabile consiste nel creare e integrare codice autocontenuto. Si tratta cioè di codice che sta in piedi da solo, che ha poche o addirittura nessuna dipendenza, e che può essere facilmente trasferito ad altri senza che questi ultimi debbano prendersi il disturbo di analizzarlo ed eventualmente correggerlo.

In termini più chiari è preferibile trasferire “codice-di-libreria” e non semplicemente codice: in questo caso chi riceve il codice potrà impiegarlo immediatamente e sarà meno tentato di metterci mano perchè dovrà farlo solo se strettamente necessario.

Per chi ama i paroloni, si tratta di una variante dell’approccio black-box in cui, pur potendo entrare nei dettagli (nessuno nasconde nulla), ci si limita ad usarlo tramite opportune interfacce e senza doverne o volerne conoscere i particolari…

Ciau!