AXENTED — Blog Article
Slug: /blog-posts/hidden-costs-bad-software-architecture |
Meta description: La mala arquitectura no aparece como un problema técnico — aparece como entrega lenta, facturas de infraestructura en aumento y dificultad para contratar. El desglose del costo real. |
Target keywords: costo mala arquitectura software, problemas arquitectura software, costo deuda técnica, beneficios revisión arquitectura |
La deuda técnica es fácil de desestimar como una preocupación de ingeniería. No lo es. Los costos de mantener una arquitectura deficiente aparecen en lugares que parecen problemas de negocio: entrega lenta de funcionalidades, facturas de infraestructura en aumento, dificultad para contratar e incapacidad de responder rápidamente a los cambios del mercado. Para cuando esos costos son obvios para las partes interesadas no técnicas, llevan años acumulándose.
Este es un intento de ponerle números a lo que la mala arquitectura realmente cuesta.
El costo más directo de una arquitectura deficiente es la velocidad de entrega. Una base de código donde los cambios en un área rompen confiablemente algo más requiere que los desarrolladores entiendan un sistema más amplio antes de tocar cualquier cosa. Una aplicación monolítica donde un cambio en el módulo de facturación requiere un redespliegue completo de todo el producto significa que una simple actualización de precios tarda un día en lugar de una hora.
La investigación de los programas accelerate-state-of-devops y nuestra propia experiencia en docenas de equipos de ingeniería sugieren que los equipos de alto rendimiento despliegan aproximadamente 200 veces más frecuentemente que los equipos de bajo rendimiento. La brecha no es principalmente de talento — es de arquitectura. Los equipos con sistemas modulares y bien diseñados pueden moverse más rápido porque el radio de blast de cualquier cambio está acotado. Los equipos con arquitecturas enredadas se ralentizan porque el costo de equivocarse es alto.
Los bugs en sistemas mal arquitecturados cuestan más de encontrar y más de corregir. Encontrar un bug requiere entender qué parte del sistema es responsable — en una base de código con límites poco claros, eso es una investigación no trivial. Corregirlo requiere confianza en que la corrección no introduce un nuevo problema en otro lugar — en un sistema estrechamente acoplado, esa confianza es difícil de obtener sin ejecutar la suite de pruebas completa, lo que puede tomar horas.
Un patrón común: un equipo que debería poder cerrar un bug en dos horas en cambio pasa ocho. Multiplicado por un equipo de diez ingenieros durante un año, la diferencia entre una arquitectura limpia y una desordenada puede representar fácilmente cientos de miles de dólares en productividad de ingeniería.
Cada nuevo ingeniero que contratas tiene que aprender tu sistema. El tiempo que tarda en volverse productivo es una función de qué tan comprensible es tu arquitectura. Un sistema bien documentado y modular con convenciones claras lleva a un nuevo ingeniero a contribuir productivamente en dos a cuatro semanas. Un monolito heredado sin documentación, patrones inconsistentes y conocimiento tribal disperso entre ingenieros de larga data puede tardar de tres a seis meses.
Si tu costo de ingeniería totalmente cargado es de $100,000 USD por ingeniero por año y tarda cuatro meses más de lo que debería incorporar a cada nueva contratación, estás gastando aproximadamente $33,000 USD por ingeniero en tiempo de incorporación extendido. Para un equipo que contrata cinco ingenieros por año, eso son $165,000 USD en costo oculto de incorporación.
Los sistemas mal diseñados a menudo tienen características de rendimiento deficientes. Una API que hace cinco consultas a la base de datos donde una bastaría genera cinco veces la carga de la base de datos. Un trabajo por lotes que procesa registros secuencialmente cuando podría paralelizarse tarda cinco veces más y retiene recursos que bloquean otro trabajo. Estas ineficiencias se manifiestan directamente en las facturas de infraestructura.
Hemos visto mejoras de arquitectura reducir las facturas de AWS en un 30–40% sin ningún cambio en la funcionalidad del producto — puramente eliminando consultas redundantes, corrigiendo problemas N+1 y agregando caché apropiado.
El mejor momento para abordar los problemas arquitectónicos es antes de que se acumulen. Las señales que indican que el momento es el correcto: la velocidad de entrega ha estado disminuyendo durante dos o más trimestres, el equipo está gastando más del 30% de la capacidad en mantenimiento, las interrupciones son recurrentes en lugar de eventos únicos, o estás planeando una expansión significativa del producto que requeriría que la arquitectura actual haga algo para lo que no fue diseñada.
Una revisión arquitectónica no tiene que significar una reescritura completa. La mayoría de las veces, una remediación dirigida de los dos o tres problemas arquitectónicos más costosos produce la mayoría del beneficio a una fracción del costo. El objetivo es un plan, no una base de código perfecta.
%20(1)-2.svg)
