La torre del software sigue creciendo

Durante años nos repitieron la misma promesa: usar más abstracciones para escribir menos código, depender de menos piezas y operar con menos dolor. La idea sonaba razonable. Menos complejidad visible, menos fricción, menos tiempo perdido. Pero si miras cualquier stack moderno con calma, la foto real es otra: la torre no se achica, solo cambia de forma. Cambias un problema por tres más pequeños, y luego esos tres crecen.

Eso no significa que la simplificación sea falsa. Significa que tiene un costo y que ese costo casi nunca aparece donde se vende la promesa. No lo ves en la demo del framework ni en el benchmark del proveedor. Lo ves en el equipo que tiene que mantenerlo vivo: más decisiones, más tooling, más observabilidad, más despliegues, más dependencia de terceros, más tiempo para entender por qué algo que “debería ser simple” ya no lo es.

La complejidad no desaparece, se desplaza

El stack de software moderno no crece solo por capricho. Crece porque cada capa resuelve una parte concreta del problema y deja otras abiertas. Un framework te ahorra tiempo en la interfaz, pero te agrega reglas. Un ORM te evita SQL repetitivo, pero te mete otra capa de abstracción. Un proveedor cloud te quita operación física, pero te obliga a aprender límites, cuotas, IAM, redes y facturación.

La trampa está en pensar que quitar código equivale a quitar complejidad. A veces sí. Muchas veces no. A veces solo la mueves de lugar: del repositorio al pipeline, del backend al runtime, del runtime a la infraestructura, de la infraestructura al equipo de guardia. El costo no desaparece, se redistribuye.

Un ejemplo simple: antes, para desplegar una aplicación, bastaba con un servidor, un proceso y un archivo de configuración. Hoy puedes tener build, test, lint, typecheck, bundle, deploy, preview environments, feature flags, secrets manager, observability, rate limits, CDN, colas, workers y un proveedor de identidad. Cada pieza resuelve algo real. El problema es que cada una también requiere configuración, monitoreo, documentación y criterio para no romper lo demás.

La torre crece por capas, no por una sola decisión

No suele existir un día en el que el stack se vuelva inmanejable. Más bien se acumulan pequeñas decisiones que, aisladas, parecen sensatas:

1. Adoptar un framework para acelerar el frontend.
2. Agregar una cola para desacoplar procesos lentos.
3. Meter un gateway para ordenar autenticación y tráfico.
4. Incluir observabilidad para entender incidentes.
5. Separar servicios para que cada equipo avance más rápido.

Cada paso tiene una justificación. El problema aparece cuando sumas todos. Entonces descubres que el equipo ya no trabaja sobre una aplicación, sino sobre una red de dependencias donde cualquier cambio toca tres sistemas, dos pipelines y un dashboard que nadie mira hasta que hay un incidente.

En ese punto, la complejidad ya no es un detalle técnico. Es una forma de organización del trabajo.

Lo que cambia para el equipo de ingeniería

La primera víctima de esta torre es el tiempo de atención. Cuando el stack crece, tu equipo deja de pensar solo en producto y empieza a pensar en compatibilidad, coordinación y riesgo. No es un problema abstracto. Se traduce en horas de reunión, PRs más grandes, revisiones más lentas y más contexto para cada cambio pequeño.

También cambia el tipo de conocimiento que necesitas. Antes, una persona fuerte en backend podía resolver mucho. Ahora necesitas gente que entienda runtime, cachés, despliegue, seguridad, costos cloud y experiencia de usuario. Eso no es malo por sí mismo, pero sí sube la barra de entrada. Un equipo chico termina dependiendo de pocas personas que entienden el sistema completo, y eso crea cuellos de botella.

Hay otro costo menos visible: la confianza. Cuando el stack tiene demasiadas piezas, cada cambio deja de sentirse directo. Ya no sabes si el bug está en el código, en la configuración, en el proveedor, en el caché o en un límite de la plataforma. Esa incertidumbre hace que el equipo se vuelva más conservador. Y cuando un equipo se vuelve más conservador, la velocidad cae aunque el backlog siga creciendo.

Tres costos reales que sí puedes medir

Si quieres aterrizar el impacto, hay tres métricas que ayudan más que una discusión filosófica sobre “simplicidad”:

• Tiempo de onboarding: cuánto tarda una persona nueva en hacer su primer cambio útil sin ayuda constante.
• Tiempo de cambio seguro: cuánto tarda desde que abres un PR hasta que llega a producción con confianza.
• Tiempo de diagnóstico: cuánto tardas en encontrar la causa raíz de un incidente o regresión.

Si esas tres cifras suben, la torre está cobrando peaje. No importa si el stack se ve elegante en una presentación.

Por qué cada capa pide más trabajo del que promete

La mayoría de las capas nuevas llegan con una promesa concreta. El framework promete productividad. La nube promete elasticidad. El contenedor promete portabilidad. El servicio administrado promete menos operación. Todo eso puede ser cierto. Pero ninguna capa viene gratis: cada una introduce su propia superficie de errores, sus propias actualizaciones, su propia semántica y sus propios límites.

Tomemos observabilidad. Hace años bastaba con logs. Luego llegaron métricas, trazas, alertas, SLIs, SLOs y dashboards. Eso mejora muchísimo la capacidad de entender sistemas complejos. Pero también exige disciplina. Si no defines bien qué alerta importa, terminas con ruido. Si no correlacionas eventos, terminas con logs que nadie lee. Si no cuidas el costo de ingestión, la factura crece más rápido que la claridad.

Lo mismo pasa con la infraestructura como código. Es mejor que hacer cambios manuales en un panel, sí. Pero también significa que ahora tienes que versionar, revisar, probar y desplegar infraestructura con el mismo rigor que el código de negocio. Si no lo haces, la promesa se rompe y aparece otra clase de deuda.

Ejemplo práctico: un cambio pequeño que ya no es pequeño

Imagina que quieres agregar un nuevo estado de pago en una app de comercio electrónico. En un stack simple, tocarías backend, frontend y base de datos. En un stack más grande, ese mismo cambio puede implicar:

• Ajustar un enum o contrato de API.
• Actualizar validaciones en el frontend.
• Revisar eventos en una cola asíncrona.
• Confirmar compatibilidad con analítica y reporting.
• Verificar reglas de permisos o antifraude.
• Actualizar tests de integración y contratos.

El cambio funcional sigue siendo uno. El costo organizacional ya no.

Eso explica por qué muchos equipos sienten que trabajan más para mover menos. No es falta de talento. Es que el sistema alrededor del cambio se hizo más pesado.

La simplificación también tiene costo

Sería injusto decir que todo crecimiento de la torre es malo. Muchas capas existen porque el problema real cambió. Un producto con 1.000 usuarios no se opera igual que uno con 10 millones. Una app monolítica que funcionaba bien al principio puede volverse un freno cuando varias personas editan el mismo código todos los días. Separar responsabilidades, usar servicios administrados o meter una cola puede ser la decisión correcta.

El punto no es volver a un pasado idealizado. El punto es no vender la simplificación como si fuera gratis. Simplificar una parte casi siempre complica otra. El monolito reduce coordinación entre servicios, pero puede aumentar el riesgo de despliegue. Una plataforma interna acelera equipos, pero requiere inversión sostenida. Un proveedor administrado reduce operación, pero te ata a su API y a sus precios.

La pregunta útil no es “¿esto simplifica?”. La pregunta útil es “¿qué complejidad estamos quitando, cuál estamos creando y quién la va a pagar?”.

Cuándo sí vale agregar una capa más

Hay señales claras de que una nueva capa tiene sentido:

1. El equipo ya repite el mismo trabajo varias veces al mes.
2. Un incidente específico consume horas de guardia cada semana.
3. El tiempo de despliegue o rollback se volvió un riesgo operativo.
4. La coordinación entre personas cuesta más que la ejecución técnica.
5. El negocio ya depende de una capacidad que el stack actual no soporta bien.

Si no tienes una de esas señales, agregar otra pieza a la torre suele ser solo una forma elegante de posponer la discusión real.

El costo oculto en LatAm y en equipos pequeños

En Latinoamérica este tema pega distinto porque muchos equipos trabajan con presupuestos más ajustados, rotación más alta y menos margen para contratar especialistas por cada capa del stack. Una empresa en Ciudad de México, Bogotá, Lima o Quito puede terminar operando con un equipo de 5 a 12 personas que hace desarrollo, soporte, despliegue, seguridad básica y análisis de incidentes. Ahí cada nueva capa se siente el doble.

Cuando el stack crece, también crece la dependencia de conocimiento implícito. Si solo una persona entiende cómo funciona el pipeline o cómo se recupera un servicio, la organización queda frágil. Y esa fragilidad no solo afecta velocidad; afecta continuidad. Si alguien se va, el sistema no se cae porque “faltó un dev”, se cae porque faltó la persona que sabía dónde estaba escondida la complejidad.

También hay un costo financiero directo. Más servicios administrados, más tráfico entre regiones, más almacenamiento de logs, más entornos de staging, más herramientas SaaS por asiento. A veces el presupuesto de software sube sin que el producto haya crecido en la misma proporción. Eso obliga a ingeniería a justificar cada herramienta con más precisión que antes.

Qué pasa cuando el presupuesto aprieta

Cuando el presupuesto es limitado, el equipo no puede absorber la complejidad con más personas. Entonces aparecen decisiones incómodas:

• Reducir herramientas y perder comodidad.
• Aceptar deuda técnica para no frenar entregas.
• Concentrar conocimiento en pocas personas.
• Postergar observabilidad o automatización.

Ninguna de esas opciones es ideal. Pero fingir que no existen solo empeora el problema. La torre sigue creciendo igual; la diferencia es si la estás administrando o solo la estás mirando.

Cómo bajar la complejidad sin vender humo

No hay una receta mágica, pero sí prácticas concretas que ayudan a que la torre no se descontrole. La clave es tratar la complejidad como un recurso caro, no como una consecuencia inevitable de “hacer software serio”.

Primero, limita el número de piezas nuevas que introducís por trimestre. No necesitas adoptar tres herramientas de observabilidad, dos frameworks y un nuevo orquestador en el mismo ciclo. Cada cambio de plataforma exige aprendizaje, migración y soporte. Si no lo haces con ritmo razonable, conviertes al equipo en una academia permanente.

Segundo, documenta las decisiones que agregan dependencia. No solo el “qué”; también el “por qué”. Cuando alguien pregunte por qué usan cierto proveedor o cierta arquitectura, debería encontrar la respuesta en cinco minutos, no en una reunión con tres personas que ya no trabajan juntas.

Tercero, mide el costo del sistema, no solo su rendimiento. Un servicio puede responder rápido y aun así ser caro de operar, difícil de depurar o lento de cambiar. Si solo miras latencia y throughput, te quedas corto.

Un checklist práctico para revisar tu stack

Antes de aceptar una nueva capa, revisa esto:

• ¿Qué problema concreto resuelve y con qué frecuencia aparece?
• ¿Qué parte del sistema se vuelve más difícil de entender?
• ¿Quién va a mantenerla en 6 y en 12 meses?
• ¿Qué pasa si la herramienta falla o cambia de precio?
• ¿Qué métrica va a mejorar y cómo la vas a verificar?

Si no puedes responder esas preguntas con claridad, probablemente no estás simplificando. Solo estás moviendo la complejidad a un lugar menos visible.

Tabla resumen

Lo que conviene recordar

La torre del software no deja de crecer porque el mercado no premia la pureza técnica. Premia velocidad, confiabilidad y capacidad de adaptación. Para conseguir eso, seguimos agregando capas. El problema no es que existan. El problema es fingir que cada capa simplifica gratis.

Si trabajas en ingeniería, te conviene mirar el stack como un balance, no como una lista de herramientas. Cada decisión técnica tiene un costo operativo, humano y financiero. Y cuando ese costo se oculta, termina saliendo por otro lado: incidentes, rotación, retrasos o facturas que nadie esperaba.

La buena ingeniería no es la que promete una torre más baja. Es la que sabe cuándo una capa vale la pena y cuándo solo está agregando peso.

Tabla resumen