Los 6 tipos de deuda técnica - Parte II

Eche un vistazo a la primer post de esta serie donde exploramos qué es la deuda técnica, si siempre es algo malo y las estrategias para gestionarla y segunda parte de esta serie donde explicamos cuatro tipos de deuda técnica: deuda de decisión, deuda de eficiencia de los desarrolladores, deuda de mantenimiento y deuda de estabilidad, y ofrecemos ejemplos reales de problemas y soluciones para cada tipo.

¡Ahora, volvamos a sumergirnos! La deuda técnica adopta diversas formas, y las empresas pueden tener problemas con varios tipos de deuda al mismo tiempo. Analicemos los dos últimos tipos de deuda técnica: #5: deuda de seguridad y #6: deuda de productos técnicos

#5: Deuda de seguridad

¿Qué es?

La deuda de seguridad se produce cuando se toman atajos y los equipos técnicos no evalúan completamente todos los resultados posibles, lo que deja a los sistemas vulnerables a las amenazas de seguridad.

La seguridad ha asumido un papel fundamental. Las empresas deben cumplir con las normativas y proteger activamente los datos confidenciales para que no caigan en malas manos. Los datos se han convertido en una nueva moneda mundial, lo que los convierte en un objetivo para las personas que buscan aprovechar las vulnerabilidades del sistema.

¿Qué aspecto tiene?

Un indicio común de la deuda de seguridad son las violaciones de datos. Se producen cuando los equipos no abordan las vulnerabilidades conocidas, lo que deja sus sistemas expuestos. Equifax, Yahoo, y Objetivo son todos ejemplos reales de deuda técnica de seguridad. Sus infracciones enfatizan la necesidad de soluciones oportunas, prácticas de seguridad sólidas, firewalls configurados e infraestructuras de nube seguras.

¿El denominador común en todos estos casos? Millones de dólares en costos y daños inestimables a la reputación.

#6: Deuda técnica por productos

¿Qué es?

En lo que respecta a la deuda técnica, el mismo principio se aplica al producto en sí, pero hay un giro diferente. De hecho, este tipo de deuda puede ser más fácil de detectar, ya que su impacto suele repercutir directamente en el usuario final. Es lo que llamamos deuda «orientada al exterior», y es difícil ignorar sus repercusiones. Se trata de la deuda que afecta a la experiencia del cliente al utilizar el producto.

Sin embargo, si bien la deuda externa puede ser más notoria, eso también significa que puede tener un gran impacto en sus resultados. Cuando los usuarios tienen problemas o fallas con tu producto, esto puede erosionar la confianza y la lealtad, lo que lleva a una pérdida de ingresos y oportunidades.

¿Qué aspecto tiene?

Este tipo de deuda se manifiesta en forma de quejas de los clientes sobre tiempos de carga lentos o fallos en el producto. Podemos ver ejemplos reales de esto por todas partes, ya que empresas como Facebook, Amazon y Twitter han recibido críticas en el pasado por problemas técnicos. Estos problemas suelen surgir cuando las empresas añaden nuevas funciones, lanzan productos o experimentan un uso intensivo durante los períodos de mayor actividad.

Pagar la deuda técnica en la industria de la logística

Al igual que en nuestra última publicación, profundizaremos en estos dos tipos de deuda técnica con un ejemplo real de una empresa que se ocupa de ellos y algunas medidas adoptadas por Mutt Data para hacer frente a dicha deuda. Este es un resumen de nuestro trabajo reciente en el sector de la logística.

Deuda de seguridad

Cuando se construye una startup desde cero, el desarrollo va a la velocidad de la luz. Constantemente se prueban nuevas funciones, algunas se descartan y otras se convierten en el producto final (¡al menos hasta que se produzca un cambio!).

Si bien se trabaja a esta velocidad vertiginosa, es difícil saber si los sistemas creados son robustos, escalables y seguros. En Mutt Data estamos acostumbrados a lanzarnos a este tipo de proyectos, y tenemos nuestras formas de comprobar si un sistema es seguro. ¡Resulta que este proyecto logístico tenía varios problemas de seguridad en su código base!

Para resolver esta deuda, contamos con la ayuda de Bandit, que señaló estas vulnerabilidades automáticamente y las solucionó una por una. Para evitar que se repitieran problemas de seguridad, creamos un canal de CI/CD que ejecutaba Bandit antes de cada implementación: ¡ahora solo puedes publicar tu código si es realmente seguro!

TLDR: cuando se construye demasiado rápido, es común dejar que la seguridad pase a un segundo plano. Utilice herramientas automatizadas para comprobar la seguridad de su proyecto y evitar estas vulnerabilidades antes de que lleguen a la fase de producción.

Deuda técnica por productos

Esta startup creó un impresionante sistema logístico desde cero en poco tiempo. Pero al igual que con Security Debt, ir demasiado rápido tiene sus inconvenientes: te deja poco tiempo para diseñar un sistema eficiente y escalable.

Las decisiones de diseño tomadas al principio del desarrollo afectaban tanto a los usuarios finales (que sufrían una latencia muy larga al interactuar con el sistema) como a los analistas (que tenían que esperar horas para recibir un informe sencillo). Nos dimos cuenta de que esto sucedía porque los usuarios finales y los analistas utilizaban la misma base de datos. La infraestructura de datos inicial que creó la empresa emergente no era lo suficientemente escalable para el enorme crecimiento que tenían.

Para resolver esta deuda, implementamos nuestra pila de datos moderna (¡Lea nuestro nuevo! documento técnico sobre la pila de datos moderna (con recomendaciones de herramientas seleccionadas por expertos para cada componente). Pero no te preocupes: no es que tuviéramos que crear el MDS completo para aprovechar sus beneficios: la creación de sus primeros componentes fue suficiente para tener un enorme impacto tanto en los usuarios como en los analistas.

TLDR: la deuda técnica no solo afecta a los desarrolladores, sino que también afecta a los usuarios finales. Las decisiones de diseño tomadas al inicio del proyecto no eran escalables debido a su enorme crecimiento. Pero no es demasiado tarde para crear sistemas más apropiados, que con pequeños cambios pueden tener un gran impacto en la experiencia del usuario.

Impacto final

• La seguridad ya no es una cuestión de segundo plano: las herramientas automatizadas ayudaron al cliente a saber si su proyecto era seguro.
• Uso del Pila de datos moderna nos ayudó a ampliar su producto tanto para los analistas como para los usuarios finales: basta con crear la primera etapa del MDS para reducir la latencia de los usuarios que utilizan la aplicación y de los analistas que consultan los datos.

¡Esperamos que hayas disfrutado de toda la serie! Si estás buscando publicaciones similares, aquí tienes algunas recomendaciones:

• Cómo desentrañar la deuda técnica: los costos ocultos de tomar atajos
• Los 6 tipos de deuda técnica, parte I
• Cómo el aprendizaje automático bajo demanda puede ahorrarle tiempo y dinero a su empresa
• Es hora de llamar a su médico de datos: Llegando al fondo del asunto: ¿está solucionando el problema subyacente o simplemente tratando los síntomas?
• Preguntas frecuentes: ¿Qué es Cloud FinOps?