No me agrada el término “deuda técnica” porque a menudo se usa sin una comprensión clara del problema al que se refiere.
Investigando sobre la deuda técnica, encontré un par de artículos muy interesantes de Thoughtworks que me gustaría compartir y resumir:
Technical Debt Quadrant (2009) de Martin Fowler aborda la cuestión de que tipo de defectos deben clasificarse como deuda técnica. ¿Un código desorganizado sin buenas practicas de diseño debe considerarse deuda técnica?
El autor sugiere que debemos clasificar la deuda en prudente e imprudente. La deuda prudente es aquella que se adquiere de manera consciente y se evalúa si el beneficio a corto plazo justifica los costos a largo plazo. Por otro lado, la deuda imprudente es aquella que se adquiere sin considerar sus implicaciones.
Además, plantea una distinción entre deuda deliberada e inadvertida. La deuda deliberada es cuando un equipo conoce las buenas prácticas de diseño, pero decide hacer un código “rápido y sucio” debido a limitaciones de tiempo. La deuda inadvertida ocurre cuando un equipo, a pesar de haber hecho un buen trabajo, se da cuenta después de terminar el proyecto de cuál debería haber sido el enfoque de diseño adecuado.
El autor concluye que es importante reconocer y abordar la deuda técnica prudente e imprudente para mantener la calidad del código y la eficiencia en el desarrollo de software.
Accumulation of tech debt (2022) de Tim Cochran y Carl Nygard explora los tipos de deuda técnica, define indicadores para alternarnos si es un problema y ofrece estrategias para reducir sus efectos negativos.
El artículo comienza contextualizando la deuda técnica en el ámbito de las startups donde es necesaria e incluso deseable. Sin embargo, al momento de escalar puede convertirse en un factor que limite el crecimiento a menos que se mantenga un sano balance entre deuda e inversión técnica.
Los autores clasifican la deuda técnica en 10 tipos:
- Calidad del código: Código frágil, difícil de entender o mal documentado. Modelos de datos que no cuadran con el modelo de negocio.
- Pruebas: Falta de pruebas unitarias, de integración o una mala distribución de pruebas evita que los desarrolladores conozcan rápidamente si su código afecta funcionalidades existentes.
- Acoplamiento: Diferentes equipos pueden bloquearse mutuamente por dependencias entre módulos.
- Funcionalidades sin uso o de bajo valor: Implican más complejidad y casos extremos que considerar que conlleva a código más difícil de trabajar.
- Bibliotecas o frameworks obsoletos: Impide aprovechar sus mejoras e implica riesgos de seguridad. Dificulta la incorporación de nuevos colaboradores.
- Herramientas ineficientes: Conllevan fricción y sobrecarga al equipo de desarrollo.
- Problemas de confiabilidad y rendimiento: Afectan la experiencia del usuario y la capacidad del negocio para escalar.
- Procesos manuales: La falta de automatización en procesos frecuentes requiere esfuerzo y tiempo del equipo constantemente.
- Despliegues automatizados: Pequeños despliegues incrementales facilitan la entrega de software experimental. Debes tener la capacidad de desplegar a voluntad al menos una vez al día.
- Compartir conocimiento: La falta de información dificulta incorporar nuevos colaboradores o al equipo actual trabajar fácilmente diferentes partes del desarrollo.
También los autores advierten que cuando se habla de deuda técnica en las startups con frecuencia se refieren a falta de funcionalidad en su plataforma técnica, lo que requiere un trato diferente.
Respecto a las señales para determinar si la deuda técnica es un problema, el artículo propone:
- Tiempo para la entrega de funcionalidad: Examinar de extremo a extremo el proceso para la entrega de funcionalidad y como ha evolucionado, revelara la fricción entre la deuda técnica y otros problemas.
- Impacto al usuario final: Latencia en sistemas, tiempo de incorporación de usuarios y problemas de calidad afectan a los clientes y un problema técnico podría ser la causa.
- Satisfacción de desarrolladores: Escuchar las quejas del equipo sacara a la luz problemas de la plataforma técnica para priorizar y abordar.
- Capacidad para incorporar nuevos desarrolladores: Observar el proceso de incorporación y la satisfacción de nuevos colaboradores puede revelar problemas que el equipo actual tiene el habito de evitar.
- Degradación de métricas: Costos de infraestructura, tiempo de ejecución, rendimiento y disponibilidad pueden ser indicadores indirectos de una deuda técnica excesiva que afecta los resultados del negocio.
Una serie de desiciones hechas bajo presión pueden hacer que una empresa termine con mucha deuda técnica. Los autores previenen que es natural los desarrolladores utilicen el estado actual como indicador de lo que es aceptable, generando más deuda.
Para salir de la deuda técnica, los autores recomiendan:
- Definir un estándar de calidad. Al principio puede ser complicado pero en lugar de abandonar la práctica utilizar los comentarios al respecto para orientar la inversión en capacidad del equipo.
- Limitar el radio de alcance. Al tomar atajos limitar su posible impacto al negocio. Microservicios y desacoplamiento de sistemas puede ayudar pero se debe hacer con moderación ya que agregan latencia y complejidad los sistemas.
- Colaboración entre producto e ingeniería. Sin conversaciones para equilibrar las metas del negocio, producto e ingeniería lo primero que se degrada es la calidad técnica y como resultado la del producto.
- Una estrategia para limitar el impacto de la deuda técnica. Dependiendo de la etapa del negocio (experimentación, tracción, crecimiento u optimización) se debe invertir en diferentes aspectos de la plataforma, infraestructura y equipo.
Por último, el artículo ofrece varios consejos para que, dependiendo del contexto, abordar la deuda técnica:
- La estrategia debe basarse en información disponible al equipo como el rendimiento empresarial, dirección del producto o la opinión de los clientes.
- A medida de que crecen los equipos se vuelve difícil encontrarle un propietario al código antiguo. Debemos asegurarnos todos los sistemas tienen propietario.
- Empoderar a los desarrolladores a resolver problemas en su día a día. Negociar un balance entre desarrollar nueva funcionalidad y resolver deuda técnica con los dueños de producto. Definir un proceso para abordar y supervisar continuamente la deuda técnica.
- Implementar métricas para usarlas como guías en la toma de desiciones sobre la deuda técnica. Desarrolladores experimentados pueden aportar valor interpretando datos y basando su intuición en información cualitativa fundamentada en hechos.
- Debe existir un balance entre procesos y autonomía. Comprobaciones automáticas o revisiones entre pares puede ayudar a cumplir políticas y apoyar a los desarrolladores.
Y a manera de conclusión, los autores comparten que adoptar un enfoque iterativo y permitir que las métricas combinadas con el desarrollo de software guíen la inversión para resolver la deuda técnica produce mejores resultados.
En mi opinión, la deuda técnica en el desarrollo de software es el impacto a futuro de las desiciones que tomamos en el presente con limitantes de tiempo y conocimiento.
Al igual que en las finanzas, el propósito de la deuda técnica es obtener beneficios a corto plazo que deben pagarse con intereses en el futuro. Para que adquirir esta deuda tenga sentido, es esencial que los beneficios a largo plazo superen los intereses generados.