La deuda técnica. Todo el mundo debería saber que la mala calidad software al final se paga

La metáfora de la “deuda técnica” aplicada al desarrollo software la introdujo hace dos décadas Ward Cunningham (aquí tienes un enlace al primer documento en que se citó) para explicar a los “no técnicos” la necesidad de «refactorizar» (te recomiendo este post sobre refactorización).
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. (te dejo un post sobre los costes de un mal proceso). 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 provedor que desarrolla el software o la paga el lciente 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 sus cuatro cuadrantes.
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 incurrida involuntariamente debido a trabajos de baja calidad o (II) Deuda incurrida 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 funcionalidades (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 suficientes

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.

Terminando…

Continuando con los símiles económicos, estoy deseando que alguien invente la prima de riesgo técnica de un software.
Alguna cosa más para que continúes. Recientemente ha salido un número en IEEE software sobre el término de deuda técnica, razón por la que me ha venido a la cabeza hacer este post, y del que he sacado muchas ideas para este post.

9 comentarios en “La deuda técnica. Todo el mundo debería saber que la mala calidad software al final se paga”

  1. Pingback: Bitacoras.com

  2. Interesante y oscuro tema es.
    Durante el pasado Agile Open Space 2012 Zaragoza) se dedicaron varias charlas a esta cuestión. Yo estuve en las de Pablo Bouzada (@pbousan) y Fernando Escolar (@fernandoescolar). Mis impresiones las resumí en este post #AOS2012 alea jacta est: http://blog.panel.es/?p=1142.
    El reconocimiento de la deuda era, de forma unánime, el primer paso. En la charla con Fernando nos comentó la curva «J» como forma de conseguir mover algunas mentes «directivas» para que «inviertan en amortizar deuda». Jura que funciona ;).
    Bueno, no me extiendo más. El tema es muy interesante, al nivel de … ¿qué legado estamos dejando en este mundo?.
    Saludos Javier.

  3. Hola Miguel Ángel,
    Muy buen y completo resumen el que nos dejas 🙂
    Lo de la deuda, como comentas, es una buena manera de intentar, o lograr, que los no técnicos nos entiendan!
    Saludos

  4. Pingback: 6+1 deseos navideños para el sector del desarrollo software - Javier Garzás, sobre calidad software y otros temas relacionados

  5. Pingback: Una selección de post escritos en 2012 que tienes que leer antes de empezar el 2013 - Javier Garzás, sobre calidad software y otros temas relacionados

  6. Carlos Manuel Fernández

    Gracias Javier, por recordarnos como influye la mala calidad del software. Como sabemos siendo el software el motor de la transformación digital y todo será software con IA.
    Gracias por tu conocimiento pragmático.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba