Definición
La deuda técnica es el coste futuro de haber hecho algo de la forma rápida en lugar de la forma correcta.
La metáfora financiera es de Ward Cunningham y funciona muy bien, sobre todo con quien tiene que aprobar presupuestos: puedes endeudarte a propósito para llegar antes al mercado, y eso puede ser una decisión de negocio excelente. Lo que no puedes es olvidarte de que la deuda genera intereses.
Los intereses aquí son concretos: cada cambio futuro sobre ese código cuesta más tiempo, tiene más riesgo de romper algo y desmoraliza a quien lo toca.
Los cuatro tipos
Martin Fowler los ordena en dos ejes —a propósito o sin querer, prudente o imprudente— y sirve para entender que no toda la deuda es igual:
Prudente y deliberada. "Sabemos que esto se hace mejor de otra forma, pero necesitamos entregar el jueves. Lo apuntamos y lo arreglamos después." Es deuda legítima y sana.
Imprudente y deliberada. "No hay tiempo para hacerlo bien." Sin plan de pago y sin apuntarlo. Es la que se acumula sin control.
Prudente e inadvertida. "Ahora que lo hemos terminado, vemos cómo se debería haber hecho." Aprendizaje. Inevitable y sana.
Imprudente e inadvertida. "¿Qué es una arquitectura?" Deuda por no saber, y la más cara de todas porque nadie sabe que está ahí.
Cómo se nota
No aparece en ningún informe, así que hay que reconocerla por síntomas:
- Las estimaciones se disparan. Lo que hace dos años era un día, hoy son tres.
- Cada arreglo rompe otra cosa. Señal de que las piezas están demasiado enredadas.
- Nadie quiere tocar cierto fichero. El miedo es el mejor indicador que existe.
- Montar el entorno es una odisea. También es deuda, aunque no sea código.
- Hace falta una persona concreta para ciertos cambios. Deuda de conocimiento.
- Copiar y pegar como método. Cuando duplicar es más barato que entender, algo está roto.
Ejemplo práctico
En mis proyectos hay deuda de los dos tipos, y prefiero contarla que fingir que no existe.
Deuda deliberada y anotada. En el CRM de IMDICA hay secciones que ejecutan un ALTER TABLE en cada carga de página para asegurarse de que una columna existe. Funciona, y es claramente peor que un sistema de migraciones. Se hizo así por velocidad en su momento. Está identificada, y cuando monté el panel de AEWorks lo hice desde el principio con migraciones versionadas — la deuda se pagó no repitiéndola.
Deuda inadvertida que apareció en una auditoría. Al revisar esta web encontré que 87 de 99 títulos superaban el largo que Google muestra, y que la portada no tenía ningún <h1>. Nadie lo decidió: se fue acumulando. Nada estaba "roto" —la web funcionaba— y sin embargo cada una de esas 99 páginas rendía menos de lo que podía.
Y deuda de despliegue, que es la que más me sorprendió. El script sube los ficheros por encima y nunca borra, por una buena razón: bajo el mismo dominio viven aplicaciones con datos reales. La consecuencia no prevista es que lo que se subió una vez se queda para siempre. Me encontré 24 MB de un panel privado publicado meses atrás. La decisión era correcta; el interés de esa decisión era una limpieza periódica que nadie estaba haciendo.
Cómo gestionarla
- Anótala. Deuda no escrita es deuda que nadie va a pagar. Un fichero con la lista, o incidencias marcadas.
- Ponle precio en tiempo. "Esto nos cuesta media jornada cada vez que tocamos pedidos" convence mucho más que "el código está feo".
- Págala donde duele. No hace falta arreglarlo todo: arregla lo que estás tocando ahora. El código que nadie abre puede seguir feo indefinidamente.
- Reserva una parte fija. Un porcentaje de cada semana. Sin hueco reservado, la deuda siempre pierde contra lo urgente.
- Aprovecha los cambios. Vas a tocar ese módulo igualmente: refactoriza antes de añadir.
Errores comunes
- Usar el término para justificar código malo. Deuda es una decisión consciente con un plan. Sin plan, es solo desorden.
- Querer llegar a deuda cero. No existe y no es el objetivo. El objetivo es que no crezca más rápido que tu capacidad de pagarla.
- Reescribirlo todo. Es declararse en bancarrota y empezar de cero, con la garantía de generar deuda nueva.
- No contársela a quien decide. Si el negocio no sabe que existe, no entenderá por qué de repente todo tarda el doble.
- Ignorar la deuda que no es código. Documentación que miente, entornos que no se parecen, procesos manuales. También cuestan.
Cuándo asumirla
Sí para validar una idea rápido, para llegar a una fecha con consecuencias reales, o cuando el código quizá se tire en tres meses.
No en la seguridad, en la integridad de los datos ni en las copias de seguridad. Ahí no hay deuda que valga la pena: los intereses se pagan de golpe y en el peor momento.
