¿Qué es el síndrome Not invented here?
Cultura de ingeniería y práctica de software
El síndrome Not invented here es la tendencia a desconfiar o rechazar ideas, herramientas o código principalmente porque provienen de fuera del equipo u organización. En el desarrollo de software se manifiesta cuando los ingenieros reconstruyen cosas que ya existen, se resisten a estándares compartidos o dan por sentado que el trabajo interno es automáticamente mejor. A veces ese instinto esconde orgullo o tribalismo. Otras veces refleja preocupaciones legítimas sobre control, licencias, seguridad o mantenimiento. Lo difícil es distinguir unas de otras.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Todo equipo de ingeniería debe decidir qué crear por sí mismo y qué adoptar de fuentes externas. Eso puede implicar comprar un producto, usar una biblioteca de código abierto, compartir una plataforma interna o aceptar un estándar desarrollado por otro equipo. El síndrome Not invented here aparece cuando esa elección ya se ha tomado emocionalmente antes de examinar la evidencia.
La expresión suele usarse como crítica, pero no es tan sencilla como "construir lo propio es malo". Los equipos a veces tienen buenas razones para evitar dependencias externas: pueden necesitar mayor control, una revisión de seguridad más rigurosa, mejor rendimiento o una diferenciación de producto más sólida. El síndrome es el sesgo, no el simple acto de construir.
Por qué importa
Este aspecto de la cultura de ingeniería importa porque se sitúa justo en la intersección del coste, la velocidad y la propiedad. Un equipo con fuertes instintos NIH puede pasar meses reconstruyendo infraestructura que aporta poco valor. Un equipo sin ningún escepticismo puede importar dependencias frágiles, generar dependencia de un proveedor o ceder capacidades estratégicas a terceros. La elección rara vez es solo técnica: es cultural, política y económica al mismo tiempo.
También importa para quienes trabajan junto a ingenieros. Los responsables de producto y los directivos suelen escuchar "deberíamos construir esto nosotros mismos" y asumir que es una conclusión técnica limpia. A veces lo es. Otras veces es una declaración de identidad disfrazada. Conocer el término ayuda a hacer mejores preguntas antes de que una preferencia se convierta en un compromiso de varios trimestres.
Cómo funciona
El origen del término
La expresión surgió de investigaciones y debates de gestión en torno a grupos de investigación y desarrollo que con el tiempo se volvieron introvertidos. En tecnología se consolidó porque el patrón es fácil de reconocer. Un equipo trata el trabajo externo como sospechoso por defecto y el trabajo interno como fiable por defecto, incluso cuando la evidencia apunta en sentido contrario.
Ese comportamiento por defecto puede ser sutil. Nadie anuncia "rechazamos las ideas externas". En cambio, la gente dice "necesitamos algo más adaptado", "esa biblioteca no está lista para producción" o "podemos hacer una versión mejor en un sprint". A veces esos juicios son acertados. El NIH es lo que ocurre cuando se vuelven habituales y autocomplacientes.
Por qué los ingenieros son propensos a él
En parte, la respuesta es el control. El código ajeno viene con suposiciones desconocidas, calendarios de versiones, prioridades de errores, convenciones de nomenclatura y modelos de soporte propios. Leerlo es más lento que escribir código nuevo. Adaptarlo puede sentirse como una concesión. Esa incomodidad es real y con frecuencia empuja a los equipos a reconstruir.
En parte, es orgullo. El software es un oficio, y los ingenieros se preocupan razonablemente por la calidad. Si un equipo ha sufrido con un proveedor deficiente o una plataforma compartida desordenada, "deberíamos ser dueños de esto nosotros mismos" puede parecer competencia en lugar de ego. El problema es que competencia y posesividad pueden sonar idénticas en las primeras reuniones.
También existe un problema de incentivos locales. Construir cosas nuevas es visible y prestigioso. Integrar el trabajo de otra persona, mejorar la documentación de proyectos externos o reforzar una biblioteca interna compartida resulta menos glamuroso. Muchas organizaciones celebran la invención más que la adopción cuidadosa. Con esos incentivos, el NIH puede parecer iniciativa.
Cuándo el instinto tiene sentido
Aquí es donde el término requiere matices. Rechazar un componente externo no es automáticamente irracional. Puede ser sensato si la capacidad es central para el producto, si las restricciones legales o de seguridad son severas, si el proyecto externo está abandonado o si la dependencia generaría una larga cadena de problemas de soporte. Joel Spolsky señaló hace años el contrapunto útil de que la reutilización puede crear interdependencias problemáticas. El código compartido no es gratuito solo porque no lo hayas escrito tú.
Un equipo sano, por tanto, se hace dos preguntas distintas. Primera: ¿es el componente externo suficientemente bueno para nuestra necesidad real? Segunda: ¿cuánto cuesta realmente ser propietarios de eso a lo largo del tiempo? El síndrome NIH aparece cuando se descarta la primera pregunta y se fantasea con la segunda.
La mejor contracorriente puede ser la expresión "proudly found elsewhere". Captura una actitud de ingeniería madura: usa lo que ya funciona cuando encaja de verdad. Construye cuando la propiedad vale estratégicamente la carga a largo plazo. No confundas la novedad con la ventaja.
Ejemplos
Una empresa ya dispone de una plataforma de autenticación compartida utilizada por varios productos. Un nuevo equipo decide escribir la suya propia porque el equipo de la plataforma compartida "es demasiado lento". Dieciocho meses después están manteniendo flujos de inicio de sesión, restablecimiento de contraseñas, registros de auditoría y trabajo de cumplimiento que nunca formaron parte del valor diferencial de su producto.
Un equipo de backend se niega a usar una biblioteca de colas de código abierto madura porque está convencido de que puede producir una versión interna más ligera. Al principio puede. Luego llegan el orden de mensajes, los reintentos, la observabilidad, las actualizaciones y la documentación, como parientes no invitados. La cola se convierte en un negocio paralelo.
Una organización crea cuatro sistemas de diseño internos ligeramente distintos porque cada grupo de producto quiere autonomía. Cada sistema es razonable por sí solo. Juntos generan trabajo de accesibilidad duplicado, errores de componentes duplicados y dolor de incorporación duplicado.
Malentendidos frecuentes
El síndrome Not invented here no significa que toda construcción interna sea vanidad. A veces construir es exactamente lo correcto, especialmente para una capacidad que define el producto o que conlleva restricciones inusuales.
Tampoco se resuelve gritando "construir frente a comprar" y declarando ganador al número más barato. La adopción tiene costes de integración, de gobernanza y de salida. La construcción tiene costes de mantenimiento, de personal y de casos extremos. La comparación necesita contemplar ambos lados.
Otro malentendido es que el NIH es solo un problema de gestión. Puede aparecer en cualquier lugar. Lo practican ingenieros individuales, equipos y directivos. La versión ejecutiva suele consistir en comprar una plataforma externa llamativa porque el trabajo interno parece anticuado y poco emocionante.
Por último, el extremo opuesto tampoco es sabiduría. Importar ciegamente cada dependencia, servicio o herramienta adquirida porque alguien ya la hizo es un tipo diferente de mal juicio, y a menudo termina en dependency hell.
Riesgos y límites
La expresión puede convertirse en un argumento que cierra el debate. Si toda objeción cuidadosa a una dependencia externa se etiqueta como NIH, los equipos pierden la capacidad de discutir problemas reales como la residencia de datos, la revisión de seguridad, la operabilidad, la adecuación de habilidades o el coste total de propiedad. Llamar a alguien NIH nunca debería eximirte del trabajo de argumentar tu postura.
También existe un límite humano. A veces lo que parece NIH es miedo. Los equipos conocen su propia pila tecnológica, su propia carga de alertas y sus propios plazos. Pueden resistirse al código externo porque no confían en que la organización los respalde cuando la integración se complique. En ese caso, el problema real no es la arrogancia, sino la ausencia de confianza compartida.
Qué hacer a continuación
Empieza por convertir construir, adoptar, bifurcar y comprar en opciones explícitas en lugar de identidades tribales. Pide a cada equipo que escriba por qué vale la pena ser propietario de una capacidad, qué carga conlleva esa propiedad y qué tendría que ser cierto para que una alternativa externa fuera aceptable.
Recompensa el trabajo de integración y gestión responsable. Si los ascensos y el reconocimiento solo siguen a la construcción desde cero, la gente seguirá reconstruyendo. Los equipos deberían recibir crédito por reducir la duplicación, contribuir con correcciones a proyectos externos, mejorar plataformas compartidas y retirar copias locales innecesarias.
También ayuda definir qué es genuinamente estratégico. Una empresa no necesita todo a medida. Necesita razones claras para las pocas cosas que realmente quiere controlar en profundidad. Una vez que esa línea es visible, muchos debates sobre NIH se vuelven menos emocionales y más honestos.
¿Tienes alguna pregunta o sugerencia, o quieres entender cómo investigamos y revisamos estas guías? Lee sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿El síndrome Not invented here es lo mismo que construir frente a comprar?
No. Construir frente a comprar es la decisión. El NIH es el sesgo que puede distorsionar esa decisión antes de que la evidencia se evalúe correctamente.
¿Puede el código abierto reducir el NIH?
Con frecuencia, sí. El código abierto puede facilitar la inspección, las pruebas y la mejora del código externo. Pero no elimina las preocupaciones sobre mantenimiento, actualizaciones o gobernanza.
¿Cuál es el opuesto del NIH?
A veces se dice "proudly found elsewhere". El opuesto poco saludable es importar cosas de forma acrítica solo porque están de moda o son externas.
¿Es el NIH siempre irracional?
No. Las herramientas y el código externos realmente conllevan costes de dependencia, soporte y bloqueo de proveedor. El problema es rechazarlos por reflejo en lugar de por un juicio cuidadoso.
¿Cómo puede un equipo saber si está siendo justo?
Pide una comparación escrita del coste de adopción, el coste de propiedad, el riesgo y la relevancia estratégica. Si el argumento depende principalmente del gusto o el orgullo, puede que el NIH esté actuando.
¿El NIH ocurre solo con proveedores externos?
No. Ocurre con frecuencia dentro de grandes empresas cuando un equipo de producto rechaza plataformas internas o ignora código desarrollado por otro grupo.
Fuentes
Documentation/CodingStyle and Beyond (Ottawa Linux Symposium). A grounded engineering example that explicitly tells kernel contributors to reuse well designed, well debugged facilities rather than reinventing them.