La deuda técnica es la brecha entre cómo es el código y cómo debería ser, asumida (deliberada o no) para moverse más rápido. Algo de deuda está bien; el trabajo es gestionarla, no eliminarla. La clave es priorizar la deuda que realmente daña.
Prioriza por impacto, no por molestia
text
For each piece of debt, ask:
- How often does it slow us down or cause bugs? (frequency)
- How bad is it when it bites? (severity)
- How risky/expensive is it to fix? (cost)
High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
Un ejemplo concreto
Un módulo frágil que se rompe en cada lanzamiento y bloquea al equipo semanalmente vale la pena arreglarlo. Una utilidad fea pero estable que nadie toca , incluso si te ofende. Refactorizarla es vanidad, no valor.