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