Todos los que escribimos código convivimos con la deuda técnica: ese atajo que resolvió el problema de ayer y hoy cobra intereses. El error más común no es crear deuda, sino tratar toda deuda como un pecado y querer refactorizarlo todo, siempre y ahora. Esta guía es para quienes sienten que el código se está "pudriendo", pero necesitan seguir entregando: la idea es cambiar la culpa por criterio.
Qué es la deuda técnica (y qué no es)
La deuda técnica es la distancia entre la solución que entregaste y la solución que dejarías para "hacerla bien". Nace de decisiones conscientes ("vamos a hardcodearlo ahora y lo generalizamos después") y también de decisiones que ni siquiera sabíamos que estábamos tomando: falta de contexto, plazos cortos o aprendizajes que solo llegaron más tarde.
Lo que no es deuda técnica: código feo que funciona y que nadie necesita tocar, o una arquitectura simplemente diferente de la que prefieres. La deuda es aquello que aumenta el costo de cambiar el sistema en el futuro. Si nadie va a tocar ese fragmento en mucho tiempo, el interés es bajo y quizá ni siquiera necesites pagarlo.
No toda deuda es mala: la analogía de los intereses
Piénsalo como quien pide un préstamo. La deuda puede ser una mala decisión o una forma de apalancamiento, según lo que hagas con ella y el tamaño de los intereses. Un atajo que te permite validar una idea semanas antes puede valer mucho más que la refactorización que aplaza. El problema casi nunca es el atajo consciente, sino la deuda olvidada, que acumula intereses silenciosamente hasta que cualquier cambio pequeño se convierte en una pesadilla.
La pregunta correcta nunca es "¿esto está perfecto?". Es: "¿cuánto cuesta convivir con esto y ese costo está aumentando?".
El cuadrante: cuatro tipos de deuda
Una forma sencilla de ver la deuda es cruzar dos preguntas: ¿la decisión fue intencional o accidental? ¿Y fue prudente o imprudente?
- Intencional y prudente: "sabemos que no es lo ideal, pero necesitamos lanzar; dejamos anotado el motivo". Es la deuda buena.
- Intencional e imprudente: "no tenemos tiempo para hacerlo bien", repetido para siempre y sin un plan. Aquí está el peligro.
- Accidental y prudente: "ahora que entendemos el dominio, sabemos cómo deberíamos haberlo hecho". Es aprendizaje puro, saludable y esperado.
- Accidental e imprudente: el equipo no sabía lo que no sabía. Se combate con estudio, revisión y mentoría, no con culpa.
La etiqueta importa porque cambia la conversación: la deuda prudente se gestiona; la deuda imprudente se previene.
Criterios para decidir: pagar, programar o convivir
Antes de abrir el IDE para "arreglarlo", pasa el fragmento por tres filtros:
- Frecuencia de cambio. ¿Modificas ese código cada semana o lleva meses congelado? La deuda en código que cambia mucho cobra intereses altos; la deuda en código que ya no se toca es casi gratis.
- Radio de impacto. Un atajo aislado detrás de una interfaz es fácil de cambiar después. Un atajo que se filtró a diez lugares ya te está costando caro.
- Riesgo. Si el peor escenario es un detalle estético, convive con él. Si el peor escenario involucra datos, dinero o seguridad, aumenta su prioridad, aunque el código parezca estar "bien".
Con estos filtros, la decisión casi se resuelve por sí sola:
- Pagar ahora cuando el código cambia mucho, el radio de impacto es grande y el riesgo es real, preferiblemente refactorizando junto con la próxima feature que toque esa parte.
- Programar cuando el costo es medio y predecible: regístralo, hazlo visible y trátalo como trabajo real, no como algo para "cuando haya tiempo" (nunca lo hay).
- Convivir cuando el código no cambia y está aislado: acéptalo de forma consciente y sigue adelante.
El error clásico es hacer lo contrario: una refactorización heroica de fin de semana, enorme y desconectada de cualquier entrega. Por lo general, introduce más riesgo del que resuelve.
Cómo registrar y negociar con el equipo y el negocio
La deuda que solo vive en tu cabeza no existe para el resto del equipo y desaparece cuando cambias de proyecto. Deja un registro donde el equipo ya mira: un comentario breve que explique la decisión y el desencadenante para revisarla, un elemento en el backlog con el costo expresado claramente o una nota en la propia tarea que creó el atajo.
Y aquí está la parte que casi nadie enseña: no vendes una refactorización hablando de código. Fuera de ingeniería, a nadie le importa el "acoplamiento". Tradúcelo a riesgo y costo de cambio. "Este atajo hace que cada modificación en esta pantalla tarde el triple y falle en producción" es una frase que producto y liderazgo entienden y priorizan.
Para cerrar la cuenta
La deuda técnica no es la villana de la historia; es una herramienta de negocio como cualquier otra. Los equipos maduros no tienen cero deuda: saben exactamente qué deuda cargan, por qué la aceptaron y cuándo pretenden revisarla. La próxima vez que sientas culpa por un atajo, cambia la pregunta: en lugar de "¿esto está bien?", pregunta "¿este costo está aumentando y vale la pena pagarlo ahora?". Solo ese cambio ya separa a quien apaga incendios de quien toma decisiones.