Climens Codelog

Ya escribí en su momento sobre la cultura NIH, pero un interesante post de Jeff Atwood invita, como siempre a la reflexión sobre cuando es conveniente reinventar la rueda.

El caso es que se plantea hacer una función para sanear el HTML que introducen los usuarios de modo que se eviten los posibles ataques XSS. Alguien le dice que para que hacerlo si eso seguro que ya esta hecho a lo que Jeff responde con este post, indicando que el conocimiento sobre el saneamiento del HTML es una parte fundamental de su negocio.

En ese momento, se hace referencia a un artículo de Joel Spolsky en defensa del NIH, donde se introduce el siguiente cuestionario:

1. La reutilización de código es:
   1. Buena
   2. Mala
2. Reinventar la rueda es:
   1. Bueno
   2. Malo
3. El síndrome NIH es:
   1. Bueno
   2. Malo

Cuestionario al que toda persona de bien debería responder 1), 2) y 2). ¿Verdad?

Entonces viene la defensa. Vale, reutilizar código, tanto nuestro como de otros es bueno. Vale, reinventar la rueda es una pérdida de tiempo, seguramente otros hacen mejores ruedas y vamos a perder el tiempo. Vale, el síndrome NIH es una lacra social.

Pero... ¿existe algún motivo por el que valga la pena reinventar la rueda?

Joel lo dice claro:

Si es una función principal de tu negocio, hazla tú mismo, no importa lo que sea.

Es decir, si lo que hay que desarrollar es nuestro propio negocio, hay que reinventar la rueda y invertir esfuerzo en hacerlo. No importa lo que sea, pero si nuestro negocio depende de ello y es parte del conocimiento de nuestra empresa, lo mejor será hacerlo uno mismo.

En mi caso por ejemplo, tenemos desarrollado un gestor de proyectos. En su momento, fue un producto estrella y lo lógico es que hiciésemos el desarrollo y además, lo usásemos. Ahora mismo, ya no es parte del negocio así que convendría buscar una solución externa a la gestión interna de proyectos.

También tenemos desarrollado un gestor de tickets, que nunca se pensó como parte del negocio por lo que nunca se tuvo que haber hecho, se podría haber usado perfectamente uno de los miles de gestores de tickets comerciales que existen, como por ejemplo se está haciendo con el CRM.

Pero ahora mismo estamos enfrascados en el desarrollo de un ECM. Vale, hay ECMs comerciales impresionantes a los que posiblemente nunca alcancemos, pero vender ECMs personalizados para el cliente es nuestro negocio y tenemos que saber hacer ECMs. Podríamos revender otros ECMs pero entonces la empresa debería cambiar su enfoque de negocio.

Via | Programming is hard, let's go shopping!

NIH: Del inglés Not Invented Here. Según la Wikipedia, es un término usado para describir una cultura sociológica, corporativa o institucional que evita el uso de productos, conocimientos o estudios existentes debido a sus orígenes diferentes. Normalmente se usa de forma peyorativa.

Últimamente he estado involucrado en la programación de un sistema de gestión de tickets de posventa para la empresa dónde trabajo y quizás es uno de los ejemplos más claros del tiempo que puede llegar a perderse si uno es un fiel seguidor de la cultura NIH.

Este proyecto, que empezó como una paginita sencilla se ha convertido en uno de los pilares del servicio de posventa de la empresa por lo que, al ganar usuarios también ha ganado problemas. Pero el tema fundamental es: con la gran cantidad de software de este tipo, tanto comercial como libre que hay, ¿de qué sirve hacer un desarrollo interno para eso?

La respuesta, claramente, está en la cultura del NIH. Entre todos habremos dedicado quizás 150 horas o más a este desarrollo, que aun dista bastante se ser óptimo, pero por lo menos es usable. Pero si pienso por ejemplo en 150 horas, por 50€ la hora, tirando por lo bajo haciendo la media del precio por hora de desarrollo que se suele facturar de media (algunas horas valen más que otras ;-)), dan un total de 7,500€ que se podían haber dedicado a otros menesteres.

Algunos me pueden decir que he sido simplista. Bien, quitemos por ejemplo el coste de un software comercial, digamos 1,500€ siendo de los más caros, aun quedan 5,000€. Claro, habría costado de configurar, ajustar, personalizar... pongamos unas 50h o incluso 100h y sería el mismo coste.

Al final, habríamos tenido una herramienta impresionante (por ese precio hay gestores de posventa comerciales que hacen maravillas) configurada a nuestro gusto. Y es que está muy bien vivir del software a medida pero: ¡es carísimo! Así que la próxima vez que alguien plantee un desarrollo interno, hacedle ver que el ROI quizás no es demasiado positivo (eso a los jefazos les gusta, que hablemos en términos económicos).

Curiosamente, navegando he visto que no es un asunto exclusivo del software, la prestigiosa revista Nature (me hacía ilusión, en la prensa siempre lo ponen) tiene publicado un artículo sobre el NIH en investigación médica. Incluso hay un bonito libro sobre NIH en la industria aeroespacial. Si al final no somos tan distintos, reinventar la rueda para que sea propia es muy humano, aunque no es lo mismo competir por ser el más innovador que reinventarla por gusto.

Actualización 26/03/08: He encontrado un excelente artículo sobre el tema: Why we use Ant (or :NIH). via El síndrome NIH.