Lo aburrido es una característica

La mayoría del software no falla por falta de innovación. Falla porque acumula complejidad más rápido de lo que acumula comprensión.

La seducción de la novedad

Hay un patrón recurrente en los equipos de ingeniería. Comienza un nuevo proyecto, las restricciones son pocas y el equipo tiene libertad real. Casi de inmediato, alguien propone usar el framework más reciente, el motor de base de datos más nuevo, el lenguaje del que la comunidad lleva seis meses entusiasmada.

El razonamiento siempre suena sensato: mejor rendimiento, mejor experiencia de desarrollo, abstracciones más modernas. Lo que rara vez se dice en voz alta es que estas elecciones tienen un coste oculto: uno que no pagarán quienes lo toman, sino quien mantenga el sistema dos o tres años después.

La factura llega tarde

La novedad es cara, pero la factura llega más tarde.

Cuando un sistema se construye sobre tecnología desconocida o inmadura, el coste se difiere. A corto plazo, todo parece bien. El equipo está motivado. La velocidad es alta. El sistema hace lo que se diseñó para hacer.

La factura llega cuando algo falla a las 3 de la mañana y el runbook no cubre esta versión particular de la dependencia. Llega cuando los ingenieros originales se van y el nuevo equipo pasa semanas intentando entender una decisión que en su momento parecía obvia. Llega cuando el framework publica un cambio que rompe la compatibilidad y una migración que debería llevar un día lleva un trimestre.

Estos costes son reales, pero son invisibles en el documento de planificación. No aparecen en la velocidad del sprint. Se acumulan en silencio, hasta que se convierten en un techo sobre todo lo que el equipo puede hacer.

Qué significa realmente “aburrido”

Elegir tecnología aburrida no es lo mismo que ser conservador, averso al riesgo o poco ambicioso. Es entender qué tipo de riesgo se está aceptando.

Los sistemas aburridos fallan de maneras predecibles. Cuando una instancia de Postgres se queda sin conexiones, el error está bien documentado, la solución es bien conocida y la comunidad lo ha visto mil veces. Cuando tu caché distribuido a medida falla bajo un patrón de escritura inusual, estás depurando en la oscuridad.

La tecnología aburrida tiene mejor documentación. Tiene respuestas en Stack Overflow de hace ocho años que siguen siendo válidas. Tiene libros escritos sobre sus modos de fallo. Tiene ingenieros disponibles para contratar que no necesitan seis meses de formación antes de ser productivos.

Lo más importante: la tecnología aburrida permite que un equipo se centre en el problema real que intenta resolver, en lugar de en la infraestructura que eligió para resolverlo. Ese es el objetivo. La ventaja competitiva debe venir de la lógica de dominio, no de la novedad de la capa de almacenamiento.

Gastar los tokens de innovación con sabiduría

Dan McKinley introdujo el concepto de “tokens de innovación”: la idea de que cualquier equipo tiene un presupuesto limitado para elecciones no convencionales. Gastar un token en una nueva base de datos significa tener uno menos para el modelo de datos novedoso que el producto realmente requiere. Gastar un token en un lenguaje emergente significa tener uno menos para la estrategia de caché inusual que la escala demanda.

Usados con inteligencia, los tokens de innovación producen ventaja real. Usados sin cuidado, producen diagramas de arquitectura impresionantes y equipos lentos.

La pregunta nunca es “¿es interesante esta tecnología?” La pregunta es “¿es este el lugar correcto para gastar un token?”

Cuando la novedad se gana su lugar

Hay casos legítimos para la nueva tecnología. Cuando una opción probada genuinamente no puede cumplir el requisito —no “podría no cumplirlo algún día” sino que demostrablemente no puede—, la novedad se gana su lugar.

Cuando el equipo tiene experiencia previa profunda con la nueva tecnología y el riesgo es entendido en lugar de asumido, el cálculo cambia. Cuando la organización tiene la madurez operativa y la capacidad para absorber una curva de aprendizaje, la inversión puede justificarse.

Pero estos casos son más raros de lo que los equipos asumen. La mayoría de las aplicaciones no tienen requisitos de escala que justifiquen un sistema distribuido personalizado. La mayoría de los equipos no tienen la profundidad operativa para gestionar infraestructura que aún no entienden.

En la práctica

En la práctica, esto significa empezar con la elección aburrida y exigir un caso claro para desviarse de ella. Significa preguntar “¿qué pasa cuando esto falla?” antes de preguntar “¿cuáles son los benchmarks?”

Significa construir sistemas que el siguiente ingeniero pueda entender sin leer una wiki interna que nadie ha actualizado en dieciocho meses. Significa escribir código que el equipo pueda seguir razonando cuando los autores originales ya no estén.

La buena arquitectura no va de ser impresionante. Va de ser fiable.

Y la fiabilidad, la mayor parte del tiempo, se parece mucho a lo aburrido.