Software Architect · Módulo 03
La deuda técnica no es sinónimo de mal código. Es un compromiso que tiene que ser deliberado, estar registrado y, en algún momento, pagarse.
Debt quadrant · interest · repayment strategy
La deuda es útil cuando compra tiempo. La deuda es peligrosa cuando el equipo no sabe que sacó un préstamo.
No todo código malo es deuda
Un préstamo y una billetera robada generan los dos un problema financiero. Pero se manejan de formas distintas.
La technical debt aparece cuando el equipo elige conscientemente una solución más barata-ahora entendiendo el costo futuro. Por ejemplo: "No armamos un modelo multi-tenant completo hasta que tengamos clientes que paguen". Eso es deuda.
Pero "no escribimos tests porque nos olvidamos" o "nadie entendió los invariantes" no es deuda — es un defecto de engineering discipline. Llamar deuda a todo es peligroso: el negocio deja de poder distinguir dónde termina un compromiso estratégico y dónde empieza el mal trabajo.
Los intereses importan más que el capital
Un pozo chico al lado de tu casa te molesta todos los días. Un pozo enorme en medio del bosque puede quedarse ahí años sin molestar a nadie.
Los intereses de la deuda son la desaceleración que impone a los cambios. Si la deuda vive en el hot path del desarrollo, sale cara aunque el bulto sea chico. Si vive en un script de migración que casi no se toca, puede ser tolerable.
El arquitecto evalúa no sólo "qué tan feo está esto" sino "con qué frecuencia lo pagamos". Por eso un debt register debería incluir impact, owner, trigger for repayment y risk.
La deuda se vuelve manejable cuando tiene un motivo y una estrategia de repago.
Ejemplo: una sola región por ahora
Una tienda nueva abre primero su primer local. No arma la logística nacional antes de la primera venta.
El equipo lanza el SaaS en una sola región aunque sabe que los clientes enterprise van a exigir data residency más adelante. La decisión queda capturada en un ADR: una sola región por ahora porque no tenemos clientes con ese requisito; se revisa con el primer contrato enterprise o cuando el 20% de los usuarios venga de la UE.
Eso es deliberate debt razonable. Tiene motivo, boundaries y un trigger para revisitarla.
"Después lo reescribimos", sin fecha ni condición, no es un plan. Es un conjuro.
El equipo escribe el billing sin idempotencia porque "todavía hay pocos usuarios". Eso es peligroso: un solo error puede costar plata y confianza al instante. Esa deuda no es razonable, porque el riesgo es desproporcionado al ahorro.
No toda deuda es igual. La deuda en pagos, seguridad, datos y acciones legalmente significativas exige una justificación mucho más dura.
- ¿Por qué tomamos esta deuda? - ¿Quién es el owner de pagarla? - ¿Qué señal nos va a hacer volver? - ¿A qué usuarios se les pega si la deuda explota?