El mito de cero deuda técnica
Hay una fantasía persistente en la cultura de ingeniería de que los mejores codebases tienen cero deuda técnica. Que cada atajo es un pecado. Que "hacerlo bien" siempre significa hacerlo a fondo.
En una startup, esta mentalidad te va a matar. Vas a shipear código perfecto a cero usuarios mientras tu competidor shipea código imperfecto a diez mil.
La deuda técnica como estrategia
Los líderes de ingeniería más inteligentes con los que trabajamos tratan la deuda técnica como deuda financiera — una herramienta con costos y beneficios.
Deuda buena: acelera el aprendizaje
¿Tomar un atajo para shipear una feature más rápido y validar si los usuarios la quieren? Eso es deuda buena. Si falla la validación, la borrás. Si tiene éxito, agendás el refactor.
Deuda mala: se acumula silenciosamente
Saltear manejo de errores, ignorar cobertura de tests, copiar y pegar en vez de abstraer — esto crea interés compuesto.
Nuestro framework para gestionar deuda
El registro de deuda
Mantenemos un documento vivo que trackea cada atajo intencional. Cada entrada tiene: qué cortamos, por qué, el costo estimado para arreglarlo, y la condición trigger para cuándo debemos arreglarlo.
Sprints de deuda
Cada seis semanas, dedicamos un sprint entero a reducir deuda. Sin features nuevas, sin requests de stakeholders.
La regla del 30%
En sprints regulares, el 30% de la capacidad de ingeniería se reserva para trabajo no-feature: deuda, tooling, testing e infraestructura.
Cuándo rechazar deuda
Algunas deudas nunca valen la pena: atajos de seguridad, hacks de integridad de datos, y cualquier cosa que afecte la confianza del usuario.
