El Blog de Trespams

L'altra dia de pagès al Twitter vam estar discutint alguns amics sobre la conveniència o no de desenvolupar un framework de programació web. Que si així pots controlar més el que fas, que si tot estarà més optimitzat i farà just el que vols, ... Collonades!

Ups! Me pareix que he tornat a ser políticament incorrecte, ja em perdonareu. Però aquesta és una de les típiques discussions xerrades entre informàtics i programadors, junt amb la tendència a proposar una eina totalment diferent quan algú diu que fa servir un programa o llibreria i està fent ja la tasca.

Anem a pams. Això és tan comú que fins i tot té un nom. És la síndrome de NIH (not invented here) i fins i tot en podeu trobar una entrada a la wikipèdia.

Bàsicament aquesta síndrome descriu la tendència a passar-se hores o mesos, a invertir temps en desenvolupar eines o programes que ja existeixen sols per fet que un es pensa que ho pot fer millor que el que ja hi ha, o bé com deia un poc abans, perquè té la convicció que li costarà menys fer el codi un mateix que aprendre a fer anar el codi d'un altre.

Les raons per ser conscients del problema són nombroses i miraré de fer-ne cinc cèntims un poc més endavant, però a vegades el NIH no és tant dolent i hi ha raons que fan que encara que existeixi un producte que fa el que volem, sia millor desenvolupar-lo a casa. Joel Spolski ho exposa molt bé a In Defense of Not-Invented-Here Syndrome i ho podem resumir molt fàcilment: té sentit fer-ho a casa quan allò que estàs desenvolupant forma part bàsica del teu negoci, del teu core business) en qualsevol altra cas ens ho em de mirar molt bé, ja que en la majoria de casos estarem davant d'un cas NIH com a una casa.

En un mon d'eines lliures i de codi obert la síndrome NIH fa que enlloc de col·laborar per a millorar els productes ens trobem amb un gran munt de llibreries que fan el mateix. Curiosament quan més senzilla és la tasca pareix que més llibreries hi ha, entroncant també amb la síndrome de la casa d'eines: si la tasca a fer és senzilla, com una caseta d'eines, tothom hi diu la seva i és mira en lupa tot, si la tasca a fer és complexa, com un gratacels o una fàbrica encara que el que hi hagi en joc sigui menor es fan menys aportacions.

És veritat que aprendre un nou bastiment de programació és complexe, tot aprenentatge ho és. Però al mateix temps que un aprèn el bastiment estam aprenent com un altre conjunt de programadors ha atacat el problema, llegim el seu codi, i per tant estam millorant la nostra formació. Si fem nosaltres el mateix com a programadors solitaris perdem aquesta oportunitat d'aprendre.

Potser ens trobem que el que hi ha fet no té la qualitat que volem, o ha de fer més coses. Doncs endavant, intentem millorar-ho. Ara tenim eines com git, mercurial o bazar que ens permeten fer branques molt fàcilment i enviar els nostres canvis al desenvolupador inicial de l'aplicació. En la majoria dels casos aquest estarà més que agraït en rebre la nostra contribució i tothom en surt beneficiat.

Un d'aquests amics ens deia que la raó era que tenia por a equivocar-se de bastiment i que no fos "el bo", i per tant millor fer-ho a casa per por a no equivocar-se. El problema és que fent això ja t'has equivocat.

Potser la teva productivitat inicial pareixerà que és més gran, perquè estàs escrivint codi enlloc d'aprendre, però pensem que és codi que per començar mai s'hauria d'haver escrit.

Pensem per un moment que tenim aquesta por i fem el bastiment de programació nosaltres enlloc de triar-ne un ja existent que estigui mantingut i documentat. Què passarà demà quan la tecnologia evolucioni? Ens trobarem perdent gran quantitat de temps intentant evolucionar el codi, intentant seguir el ritme o dient al nostre client que "això no ho podem fer". He conegut gent que té batiments que li generen el codi del manteniments mestres, però que quan el client els diu que ha de canviar l'ordre dels camps o afegir una validació diu que no es pot.

I si l'empresa creix o hem d'incorporar gent nova al nostre equip? Si el bastiment no l'hem fet nosaltres hi ha possibilitats que el candidat ja el conegui (o al manco podem intentar posar-ho al requeriments de la feina), però encara que estiguem en el cas pitjor, li podrem dir que es llegeixi la documentació, que miri els exemples de como ho fa l'altra gent. Si ho hem fet nosaltres l'hem de mantenir, l'hem de documentar i quan algú s'incorpori l'haurem de formar i en la majoria de casos no hi haurà documentació d'aquest bastiment propi. La nostra por s'ha convertit en una hipoteca pel nostre futur que ens dificultarà evolucionar o ser competitius.

I què passa amb els nostres clients? Aquesta decisió també els afecta, ja que els estam fermant d'alguna manera a nosaltres, ja que en cas de voler agafar ells el projecte es trobaran amb un bastiment de programació que sols l'empresa original coneix, haurà de dedicar molts esforços a aprendre com va i també l'estarem condemnant a mantenir-ho.

Hem de lluitar contra el "m'estim més fer-ho jo" i abraçar més el concepte de comunitat, confiar també amb la feina i el bon fer d'altres programadors que segurament en saben tant o més que nosaltres. Potser demà ens trobarem amb la necessitat de desenvolupar una eina que realment sia necessària i també ens agradarà rebre contribucions i que la gent s'animi a mantenir-la amb nosaltres.

El NIH és un perill perquè va contra el concepte de comunitat i col·laboració, perquè en la gran majoria dels casos representa una hipoteca tecnològica brutal per a nosaltres o els nostres clients. Així que abans d'optar per la solució fàcil de m'ho faig jo, potser ens convé reflexionar un poc no sia cosa que haguem agafat aquesta malaltia.