Эффект IKEA и синдром NIH в разработке ПО

• Sesgo: Sobrevaloramos las decisiones creadas con nuestro propio esfuerzo y, al mismo tiempo, desvalorizamos los desarrollos ajenos, especialmente si no fueron creados dentro de nuestra organización.
• Qué rompe: La evaluación objetiva de la calidad del código y la arquitectura, la colaboración en equipo, la capacidad de aprender de la experiencia ajena y la toma de decisiones técnicas fundamentadas.
• Nivel de evidencia: L2 — 4 estudios clave. El efecto IKEA está confirmado en condiciones de laboratorio (S001, S003), el síndrome NIH en desarrollo de software está documentado en casos prácticos e investigaciones organizacionales.
• Cómo detectarlo en 30 segundos: El equipo rechaza soluciones listas sin analizarlas, insiste en reescribir código existente y defiende sus propias soluciones de forma emocional, no argumentada.

¿Por qué nos enamoramos de nuestro propio código e ignoramos las soluciones ajenas?

Efecto IKEA — fenómeno psicológico en el que otorgamos gran valor a los objetos que hemos creado con nuestro propio esfuerzo (S001). En el contexto del desarrollo de software, esto significa que desarrolladores y equipos sobrevaloran la calidad del código, la arquitectura o los frameworks que han creado ellos mismos, aun cuando existen alternativas objetivamente mejores. Cuanto más tiempo y esfuerzo se ha invertido en el desarrollo, mayor es la valoración subjetiva de su valor.

Síndrome NIH (Not Invented Here — «no inventado aquí») — fenómeno organizacional en el que empresas y equipos se niegan a usar soluciones externas, bibliotecas o enfoques, prefiriendo desarrollar todo desde cero. No se trata solo de desconfianza al código ajeno, sino de una resistencia activa a la incorporación de soluciones listas, a menudo acompañada de la convicción de que los desarrollos internos son siempre superiores. El síndrome NIH se intensifica cuando la organización posee una fuerte cultura de ingeniería y se enorgullece de sus tecnologías.

Estos dos fenómenos están estrechamente vinculados: el efecto IKEA genera apego emocional a las propias soluciones, y el síndrome NIH transforma ese apego en una política organizacional. Juntos conducen a que los equipos dediquen meses a desarrollar funcionalidades que ya existen en proyectos de código abierto consolidados, o se nieguen a integrarse con los mejores servicios del mercado.

En el desarrollo de software esta combinación es particularmente peligrosa. Congela la pila tecnológica, aumenta la deuda técnica, desvía recursos de la innovación y crea la ilusión de control sobre la calidad. Los equipos afectados por el síndrome NIH a menudo sobreestiman sus capacidades — un fenómeno cercano al efecto Dunning‑Kruger, cuando la falta de experiencia impide evaluar objetivamente la complejidad de una tarea.

Superar este sesgo requiere una separación consciente entre el valor emocional (lo creé yo) y el valor práctico (resuelve la tarea de la mejor manera). Los equipos saludables realizan auditorías regulares de las soluciones existentes, establecen criterios claros para elegir entre código “propio” y “ajeno”, y fomentan la disposición a aprender de otros desarrolladores.

Diferencia clave

El efecto IKEA es un sesgo de percepción personal. El síndrome NIH es un comportamiento organizacional que puede existir incluso sin el efecto IKEA, si en la empresa simplemente se acostumbra a no confiar en soluciones externas.

Arquitectura cognitiva de la apropiación: cómo el trabajo reescribe la percepción

Apropiación psicológica mediante la inversión de esfuerzo

Cuando un desarrollador o un equipo invierten esfuerzos significativos en crear una solución, el cerebro reevalúa automáticamente su valor (S001, S003). Este proceso está arraigado en la lógica evolutiva: si un organismo ha gastado recursos en un objeto, debe ser valioso; de lo contrario, la inversión sería irracional. La apropiación psicológica activa los sistemas de recompensa en la corteza prefrontal, creando un vínculo emocional con el resultado del trabajo (S008).

En el contexto del desarrollo de software, esto significa que una solución arquitectónica en la que el equipo ha trabajado durante meses se percibe como más elegante y fiable de lo que realmente es. La crítica a dicha solución activa mecanismos de defensa, ya que un ataque al código se percibe como un ataque al esfuerzo invertido y, por ende, a la competencia del propio equipo.

Síndrome NIH como defensa de la identidad del grupo

El síndrome de “no inventado aquí” se intensifica cuando una solución externa amenaza la identidad del grupo. Un equipo que ha gastado recursos en desarrollar su propio framework percibe la solución lista no como una herramienta, sino como una negación simbólica de su competencia. Esto está relacionado con la error fundamental de atribución: las soluciones externas se atribuyen a la suerte o al marketing, mientras que las propias se atribuyen a la maestría.

La identidad grupal refuerza el efecto mediante el refuerzo social: los miembros del equipo confirman mutuamente la superioridad de su propia solución, creando una burbuja informativa. La distorsión de confirmación garantiza que cualquier dato sobre las ventajas de soluciones externas sea reinterpretado o rechazado.

Manifestación por etapas en el ciclo de desarrollo

En la fase de planificación, el efecto IKEA se manifiesta como una sobreestimación de las propias capacidades: el equipo subestima la complejidad de la tarea porque ya se ha apropiado psicológicamente del éxito. En la fase de codificación, la falacia de planificación se agrava por la renuencia a reconocer que el enfoque elegido no es óptimo, lo que requeriría una reevaluación del esfuerzo invertido.

Durante las pruebas, el síndrome NIH se manifiesta como una insuficiente prueba del propio código y una actitud excesivamente crítica hacia las alternativas. En la fase de mantenimiento, el equipo sigue defendiendo las decisiones arquitectónicas, incluso cuando generan deuda técnica, porque admitir un error implica reconocer que el esfuerzo invertido se ha gastado en vano.

Raíces neurobiológicas y evolutivas

El sistema de recompensa del cerebro (cuerpo estriado ventral y corteza orbitofrontal) se activa no solo al obtener el resultado, sino también al invertir esfuerzos para alcanzarlo. Este sistema está evolutivamente adaptado para cazadores‑recolectores, donde la inversión de energía en un objeto (fabricar una herramienta, procesar una presa) realmente correlacionaba con su valor.

En el desarrollo de software actual, este sistema trabaja en contra nuestra: la complejidad de la tarea y la cantidad de esfuerzo invertido ya no garantizan la optimalidad de la solución. Además, la ilusión de control lleva a los desarrolladores a creer que comprenden plenamente las consecuencias de sus decisiones arquitectónicas, lo que reduce la criticidad de la evaluación.

Factor	Efecto IKEA	Síndrome NIH	Influencia en el proyecto
Fuente del sesgo	Apropiación psicológica mediante el esfuerzo	Defensa de la identidad grupal	Sobreestimación de las propias decisiones
Sistemas cognitivos activados	Sistema de recompensa, vínculo emocional	Refuerzo social, punto ciego de sesgo	Reducción de la objetividad de la evaluación
Período crítico	Después de inversiones significativas de tiempo	Ante la aparición de soluciones competidoras	Los plazos y el presupuesto se extienden
Manifestación en el código	Reticencia a refactorizar, sobrecomplejidad	Rechazo de bibliotecas listas, duplicación de funcionalidad	Deuda técnica y vulnerabilidades de seguridad
Factor potenciador	Presentación pública de la solución	Tamaño y cohesión del equipo	Las decisiones arquitectónicas se vuelven inmutables

La combinación de estos mecanismos crea un escenario especialmente peligroso en TI: el equipo no solo sobrevalora la calidad de su código, sino que también resiste activamente los datos externos que contradicen esa valoración. Esto conduce a deuda técnica, retrasos en los plazos y vulnerabilidades de seguridad potenciales que permanecen sin ser detectadas debido a la distorsión del resultado — si el sistema funciona, entonces la arquitectura fue correcta.

Разработка, продуктовые команды, закупки, архитектура, исследования.

Ejemplos del efecto IKEA y el síndrome NIH en el desarrollo de software

Caso 1: Desarrollo de un sistema propio de gestión de contenidos en una startup

En 2019, un equipo de ocho desarrolladores en una startup de EdTech con sede en Moscú decidió crear su propio sistema de gestión de contenidos en lugar de implementar una solución ya existente como Contentful o Strapi. El proyecto estaba planificado para tres meses con un presupuesto de 25.000 €.

Los desarrolladores estaban convencidos de que podrían crear una solución más flexible y optimizada para sus necesidades. Sin embargo, tras ocho meses, el sistema seguía en desarrollo, los costos superaron los 80.000 €, y el equipo dedicó el 70 % del tiempo a depuración y corrección de errores en lugar de trabajar en el producto principal. El efecto IKEA se manifestó en que los desarrolladores estaban emocionalmente apegados a su solución y se resistían a las propuestas de usar alternativas ya disponibles (S001).

El síndrome NIH amplificó este sesgo: el equipo consideraba que las soluciones externas «no se adaptaban a su especificidad», aunque en realidad el 80 % de la funcionalidad coincidía con los requisitos. Los desarrolladores ignoraron las advertencias del gestor del proyecto y siguieron escribiendo código, invirtiendo cada vez más trabajo y energía emocional. Si el equipo hubiera realizado un análisis honesto de costos en la tercera semana de desarrollo y comparado el precio de la solución comercial con los gastos previstos, podría haber ahorrado 55.000 € y acelerar el lanzamiento del producto al mercado en cinco meses.

Caso 2: Reescritura de un framework en una gran empresa de TI

El arquitecto del sistema en una empresa con 200 desarrolladores inició un proyecto de reescritura completa del framework interno, que se utilizaba en 15 microservicios. El framework había sido escrito hace cinco años y necesitaba una actualización, aunque funcionaba de manera estable. El arquitecto convenció a la dirección de que la nueva versión sería un 40 % más rápida y un 60 % más fácil de mantener.

El proyecto duró 18 meses en lugar de los nueve planificados. Un equipo de 12 personas estuvo completamente ocupado con la reescritura, mientras que los demás desarrolladores no pudieron usar el nuevo framework y continuaron trabajando con el antiguo. Los costos ascendieron a 150.000 €. Cuando el nuevo framework finalmente se desplegó, se descubrió que el aumento de rendimiento fue de apenas un 12 % y la complejidad del mantenimiento se mantuvo al mismo nivel (S003).

El efecto IKEA y el síndrome NIH se manifestaron aquí en que el arquitecto estaba emocionalmente apegado a su visión del nuevo framework y no quería reconocer que la solución anterior funcionaba bien. El equipo de desarrolladores, que había invertido meses de trabajo en el nuevo código, lo defendía de las críticas, incluso cuando los datos mostraban que las mejoras eran mínimas. Si la empresa hubiera llevado a cabo un proyecto piloto en un microservicio y evaluado honestamente los resultados, habría comprendido que reescribir todo el framework no era rentable y, en su lugar, podría haberse centrado en optimizaciones puntuales del código existente.

Caso 3: Desarrollo de un ORM propio en lugar de usar Hibernate

Un equipo de cinco desarrolladores Java en una empresa fintech decidió crear su propio ORM (Object-Relational Mapping) en lugar de usar Hibernate, que era el estándar en la industria. Los desarrolladores consideraban que Hibernate era «demasiado pesado» y «no estaba optimizado para sus consultas específicas a la base de datos».

En 14 meses, el equipo escribió 25 mil líneas de código para su propio ORM. Sin embargo, cuando el sistema se desplegó en producción, surgieron problemas críticos: fugas de memoria, manejo incorrecto de transacciones y problemas de caché. La corrección de errores tomó cuatro meses adicionales. Paralelamente, se descubrió que Hibernate habría resuelto las mismas tareas mediante sus optimizaciones integradas y contaba con mejor documentación y una comunidad de soporte (S008).

El síndrome NIH y el efecto Dunning‑Kruger llevaron a que los desarrolladores sobreestimaran su capacidad para crear una solución mejor que una herramienta probada por el tiempo. El efecto IKEA amplificó este sesgo: cuanto más código escribían los desarrolladores, más apegados estaban a su solución y menos la evaluaban críticamente. Si el equipo hubiera realizado un análisis honesto de los requisitos y comparado la funcionalidad de Hibernate con las necesidades reales del proyecto en la fase de planificación, habría comprendido que la solución comercial cubre completamente sus necesidades y le permitiría centrarse en la lógica de negocio en lugar de desarrollar infraestructura.