Choose Boring Technology (2015)
Un ensayo muy citado que insta a los equipos a “elegir tecnología aburrida” provoca debate sobre cuándo favorecer pilas probadas y bien entendidas frente a herramientas más nuevas que prometen mayor rendimiento pero añaden riesgo. Muchos ingenieros elogian ideas como los “tokens de innovación” como una forma práctica de limitar la novedad a unas pocas áreas de un sistema, especialmente en startups o infraestructura donde la fiabilidad, las plataformas compartidas y la mantenibilidad importan más que las decisiones impulsadas por el currículum. Otros sostienen que etiquetas como “aburrida” son vagas y pueden cortar el análisis adecuado, señalando que el contexto, la experiencia del equipo, los ecosistemas en evolución (desde Node y Kubernetes hasta agentes de IA y pilas compatibles con LLMs) y los requisitos claramente definidos deberían guiar las decisiones tecnológicas en su lugar.
Tokens de innovación y tecnología “aburrida”
- A muchos comentaristas todavía les gusta el marco de los “tokens de innovación” como una forma de explicar compromisos a personas no ingenieras y mantener el riesgo concentrado en unas pocas áreas.
- Otros sostienen que la metáfora es difusa; las decisiones deberían plantearse explícitamente en términos de riesgo, pruebas, modos de fallo y experiencia del equipo, en lugar de “aburrido vs nuevo”.
- Varias personas subrayan que “aburrido” es algo contextual: si un equipo ya conoce Node, Mongo, Rust, etc., eso puede contar como aburrido para ellos.
Definiendo “aburrido”
- Definición de trabajo del hilo: tecnología cuyas capacidades y, especialmente, cuyos modos de fallo están bien entendidos, con pocas sorpresas de “no sabía que podía hacer eso”.
- Ejemplos citados con frecuencia como aburridos: Postgres/MySQL, PHP/Ruby/Django, cron, memcached, configuraciones básicas de Linux + HAProxy.
- Algunos argumentan que todo sistema, incluidas las bases de datos “aburridas”, tiene muchos footguns; aburrido solo significa “la cantidad conocida menos mala”.
Node, JavaScript y la rotación del ecosistema
- Hay un amplio acuerdo en que Node en sí es “aburrido” en 2026, pero muchos ven el ecosistema de JS (la dispersión de npm, la rotación de herramientas, el riesgo de cadena de suministro) como todavía no aburrido.
- Debate sobre si algo en el ecosistema de JS puede considerarse maduro frente a otros lenguajes.
Kubernetes y la complejidad de infraestructura
- Fuerte rechazo a tratar Kubernetes como aburrido; muchos lo ven como excesivo para la mayoría de las empresas y una fuente importante de caídas y carga cognitiva.
- Se argumenta que configuraciones simples en bare metal o VPS con una pequeña pila (Linux + Postgres + PHP/Python) son suficientes para la mayoría de las aplicaciones de negocio.
Incentivos, carreras y “desarrollo impulsado por el CV”
- Varios comentarios señalan que los incentivos del currículum y la cultura del héroe recompensan la tecnología llamativa y apagar incendios más que la prevención y la fiabilidad aburrida.
- A otros no les gustan términos como “CV-driven development”, porque consideran que asignan motivos malos de forma injusta.
IA/agentes y tecnología aburrida
- Algunos sugieren gastar los tokens de innovación en IA/agentes y combinarlos con pilas aburridas y en distribución, que los modelos conocen bien (por ejemplo, Django, PHP, Go).
- Existe la preocupación de que los LLMs se inclinen por pilas populares o de moda (TypeScript/Next.js), sesgando las decisiones.
- Otros sostienen que los LLMs, de hecho, facilitan usar tecnología más antigua y simple de forma eficaz.
Críticas a la tesis
- Los críticos dicen que “elige tecnología aburrida” puede convertirse en un cliché que termina el pensamiento, usado para bloquear la innovación adecuada o justificar pilas heredadas que no encajan.
- Contrapropuesta: elegir siempre “la tecnología más apropiada”, con la aburrición como solo un factor entre requisitos, ajuste a la carga de trabajo, contratación y coste operativo.