La deuda técnica y la metáfora de los suegros

Esta semana hablamos de uno de esos temas que divide opiniones en todos los equipos de desarrollo: la deuda técnica. Y empiezo con la pregunta que siempre hago en mis formaciones:

¿La deuda técnica es mala?

Spoiler: No. Pero tiene truco.

El mito de la deuda técnica

La deuda técnica no es mala per se. Es una herramienta estratégica que podemos usar para entregar valor antes y aprender sobre ello. El problema no es usarla, sino no entender sus costes asociados.

Por internet encontrarás muchas definiciones usando metáforas económicas. A mí me gusta explicarlo con algo más tangible: la cocina.

La metáfora de los suegros

Imagina esta escena: estás tranquilamente en casa cuando suena el teléfono. Tus suegros vienen a cenar. En 30 minutos.

Toca hacer malabares. Entre tu pareja y tú improvisáis lo mejor posible: un primero, un segundo, un postre... Pero no hay tiempo de limpiar. Así que hacéis lo que cualquier adulto razonable haría: meter todos los cacharros sucios en los cajones.

Llegan, cenan, os felicitan por la comida. Misión cumplida.

A la mañana siguiente vas a preparar el desayuno y... un cajón lleno de utensilios sucios. Ahora tienes dos opciones:

1. Invertir tiempo en recoger todo ahora (y posiblemente llegar tarde al trabajo)
2. Ignorarlo y dejarlo para después (cuando el problema puede ser peor)

Eso es la deuda técnica.

Un caso real: Las etiquetas de impresión

En el equipo que supervisaba en Mercadona Tech vivimos esto de primera mano con el código de impresión de etiquetas para el almacén.

El código había evolucionado de forma errática durante años. A cada nueva necesidad, un nuevo parche. Teníamos templates gigantescos con comandos de impresora específicos, sin abstracciones, sin tests semánticos.

¿Cómo probábamos los cambios? Generábamos la template, copiábamos el código, lo enviábamos a una impresora física y revisábamos el papel impreso. Si estaba bien, genial. Si no, a repetir.

Cada cambio era un microcrédito a un interés altísimo. El primero no se notaba, pero después de un año, el "interés" que pagábamos en forma de lentitud y errores era mayor que el beneficio de los atajos originales.

El punto de quiebra

Llegó el día en que necesitábamos un cambio rápido para una prueba. El código estaba enrevesado, mal testeado, "cogido con pinzas". Levantamos la mano: esto no iba a ser fácil y tenía riesgo.

Hicimos el cambio. La prueba fue bien. Pero al día siguiente tuvimos un incidente porque habíamos roto un caso esquina y la preparación en el almacén se vio comprometida.

El arreglo fue simple (desplegar la versión anterior), pero fue un toque de atención importante para desarrolladores y negocio.

Habíamos avanzado rápido todos esos años tomando atajos sin pagar la factura. Ahora estábamos en problemas.

La solución: del caos al DSL

Lo sensato fue reconocer el problema y ponerle solución. En vez de seguir con templates supercómplejas y texto libre que rompías con un punto y coma mal colocado, creamos un DSL (Domain Specific Language) alrededor del documento.

Pasamos de tener comandos específicos de impresora mezclados con datos de negocio, a tener objetos que representaban conceptos claros: un código QR, un texto, una imagen. Cada uno con sus propiedades bien definidas.

Beneficios inmediatos:

• ✅ Composición declarativa de etiquetas
• ✅ Testing semántico (probábamos objetos, no strings)
• ✅ Traducción robusta a comandos de impresora
• ✅ Desarrollo acelerado
• ✅ Cambiar etiquetas dejó de ser un dolor

La clave está en el equilibrio. Ser Senior es:

1. Ser lo suficientemente pragmático para saber cuándo hay que ir rápido tomando atajos
2. Ser lo suficientemente responsable para saber cuándo hay que frenar y recoger la cocina

La regla del prototipo vs. productivo

Una herramienta que me funciona muy bien es diferenciar entre:

• Código de prototipado: Aquel en el que hemos tomado atajos para validar una idea, entregar un valor inicial o empezar a aprender de nuestros usuarios. Lo tratamos como tal: un prototipo.
• Código productivo: Código listo para ser mantenido en el futuro, testeado, con abstracciones apropiadas y preparado para evolucionar.

Lo importante es que todo el mundo hable usando el mismo lenguaje. Que el equipo y negocio entiendan que con ese código hemos recortado esquinas y que la funcionalidad "no está acabada" hasta transformarlo.

Una vez entregado el valor y con usuarios y negocio contentos, transformamos ese código de prototipado en código productivo.

Esto nos permite:

• Obtener los beneficios de generar deuda técnica (velocidad, aprendizaje)
• Mantener el impacto negativo bajo control
• No comprometer el largo plazo

Negociar con Negocio

Gestionar la deuda técnica no es solo una cuestión de código, sino también de cultura. Implica conversaciones incómodas, consensos sobre prioridades y comunicación honesta dentro del equipo.

Hay que traducir la deuda a coste real: "Este código nos hace perder X días en cada cambio" o "Hemos tenido Y incidentes por no arreglarlo" son argumentos que negocio entiende.

¿Qué experiencias has tenido tú con deuda técnica? Compártelo en Twitter o LinkedIn, me encanta leer vuestras historias.