¿Qué es el desarrollo orientado al currículum?
Cultura de ingeniería y práctica de software
El desarrollo orientado al currículum es un término peyorativo para describir la práctica de elegir tecnologías, arquitecturas o proyectos principalmente porque quedan bien en un currículum, y no porque se adapten bien al trabajo. Es una expresión controvertida. A veces designa un patrón real de exceso a la moda. Otras veces se usa de forma demasiado laxa para desestimar el aprendizaje legítimo o la experimentación estratégica. La idea central útil es sencilla: las decisiones tecnológicas deben servir al trabajo en primer lugar, sin dejar de dar margen a los ingenieros para crecer.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Las personas que trabajan en software no construyen en el vacío. También construyen carreras profesionales. Esa tensión es el origen de la expresión. Si un equipo adopta un nuevo lenguaje, framework o arquitectura porque realmente encaja con el producto, perfecto. Si el verdadero motivo es "esto quedará genial en mi CV", las cejas se levantan. Ese es el significado popular del desarrollo orientado al currículum, a menudo abreviado como RDD.
El término se popularizó porque muchos ingenieros han visto el mismo patrón. Un sistema bastante ordinario de repente recibe una reescritura dramática. Una aplicación modesta adquiere microservicios, flujos de eventos, service mesh, tres bases de datos y una plataforma a medida. La versión oficial suele ser ambiciosa. La sospecha privada es menos halagadora.
Aun así, la expresión requiere un manejo cuidadoso. Los ingenieros tienen razón en preocuparse por su empleabilidad, y aprender nuevas herramientas forma parte del trabajo. Por eso la pregunta no es "¿Estamos usando algo nuevo?". La pregunta más útil es "¿Por qué esto, aquí, ahora, con este equipo y a este coste?".
Por qué importa
Este término importa porque las decisiones tecnológicas tienen repercusiones durante años. Una apuesta llamativa puede afectar a la contratación, el soporte, la seguridad, la incorporación de nuevos miembros, el riesgo con proveedores y la carga operativa. Si la decisión se tomó principalmente para pulir la imagen de mercado del equipo, la factura suele pagarla la siguiente generación de ingenieros y los equipos de negocio que dependen del software.
La expresión también pone de relieve algo más amplio que la vanidad de un ingeniero concreto. Los debates más recientes la tratan como un bucle. Los responsables de contratación llenan las ofertas de empleo con términos de moda porque creen que los candidatos los esperan. Los candidatos persiguen esos mismos términos porque creen que los empleadores los recompensan. Ambas partes refuerzan así un mercado donde la tecnología de moda parece más valiosa de lo que realmente es en la ingeniería del día a día. En ese sentido, el RDD puede ser sistémico y no meramente personal.
Para quienes lideran equipos, el término es útil porque da nombre a un olor familiar. Se escucha una propuesta y suena extrañamente desconectada de las restricciones reales. El producto es pequeño. El equipo de soporte es reducido. El plazo de entrega es ajustado. Y sin embargo, el plan empieza de algún modo con el stack más de moda en el circuito de conferencias. Poder nombrar ese patrón, con tacto y ecuanimidad, es mejor que quejarse en general de "sobreingeniería".
También importa para la moral del equipo. Los ingenieros necesitan crecer. Si cada decisión práctica los hace silenciosamente menos empleables o los deja atrapados en herramientas que no evolucionan, la empresa crea sus propios incentivos para el RDD. Esto no es un sermón sobre la mediocridad. Es una llamada a la deliberación. Los buenos equipos crean espacio para el aprendizaje sin dejar que cada objetivo de desarrollo profesional secuestre la arquitectura central.
Cómo funciona
De dónde viene el término
La expresión surgió del folclore de los desarrolladores y de escritos satíricos al estilo de los manifiestos. Ese origen importa porque explica el tono. El término nunca pretendió sonar neutro. Se acuñó para burlarse de un patrón en el que la ambición técnica se alinea de forma extraña con la señalización personal.
Con el tiempo, la expresión se amplió. Ahora abarca no solo decisiones individuales, sino un bucle de retroalimentación entre candidatos, equipos de contratación y la moda tecnológica. Esa visión más amplia es útil porque algunas decisiones cuestionables están impulsadas por presiones del mercado, no solo por el ego.
Cómo se forma el bucle
Todo empieza con la contratación. Una empresa quiere parecer actual y atractiva, así que menciona los últimos frameworks y plataformas en una oferta de empleo. Los candidatos lo leen y concluyen que necesitan experiencia visible en esas herramientas. Una vez dentro de la empresa, prefieren de forma natural los proyectos que les permiten acumular esa experiencia. Los responsables notan esa preferencia y ajustan las próximas ofertas. La moda viaja en círculo.
Esto no significa que nadie crea en las herramientas que defiende. A menudo sí creen. El problema está en la ponderación. Un equipo puede estar valorando la señal de carrera mucho más que el coste de mantenimiento, dotación de personal y operación.
Cómo se manifiesta en decisiones técnicas reales
El RDD suele aparecer en saltos arquitectónicos más que en pequeños cambios de herramientas. Una aplicación sencilla se divide en microservicios antes de que la organización tenga automatización de despliegues, buena observabilidad o límites de servicio claros. Un stack exitoso pero sencillo se reescribe en un nuevo lenguaje sin presión real del producto. Un equipo de plataforma introduce un flujo de trabajo sofisticado que solo un puñado de entusiastas puede entender.
Por eso el RDD se menciona con frecuencia junto a las historias de advertencia sobre microservicios. Los sistemas distribuidos añaden una carga operativa real. Si la organización no cuenta con los requisitos previos, las piezas móviles adicionales pueden ralentizar a todo el mundo. Una arquitectura de moda puede parecer avanzada e impresionante mientras hace el trabajo diario mucho más difícil.
Cómo es el aprendizaje saludable en su lugar
Criticar el RDD no significa congelar el stack para siempre. Los equipos necesitan experimentar. Necesitan modernizarse, aprender y reemplazar callejones sin salida. El patrón más saludable es separar el aprendizaje de la arquitectura central siempre que sea posible. Ejecutar un spike con tiempo acotado. Usar una herramienta interna como banco de pruebas. Introducir un nuevo componente en el margen, no una reescritura completa en el centro. Crear tiempo de formación explícito en lugar de colar el desarrollo profesional dentro de decisiones críticas para producción.
Otro patrón saludable es "elegir tecnología aburrida" como opción por defecto y hacer excepciones deliberadas. "Aburrida" aquí no significa antigua ni sin atractivo. Significa suficientemente bien comprendida como para que el equipo pueda operarla con confianza. Esa base es especialmente valiosa si el producto todavía está encontrando su forma. Un stack estable deja más atención para los usuarios, la entrega y la fiabilidad.
Por qué la acusación puede ser injusta
Como muchas expresiones del folclore del software, esta puede convertirse en un insulto fácil. A veces una propuesta legítima se descarta como RDD simplemente porque le resulta desconocida al revisor. A veces un ingeniero está pidiendo una modernización necesaria, pero una cultura adversa al riesgo lo llama vanidad. A veces los líderes pagan poco, forman poco e invierten poco, y luego se sorprenden de que el personal se preocupe por las habilidades con valor de mercado.
Por eso el término se usa mejor como un estímulo diagnóstico, no como un veredicto. Conviene preguntar qué problema se está resolviendo. Preguntar qué capacidades tiene ya el equipo. Preguntar qué carga futura introduce esto. Preguntar qué pasaría si se eliminara la parte llamativa de la presentación. Si la propuesta sigue teniendo sentido, probablemente no sea RDD.
Cómo se relaciona con otros términos culturales
El RDD suele tener una relación de parentesco con el mito del ingeniero 10x. Uno glorifica al héroe excepcional. El otro glorifica el stack llamativo. Juntos generan un modo de fallo poderoso: la creencia de que las personas excepcionales demuestran su valía a través de la complejidad excepcional.
También se solapa con el yak shaving. Los equipos pueden empezar con una actualización tecnológica pequeña y discutible, y luego perderse durante meses en adaptadores, trabajo de plataforma, scripts de migración y desvíos secundarios. El stack final puede parecer impresionante, pero nadie recuerda cómo el rodeo se hizo tan largo.
Ejemplos
Un producto pequeño con una aplicación web y una base de datos funciona de forma adecuada, pero los desarrolladores están aburridos y las ofertas de empleo del mercado están llenas de palabras de moda sobre sistemas distribuidos. Aparece una propuesta para dividir la aplicación en un conjunto de servicios, añadir mensajería asíncrona e introducir una nueva capa de operaciones. El producto todavía no necesita esa complejidad, y el equipo no tiene una práctica sólida de despliegue ni de trazabilidad. Esto es territorio clásico del RDD.
Un grupo de plataforma quiere estandarizar el trabajo de front end y propone un nuevo framework. Esto puede ser saludable o no. Es saludable si la configuración actual es problemática, la dotación de personal respalda el cambio, la migración es gradual y la nueva elección reduce la confusión a largo plazo. Es poco saludable si el argumento más sólido es que el equipo parecerá más moderno a futuros empleadores.
Un caso más sutil ocurre en la contratación. Los responsables siguen añadiendo términos de moda a las ofertas de empleo porque temen que la empresa parezca anticuada. Los ingenieros dentro de la empresa sienten entonces presión para introducir esas mismas tecnologías en el trabajo real solo para mantenerse alineados con la imagen de mercado que la propia empresa creó. Nadie pretendía iniciar un bucle de RDD, pero el bucle es real de todas formas.
Malentendidos frecuentes
Un malentendido es que cualquier uso de tecnología nueva debe ser RDD. Eso haría imposible el progreso. La pregunta es de adecuación, no de novedad. Muchos avances valiosos fueron nuevos en su momento.
Otro es que solo los ingenieros junior hacen esto. En realidad, el personal sénior puede impulsarlo con igual facilidad, a veces con más confianza y un lenguaje más persuasivo.
Un tercero es que la expresión culpa solo a los desarrolladores. Los equipos de contratación, los líderes, la cultura de las conferencias y la moda del sector contribuyen todos a crear los incentivos. El RDD suele ser compartido, no individual.
Algunas personas escuchan "elegir tecnología aburrida" y asumen que significa tolerar el estancamiento. No es así. Significa ser honesto sobre el coste operativo y la capacidad de adopción antes de elevar el entusiasmo a la categoría de arquitectura.
Por último, algunos equipos creen que la solución es simplemente prohibir el pensamiento sobre la carrera profesional en el trabajo técnico. Eso pasa por alto el problema humano. Las personas tienen razones legítimas para querer seguir siendo empleables. Las organizaciones saludables lo reconocen abiertamente en lugar de fingir que no existe.
Riesgos y límites
El riesgo más evidente es la complejidad que nadie pidió. Lenguajes, frameworks y piezas móviles adicionales pueden aumentar el coste de formación, el trabajo de soporte y la carga ante incidentes. También dificulta la contratación en profundidad porque cada puesto exige ahora una lista de herramientas muy específicas.
Un riesgo más sutil es la deriva estratégica. Los equipos pueden empezar a optimizar para lo que parece prestigioso en lugar de para lo que hace el producto más fácil de evolucionar. Eso ralentiza el aprendizaje real porque la organización gasta tanta energía manteniendo viva la maquinaria de moda.
Pero la crítica tiene un límite. Llamar RDD a algo puede convertirse en su propio movimiento perezoso. Puede frenar la experimentación, reforzar el gatekeeping y proteger a quienes ya están dentro y prefieren las herramientas conocidas por comodidad y no por mérito. Una empresa puede ser demasiado esclava de la moda, pero también puede ser demasiado temerosa.
La versión positiva de la idea es un estímulo para pensar con más claridad. La versión negativa es un desprecio dirigido a cualquiera que proponga un cambio. Los equipos útiles cuestionan el motivo sin burlarse de la persona.
Qué hacer a continuación
Crear un proceso ligero para las decisiones tecnológicas. No hace falta que sea grandioso. Una plantilla de una página puede ser suficiente: qué problema se está abordando, por qué esta opción, cuánto cuesta operarla, qué habilidades tiene ya el equipo, cómo sería una opción más sencilla y cómo se revertirá el curso si es necesario. Ese único hábito detecta una cantidad sorprendente de deriva impulsada por la moda.
Separar el aprendizaje de la arquitectura crítica para producción. Dar a los ingenieros espacio explícito para desarrollar habilidades a través de spikes, prototipos, herramientas internas, rotaciones o formación financiada. Cuando el crecimiento profesional tiene un lugar propio, es menos probable que secuestre los sistemas orientados al cliente.
Limpiar las señales de contratación. Revisar las ofertas de empleo y los escalafones internos. Si solo se premia la persecución de tendencias, no hay que sorprenderse cuando las personas actúan en consecuencia. Recompensar el mantenimiento, la fiabilidad, la enseñanza y el buen juicio con la misma visibilidad que la novedad en proyectos nuevos.
Por último, usar lenguaje claro en las reuniones de revisión. Preguntar: "¿Esto es para el producto, el equipo o el CV?" sin convertirlo en un ritual de vergüenza pública. A menudo la respuesta honesta es "algo de todo". Eso está bien. Lo importante es elegir de forma deliberada. Una buena cultura de ingeniería no niega la ambición. La orienta para que el trabajo siga siendo comprensible, mantenible y digno de heredar.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es el desarrollo orientado al currículum lo mismo que la sobreingeniería?
Se solapan, pero no son idénticos. La sobreingeniería puede surgir de la cautela, el perfeccionismo o la incomprensión. El RDD apunta específicamente a la señalización de carrera como probable motor.
¿Es malo que los ingenieros se preocupen por su currículum?
No. Es normal y racional. El problema empieza cuando las decisiones de producción están impulsadas principalmente por la señalización y no por la adecuación.
¿Puede una tecnología nueva seguir siendo la decisión correcta?
Sí. Si encaja con el problema, el equipo puede darle soporte y el intercambio es explícito, la decisión puede ser completamente acertada.
¿Por qué el debate sobre microservicios se vincula a menudo al RDD?
Porque los microservicios tienen un prestigio visible y una complejidad real. Pueden ser una excelente opción en el contexto adecuado, pero también son una insignia fácil de perseguir demasiado pronto.
¿Cuál es una forma más segura de probar algo nuevo?
Usar un experimento pequeño y reversible. Probar un componente en el margen, una herramienta interna o un prototipo con tiempo acotado antes de apostar todo el producto por ello.
¿Quién es responsable del RDD?
Generalmente más de una parte. Los ingenieros, los responsables, los reclutadores y la moda del sector pueden contribuir todos.
¿Cómo se relaciona esto con el mito del ingeniero 10x?
Ambos términos pueden recompensar la señalización individual llamativa por encima del rendimiento compartido y sostenible del equipo.
¿Cómo se relaciona esto con el yak shaving?
Una reescritura de moda puede desencadenar una larga cadena de migraciones, adaptadores y tareas de plataforma que consumen meses antes de que los usuarios vean un beneficio apreciable.
Fuentes
Resume Driven Development, A Definition and Empirical Characterization (arXiv). empirical definition, theory and consequences