La metáfora de la “deuda técnica” aplicada al desarrollo software la introdujo hace dos décadas Ward Cunningham para explicar a los “no técnicos” la necesidad de “refactorizar”. Desde entonces, la deuda técnica se ha utilizado para describir muchos otros tipos de deudas o males del desarrollo de software, y se ha aplicado a cualquier cosa que aumente innecesariamente los esfuerzos de desarrollo, se interponga en la futura evolución o venta de un sistema de software. Hoy podemos encontrar la deuda de las pruebas, la deuda de las personas, la deuda de la arquitectura, la deuda de los requisitos, la deuda de la documentación, etc.
La deuda técnica es el coste y los intereses a pagar por hacer mal las cosas. El sobre esfuerzo a pagar para mantener un producto software mal hecho, y lo que conlleva, como el coste de la mala imagen frente a los clientes, etc.
Hay quien no es ni siquiera consciente de que está pagando intereses por hacer mal el software, y continua así hasta el “default”. La deuda técnica al final siempre alguien la paga. O la paga el proveedor que desarrolla el software o la paga el cliente que lo usa o compra.
Principal causa de la deuda técnica: la presión de las fechas
La mayoría de los autores coinciden en que la principal causa de la deuda técnica es la presión en fechas y planes. Sin embargo, hay muchas otras causas, como la falta de cuidado, falta de educación, procesos pobres, la no verificación de la calidad, o la incompetencia.
¿Qué es exactamente la deuda técnica? Algo que resta valor al producto software y que no se ve…
Con el tiempo, el término deuda técnica se ha perfeccionado y ampliado, principalmente por Steve McConnell con su taxonomía y Martin Fowler con .
La pequeña taxonomía de McConnell, habla de que:
– No hay deuda técnica, si… Hay retrasos, recortes, etc., que no requieren el pago de intereses. No todo el trabajo incompleto es deuda.
– Si hay deuda técnica… puede ser (I) Deuda incurrid involuntariamente debido a trabajos de baja calidad o (II) Deuda incurrido intencionalmente.
Dándole una vuelta más al término, la figura de abajo muestra cuatro tipos de posibles mejoras o tareas a realizar en el futuro para aumentar el valor del producto software, como pueden ser ampliar funcionalidad (color verde, que es en lo que suelen fijarse las empresas), o invertir en arquitectura (amarillo), invertir reducir los defectos (rojo) o la deuda técnica (negro), que es invisible y tiene un efecto negativo.
Las herramientas de calidad de código no son suficiente
Es importante tener en cuenta, sin embargo, que la deuda técnica no es sólo algo a mejorar, o evitar, sobre el código o sobre la calidad del código. Por ello, las herramientas de análisis de código identifican un pequeño número de elementos asociados a deuda técnica.
Las herramientas de análisis de código no son suficiente para la identificación de la deuda técnica. La mayoría de las veces, la deuda técnica no se relaciona con código y sus cualidades intrínsecas, sino a opciones estructurales, arquitecturales o brechas tecnológicas. Ninguna herramienta revelará que, hace dos años, el equipo implementó una arquitectura inapropiada.
En el siguiente vídeo, podemos ver a Javier Garzás dando una explicación sobre la deuda técnica, espero que sea de vuestro interés.
Comentarios
Publicar un comentario