Tanto para los desarrolladores como para la dirección de una empresa, la deuda técnica es una cuestión primordial. Un código obsoleto, una implementación mal consolidada puede generar mucha complejidad, costos elevados y problemas que deben ser compensados con esfuerzos adicionales. Como proveedor de servicios en la nube reconocido en toda Europa, nos enfrentamos a este reto constantemente. En este artículo, compartimos nuestra experiencia en este tema a través de uno de los productos estrella de nuestra suite de herramientas de productividad en línea, la interfaz web que te permite gestionar tu correo electrónico en línea.

La deuda técnica a menudo se deja de lado porque no genera valor inmediato para la empresa, pero puede convertirse rápidamente en un peso muerto que impide el progreso futuro. Julien Arnoux, VP of Engineering

La deuda técnica: una bomba de tiempo que puede tener un impacto crítico en el negocio 

Las nuevas funciones siempre tienen buena acogida en el mercado. Así que a menudo aceleramos, haciendo caso omiso de las partes antiguas del código de las que «nos ocuparemos más tarde». Pero cuando los objetivos empresariales barren la calidad del código debajo de la alfombra, esto es lo que pasa:

Entre los desarrolladores: frustración

Cada iteración aumenta la deuda. Sin embargo, seguimos evolucionando sobre bases de software creadas hace X años y que ya no corresponden necesariamente a las necesidades actuales. No se pueden utilizar los últimos lenguajes, las máquinas en preproducción no son idénticas a las máquinas de producción… Nos imponemos prácticas anticuadas con bloqueos que se multiplican y el riesgo de errores también. Así que no tocamos nada por miedo a romperlo todo. La montaña de tareas de ingeniería crece, el estrés vence a los equipos que pierden ingenieros debido a la dificultad del trabajo.  

Por parte de los gerentes: incomprensión

Por lo general, los problemas se resuelven con soluciones rápidas, pero ahora se necesitan dos semanas para cambiar los botones de la interfaz. Para tratar de alcanzar plazos poco realistas, se presiona a los desarrolladores que «carecen de rigor» cuando tienen que lidiar constantemente con problemas técnicos y bugs. La productividad cae y la motivación se resiente.

Para la dirección: nada va lo suficientemente rápido

El dinero y la viabilidad están en juego. ¿Por qué se tarda tanto en entregar valor? ¿Por qué el sitio web es lento? ¿Por qué modernizar el código cuando no resuelve ninguno de los problemas expresados por los clientes? Por ejemplo, los responsables de la toma de decisiones pueden sentirse tentados a compensar las ralentizaciones con una solución inmediata, como añadir potencia de servidor, sin resolver la deuda técnica subyacente que seguirá afectando cada vez más a la calidad del código a largo plazo.

Las cifras hablan por sí solas: en las empresas, la deuda técnica representaría entre el 10% y el 20% de los costes de cada proyecto, la resolución de problemas de hasta 13,5 horas/semana por empleado y aproximadamente el 30% del presupuesto anual de informática.

Si no encontramos el equilibrio, vamos directos a la pared. Los riesgos son claros:

  • Pérdida de velocidad
  • Problemas de seguridad
  • Desmotivación de los equipos (técnica y producto)
  • Programas informáticos de baja calidad

Pero, ¿de qué hablamos exactamente cuando decimos deuda técnica?

La deuda técnica es la diferencia entre el código actual y lo que debería ser idealmente. Por lo tanto, cuanto más malo es el software, mayor es la deuda.

Es inevitable, ya sea intencional o no. 

Se puede sacrificar la calidad del código para obtener un beneficio, por ejemplo, si el time to market (tiempo de comercialización) es muy corto o si un retraso en el lanzamiento de una nueva versión es financieramente insostenible. En este caso, el endeudamiento es intencional, pero la mayoría de las veces no lo es, porque la deuda técnica es inherente a nuestro oficio.

Aumenta con cada línea de código 

Cuanto más avancemos en las iteraciones, mayor será la complejidad del software y el desorden.

El primer problema es la complejidad esencial de nuestra profesión. En el caso del Servicio de Correo, esto significa poder interactuar con un servidor de correo de forma rápida y eficiente y proporcionar una API que pueda ser consumida por una aplicación web y aplicaciones móviles.

Luego viene la complejidad accidental con los problemas causados por la mala calidad del código. También depende de las opciones técnicas que se adopten, por ejemplo:  Durante la remodelación de la versión anterior del Servicio de Correo, parte de la base de código fue recuperada de la primera versión escrita hace más de 15 años. Esta usaba un sistema de almacenamiento diferente para los correos electrónicos. Por lo tanto, hemos heredado un montón de complejidad innecesaria a pesar de que hace mucho que no usamos este sistema.

Y por último, el desorden natural (entropía de software). Se empieza con una base de software simple, a la que se añaden módulos a medida que la aplicación se va desarrollando. La lógica termina enredándose y se vuelve difícil de entender, especialmente si un desarrollador deja el equipo. Nos encontramos con fragmentos de código que ya no sirven para nada, pero que aumentan la complejidad:

Qué sucede cuando la deuda técnica se acumula

Terminamos gastando más tiempo en compensar las dificultades que en crear funcionalidades y realmente agregar valor al software:

Entonces, ¿cómo hacer frente a la deuda técnica?

Es una cuestión de equilibrio, el compromiso entre calidad y coste, es casi el dato básico en el desarrollo de software.

Empezar por hacerla visible

Es importante convencer a todo el mundo: a los colegas, al gerente, a la dirección. ¿No es tan fácil? Es esencial traducir la deuda técnica para los gerentes y CEO explicando los siguientes puntos:

  • demostrar que los beneficios a corto plazo ponen en peligro la competitividad a largo plazo;
  • explicar que los problemas técnicos se convertirán en pérdidas de clientes;
  • sensibilizar sobre el hecho de que el código obsoleto reduce la previsibilidad y hace que el proyecto sea opaco.

«Modernizar el código no es un esnobismo de desarrollador». Es una necesidad para el negocio.

Los equipos que reducen su deuda técnica liberan hasta un 50% más de tiempo para crear valor.

Detener el sangrado para evitar la acumulación actual

No vamos a cambiar la cultura de un equipo de la noche a la mañana, pero debemos ser conscientes de los factores agravantes para minimizarlos:

  • plazos insostenibles
  • definición errónea de la necesidad
  • mala organización de la empresa (compartimentalización de los equipos)
  • falta de conocimientos profesionales
  • técnicamente: malas prácticas, falta de doc, over-engineering, falta de pruebas, etc. 

3 principios que también pueden agravar la deuda:

  • No hay una solución milagrosa. Los frameworks que prometen resolver todos los problemas no existen.
  • Evitar el mimetismo: «Netflix hace microservicios», «Google está en monorepo». Hacer lo mismo que los demás «porque lo hacen» no producirá los resultados esperados en un contexto diferente (ver Culto cargo). 
  • El síndrome de la ventana rota: es la idea de que si dejas una ventana rota en un edificio sin repararla, esto incitará a la falta de civismo y la degradación de otras ventanas del edificio, luego de las paredes, luego del barrio, etc. Esto es muy común en el software: uno no duda en empujar un trozo de código mediocre si el estado general del código ya es malo y termina con una montaña de código espagueti que mantener.

Algunos principios a seguir para evitarlo:

  • La regla del boy scout: mantener el campo (código) tan limpio después de nuestro paso como lo encontramos al llegar. Pensemos en los demás 😉 
  • K.I.S.S. : Keep it simple stupid (hacerlo sencillo es complicado, pero hazlo de todos modos).
  • Y.A.G.N.I. : You ain’t gonna need it (a los desarrolladores se nos da muy bien añadir cosas «por si» las necesitamos …) 
  • D.R.Y. : Don’t repeat yourself (en lugar de duplicar el código, tratamos de factorizarlo de otra manera).

En general, las técnicas de craft son un buen recurso.

¿Cómo puedo amortizar la deuda técnica existente?

Vamos al grano. Si queremos tener el máximo impacto: 

  1. Identificar las áreas de riesgo para la deuda técnica.
  2. Ilustrar los beneficios de abordarlas
  3. Categorías: seguridad, mantenimiento, automatización, quality assurance, continuous integration…
  4. Priorización de las deudas técnicas en función de su impacto
  5. Tratar

Por ejemplo:

  • «Tengo una dependencia obsoleta desde hace 6 meses. Ya no se mantiene y potencialmente hay agujeros de seguridad».
  • El beneficio: «potencialmente evitar agujeros de seguridad».
  • Después, se aborda esta cuestión en relación con las demás deudas identificadas en función de las prioridades y el impacto previsto. 

Invertir periódicamente para reducir la deuda existente 

Gracias al trabajo de identificación, se puede planificar la amortización de la deuda técnica e integrarla en la hoja de ruta del producto/servicio. Por lo tanto, esto se hace con el Product Owner o el Product Manager.

¿Amortizarla toda? Es una cuestión de medida.

La deuda técnica es una carrera de fondo. La búsqueda de la pureza del código a toda costa es completamente inútil, pero el énfasis en la calidad contribuye en gran medida al potencial de desarrollo. No tener un software endeudado atrae a los desarrolladores en lugar de ahuyentarlos. Lo mejor que se puede hacer es reevaluar la deuda periódicamente para ajustar los controles deslizantes y seguir siempre el camino correcto.

Más información

El seminario web completo sobre la deuda técnica:

Esta conferencia explica qué es la deuda técnica, sus orígenes, los riesgos que conlleva y cómo prevenirla y pagarla. Julien Arnoux es VP of Engineering en Infomaniak. Lleva más de 15 años navegando por la tecnología; primero como desarrollador, luego como desarrollador principal y finalmente como VP. Ha podido observar los diferentes aspectos del desarrollo de productos web desde la tecnología hasta la organización.