En este artículo explicamos qué es la deuda técnica, también conocida como deuda tecnológica o deuda de código. Este concepto se define como el resultado de tomar medidas para acelerar la entrega en los equipos de desarrollo de un proyecto que luego debe ser refactorizado. Se da prioridad a un proceso de desarrollo rápido en detrimento del código, dando así más peso a la entrega rápida frente a un código de calidad. En resumen, con el término deuda técnica nos referimos a una situación en la que los desarrolladores escriben software que infringe las buenas prácticas relacionadas con la arquitectura, la estructura del código, los patrones de diseño o los estándares para la creación de ciertos mecanismos, entre otras cosas, en pos de una mayor rapidez en el desarrollo del proyecto.
Este término es muy usado en en la industria del software por programadores, gerentes de proyectos o gerentes de empresas. A veces, las empresas no son conscientes de las consecuencias negativas que tiene el subestimar la deuda tecnológica, ya que ralentiza la capacidad de ofrecer funciones futuras y genera un costo de oportunidad por una eventual pérdida de ingresos.
Para evitar esta situación, los líderes de equipo deben monitorear cuánta deuda técnica adquieren y aprender a gestionarla de manera correcta.
Lo que vas a ver en este post:
Origen del término “deuda técnica”
El término deuda técnica fue acuñado originalmente por el estadounidense Ward Cunningham en 1992. Cunningham es un desarrollador de software y se le atribuye la invención del primer software wiki. Está considerado como un pionero en patrones de diseño y eXtreme Programming, además de ser uno de los 17 autores del Manifiesto Ágil.
El autor describió el el concepto de deuda técnica de la siguiente manera:
“Enviar código por primera vez es como endeudarse. Un poco de deuda acelera el desarrollo siempre que se pague rápidamente con una reescritura. Los objetos hacen que el costo de esta transacción sea tolerable. El peligro ocurre cuando la deuda no se paga. Cada minuto dedicado a un código incorrecto cuenta como interés sobre esa deuda. Organizaciones de ingeniería enteras pueden paralizarse bajo la carga de la deuda de una implementación no consolidada, orientada a objetos o de otro tipo «.
El proceso de desarrollo apresurado significa que la base del código tendrá ciertas deficiencias que un programador tendrá que volver a trabajar o limpiar más adelante. Estas deficiencias, también llamadas «cruft«, afectan a la calidad general del código y, aunque el software aún puede funcionar, no puede alcanzar su máximo potencial hasta que alguien corrija las deficiencias. Arreglar el problema, entonces, es como pagar intereses por un préstamo financiero: es el precio que se paga por acelerar el proceso y descuidarlo puede tener efectos realmente negativos.
Cunningham había acuñado una nueva palabra que sería muy utilizada por la comunidad del software y que daría como resultado muchos estudios académicos y debates.
Tipos de deuda técnica
Han sido muchos los profesionales de desarrollo de software que han buscado nuevas formas de describir y clasificar la deuda técnica.
Steve McConnell, en el año 2007, habló de dos tipos de deuda técnica:
· Intencional
· No intencional
Sugirió que la deuda técnica intencional es una deuda técnica que se asume conscientemente como herramienta estratégica. Por otro lado, la diferenció de la deuda no intencional, que describió como «el resultado no estratégico de hacer un mal trabajo».
Posteriormente, Martin Fowler llevó el concepto de McConnell un paso más allá y publicó lo que él llama el » Cuadrante de deuda técnica «. Este cuadrante categoriza la deuda técnica en cuatro tipos según la intención y el contexto. Este autor clasifica la deuda técnica primero en función de la intención, es decir, si es deliberada o accidental. Asimismo, distingue si trata de una deuda prudente o imprudente.
Principales causas de la deuda técnica
Como hemos indicado al principio de este post, las principales causas de la deuda técnica pueden ser varias:
· Definición inicial del proyecto insuficiente, donde los requisitos todavía se están definiendo durante el desarrollo.
· Falta de colaboración entre equipos
· La falta de procesos objetivos de revisión de códigos.
· Presupuesto ajustado y presión de tiempo.
· Falta de documentación.
· Refactorización retrasada.
· Complejidad del código
· Estimación deficiente de lanzamientos de productos
· No seguir las mejores prácticas o patrones estándar de la industria
Cómo evitar la deuda técnica
Completar un proyecto de software rápidamente sin incurrir en algún nivel de deuda técnica es un desafío. Ningún equipo escapa de la deuda técnica. Pero hay formas de evitarla para que no se convierta en un lastre demasiado grande. Existen medidas para prevenir o reducir la creación y el crecimiento de la deuda:
· Algo fundamental es dar tiempo al equipo para mejorar continuamente el código. Además, no permitiendo esto, la moral del equipo se puede ver afectada y también su productividad.
· Es importante tener una estrategia que administre la deuda con prudencia y minimice la deuda imprudente.
· Disponer de las personas adecuadas en roles de alto impacto y tener claras las responsabilidades y distribución de tareas en equipos
· Capacitar al equipo para que conozca la plataforma.
· Realizar procesos estandarizados para la refactorización y la gestión de calidad.
· Hacer un buen uso de patrones fuertes y detectables mediante división en clases, métodos comprensibles.
· Uso de herramientas actualizadas para medir y analizar los errores.
Conclusión
Una de las maneras de controlar la deuda técnica es crear conciencia sobre esta, tanto en el la parte comercial como en los equipos de desarrollo de software. La deuda tecnológica debe gestionarse adecuadamente para minimizar el riesgo asociado. Una de las maneras más efectivas es utilizar herramientas como Sentrio porque te permite visualizar, analizar y mejorar el flujo de trabajo en el desarrollo de proyectos de software con vistas a mejorar la productividad, detectar bloqueos y reducir la deuda técnica. Se integra no sólo con soluciones y herramientas estándar (Jira, Jenkins, Bitbucket, Sonarqube, etc), sino también con tus herramientas propietarias. Si quieres conocer más sobre Sentrio, contacta con nosotros.
