# 03. Deuda técnica Cómo distinguir la deuda técnica deliberada del caos, cuándo la deuda empieza a cobrar intereses y cómo hablar de su repago con el negocio. - **Author:** Fedor Chishchin - **Level:** advanced - **Reading time:** ~25 minutos de lectura - **Published:** 2026-05-23 - **Source:** https://fedorthinks.com/es/learn/software-architect-03-technical-debt --- ## 1. La idea central 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. ## 2. Ejemplo y antiejemplo 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. ### Antiejemplo: "después lo reescribimos" > "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. #### Autoevaluación - ¿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? Próximo módulo: [Carga cognitiva](./software-architect-04-cognitive-load).