La Deuda Técnica Es un Presupuesto, No un Fracaso
La deuda técnica se habla como si fuera algo que te pasa — un efecto secundario de moverse rápido, una señal de que se cortaron esquinas, una marca negativa contra el equipo. Creo que ese enfoque está equivocado, y genera daño real.
Los equipos que más he visto luchar con la deuda técnica no son los que la tomaron. Son los que fingieron que no la estaban tomando, nunca la escribieron, y se despertaron seis meses después dentro de un codebase que nadie quería tocar.
La deuda no es el problema. La deuda invisible es el problema.
La Deuda Es un Instrumento Financiero, No una Falla Moral
La metáfora es buena — solo la usamos mal. En finanzas, la deuda es una herramienta. Pides un préstamo para obtener apalancamiento: te mueves más rápido ahora, lo pagas después. Es un intercambio válido. Las empresas lo hacen de manera deliberada, con plena conciencia de los términos.
La deuda técnica funciona igual. Hardcodeas esa configuración porque lanzar en tres días importa más que construir un servicio de configuración. Saltas la abstracción porque la dirección del producto todavía es incierta. Escribes el script de migración a mano en lugar de conectarlo al CLI porque necesitas esto en producción esta noche.
Esas son decisiones, no accidentes. El problema es cuando las tratamos como accidentes — cuando lanzamos el atajo sin reconocerlo, sin escribirlo, sin planear volver algún día.
TIPCada vez que tomas deuda técnica deliberada, escribe un comentario de una línea:
// DEBT: [qué y por qué]. Ese comentario vale más que un ticket en el backlog. Vive donde vive el código.
Hay Dos Tipos de Deuda
No toda la deuda técnica es igual. La pienso en dos categorías:
Deuda estratégica — tomada intencionalmente para ganar velocidad. Conoces el intercambio. Tienes un plan. Quizás estás construyendo un MVP y una arquitectura limpia importa menos que validar el concepto. Quizás estás corriendo hacia una fecha límite y conscientemente eliges diferir la solución correcta.
Deuda accidental — esta se acumula cuando nadie está prestando atención. Lógica copiada que diverge con el tiempo. Librerías que nadie actualizó porque nadie era responsable. Un esquema que tenía sentido hace dos años pero que ahora pelea con cada nuevo feature. Esta es la deuda que mata los codebases.
El objetivo no es eliminar la deuda estratégica. El objetivo es eliminar la deuda accidental convirtiendo toda tu deuda en estratégica.
Cómo Presupuestar la Deuda como Equipo
Un presupuesto implica planeación. Si vas a tomar deuda, trátala como una línea en el presupuesto:
Nómbrala. Cuando lanzas un atajo, dilo en el PR. “Esta implementación omite la validación de X porque necesitamos esto el viernes — deberíamos revisarlo antes de agregar más consumidores a este endpoint.” Esa oración protege a tus compañeros futuros.
Rastréala. No en un doc interminable que nadie lee — una lista viva, actualizada en el mismo ritmo que tu roadmap. ¿Cuál es la deuda? ¿Por qué existe? ¿Cuándo se vuelve urgente?
Págala con un calendario. Los mejores equipos con los que he trabajado tratan el pago de deuda como trabajo de features. Cada sprint o ciclo tiene un porcentaje dedicado — 10%, 20% — que va a pagar la deuda más urgente antes de que se apilen nuevos features encima.
El error es tratar la deuda como algo que vas a arreglar “cuando las cosas se tranquilicen.” Las cosas no se tranquilizan. Tienes que programar el pago de la misma manera en que programas cualquier otra cosa que importa.
Cuándo la Deuda Se Vuelve Peligrosa
La deuda se compone. Esa es la parte que la gente olvida. Un parche en la capa de autenticación queda envuelto por un nuevo feature. Ese feature lo construye otro encima. Un año después, el parche original es infraestructura crítica y tocarlo aterroriza a todos.
La señal de peligro no es la complejidad — es la fricción. Cuando notas que agregar un nuevo feature requiere entender una cantidad desproporcionada de código no relacionado, tienes deuda compuesta. Cuando onboardear a un ingeniero nuevo toma el doble de tiempo porque el codebase tiene minas por todos lados, tienes deuda compuesta. Cuando tu equipo empieza a cubrir estimados porque “depende de lo que encontremos ahí adentro,” la deuda ya está manejando el calendario.
Ese es el momento en que la deuda deja de ser una herramienta y se convierte en un impuesto.
TIPRastrea la proporción de tiempo que pasas peleando con el codebase versus construyendo cosas nuevas. Si estás gastando más del 30% de tu tiempo en apagar incendios no planeados, tu presupuesto de deuda ya está rebasado.
Pedir Prestado con los Ojos Abiertos
He tomado deuda técnica deliberadamente en todas las empresas donde he trabajado. No me arrepiento de ninguna — las decisiones estratégicas que nos llevaron al mercado más rápido, que nos dejaron validar una apuesta riesgosa antes de invertir semanas en una solución limpia.
De lo que me arrepiento es de la deuda que tomé sin nombrarla. Las soluciones “temporales” que lancé sin nota, que se volvieron permanentes porque nadie recordaba por qué estaban escritas así.
La disciplina no es escribir código perfecto. Es ser honesto contigo mismo y con tu equipo sobre cuándo estás pidiendo prestado contra el futuro — y tener un plan para pagarlo.
La deuda técnica no es una señal de que tu equipo fracasó. Es una señal de que tu equipo tomó decisiones de compromiso. La pregunta es si esos compromisos fueron conscientes, documentados y gestionados — o si simplemente se acumularon en la oscuridad hasta que nadie quería mirar el codebase.
Pide prestado intencionalmente. Paga con un calendario. Eso es todo.