Hay una frase que se dice mucho y que, cada vez que la escucho, me dan ganas de discutirla: “tenemos que eliminar la deuda técnica”. Suena bien, suena responsable, suena a equipo maduro. El problema es que parte de una idea equivocada: que la deuda técnica es algo malo que hay que erradicar, como una plaga. Después de muchos años conviviendo con sistemas reales —los que funcionan, los que dan plata, los que tienen clientes que dependen de ellos— llegué a una conclusión distinta y bastante más incómoda: la deuda técnica no se elimina, se administra. No es un error a corregir, es una condición permanente del oficio, como la fricción para un mecánico o el costo para un contador. Y como toda condición permanente, lo que importa no es soñar con hacerla desaparecer, sino aprender a gestionarla con criterio. La vengo mencionando al pasar en casi todo lo que escribí este año, así que me debía a mí mismo un post entero. Acá está.
Deuda no es lo mismo que desprolijidad#
Lo primero que conviene aclarar, porque se confunde todo el tiempo, es que deuda técnica no es sinónimo de código mal hecho. El nombre lo eligió bien quien lo inventó, porque la metáfora financiera es exacta: una deuda es algo que tomás a propósito, conscientemente, para conseguir algo ahora a cambio de pagar más después. Pedís prestado tiempo del futuro para entregar valor en el presente. Y eso, lejos de ser siempre malo, a veces es la decisión correcta.
Pensémoslo con un ejemplo cualquiera. Una empresa tiene una oportunidad de mercado que dura tres semanas. Puede construir la solución perfecta, bien diseñada, mantenible, en tres meses, y perder la oportunidad. O puede construir algo que funcione en dos semanas, con atajos conscientes, y capturar el negocio, sabiendo que después tendrá que volver a poner las cosas en orden. Tomar deuda ahí no es irresponsable; es estratégico. El problema no es tomar deuda. El problema es tomarla sin saber que la estás tomando, no registrarla, y descubrir años después que el sistema entero está hipotecado y nadie firmó nada.
Por eso me gusta separar la deuda deliberada de la desprolijidad. La deuda deliberada es una decisión: “sabemos que esto no es lo ideal, lo hacemos así por esta razón, y vamos a tener que volver”. La desprolijidad es otra cosa: es no saber hacerlo mejor, o no haberse tomado el trabajo de pensar. La primera es una herramienta legítima del oficio. La segunda es, simplemente, trabajo mal hecho disfrazado con un nombre elegante. Cuando alguien dice “es deuda técnica” para justificar algo que en realidad es chapucería, está usando mal el término, y conviene no dejarlo pasar.
La que se ve#
La deuda más fácil de manejar es la que se ve. El código que sabemos que está feo, la función que todos evitan tocar, el módulo que da vergüenza, la parte del sistema sobre la que el equipo bromea en los pasillos. Esa deuda, al menos, tiene la cortesía de ser visible. Sabemos que está, sabemos más o menos dónde, y podemos decidir qué hacer con ella.
Lo interesante de la deuda visible es que el problema rara vez es técnico: es de priorización. Casi siempre sabemos qué habría que arreglar; lo que no tenemos es el permiso, el tiempo o la decisión de hacerlo. Y ahí entra una de las habilidades centrales de quien lidera: elegir qué deuda visible vale la pena pagar y cuál conviene dejar tranquila. Porque —y esto va contra el instinto del perfeccionista— no toda deuda visible hay que pagarla. Hay código feo que funciona perfecto, que casi no se toca, que no está en el camino crítico de nada. Refactorizarlo sería gastar esfuerzo en mejorar algo que nadie iba a sentir. La deuda visible que no molesta puede quedarse fea y en paz. El criterio no está en arreglar todo lo que se ve mal, sino en distinguir lo que duele de lo que solo es feo.
La que se esconde#
Mucho más peligrosa es la deuda que no se ve. Y acá conecto con algo que escribí hace unos meses sobre las dependencias invisibles, porque es la misma familia de problemas: lo que no conocemos no lo podemos gestionar. La deuda escondida no es código feo que evitamos; es deuda que ni siquiera sabemos que tenemos.
Tiene muchas formas, y casi ninguna parece deuda a primera vista. El conocimiento que vive en la cabeza de una sola persona y que se va a ir caminando el día que esa persona renuncie. La decisión de arquitectura que se tomó hace cinco años por una razón que ya nadie recuerda, y que sigue condicionando todo sin que sepamos por qué. La dependencia que funciona tan bien que dejamos de mirarla. El supuesto que era verdad cuando se diseñó el sistema y dejó de serlo sin que nadie lo notara. La falta de tests que no se siente como deuda hasta el día que hay que cambiar algo y nadie está seguro de qué va a romper. Como dije una vez, la deuda técnica no es solo código viejo: es conocimiento perdido, decisión no documentada, miedo a tocar una parte del sistema. Todo eso es deuda, y toda esa deuda es invisible justamente hasta el peor momento.
Lo que vuelve tan traicionera a la deuda escondida es que no aparece en ninguna métrica, en ningún tablero, en ninguna reunión de planificación. No genera alertas. No molesta en el día a día. Crece en silencio, y solo se cobra cuando intentamos cambiar algo y descubrimos que el sistema es mucho más frágil de lo que creíamos. Por eso el mejor trabajo que puede hacer un equipo sobre su deuda escondida es, antes que nada, hacerla visible: documentar lo que vive en cabezas, registrar las decisiones y sus porqués, mapear de qué depende lo crítico. No se puede pagar una deuda que no figura en ningún lado, igual que no se puede proteger lo que no se conoce. Hacer visible la deuda escondida no la elimina, pero la convierte en algo gestionable, que ya es muchísimo.
La que heredamos#
Y después está la deuda que no creamos nosotros: la que heredamos. Casi cualquiera que llega a un sistema con algunos años de vida se encuentra con esto, y merece una mirada propia porque tiene una dinámica distinta a las otras dos. Heredar deuda es recibir un sistema construido por gente que ya no está, con decisiones que no tomamos, atajos que no elegimos, y una historia que muchas veces nadie nos puede contar entera.
La deuda heredada tiene una trampa emocional que conviene nombrar. Cuando uno recibe un sistema lleno de deuda, la reacción fácil es el desprecio: “qué desastre hicieron acá, esto está todo mal, hay que tirar todo y rehacerlo”. Es una reacción comprensible y casi siempre equivocada. Equivocada por dos razones. La primera es de humildad: ese sistema que nos parece un desastre probablemente se construyó con restricciones que no conocemos —plazos imposibles, presupuestos ajustados, requisitos que cambiaban, gente que aprendía sobre la marcha—. La gente que lo hizo no era necesariamente peor que nosotros; estaba en otra situación. Juzgar el pasado con la comodidad del presente es injusto y, peor, no ayuda en nada. La segunda razón es práctica: ese sistema “desastroso”, con toda su deuda, es el que está funcionando, el que sostiene el negocio, el que tiene clientes encima. No es un borrador que podemos descartar; es algo vivo que hay que mantener andando mientras lo mejoramos.
La tentación más peligrosa frente a la deuda heredada es la reescritura total: tirar todo y empezar de cero, hacerlo “bien” esta vez. La historia de nuestra industria está llena de reescrituras que terminaron mal, que tardaron el triple de lo previsto, que reintrodujeron los mismos problemas con ropa nueva, o que nunca llegaron a reemplazar al viejo sistema que, mientras tanto, seguía funcionando. Modernizar un sistema heredado casi nunca es tirar todo y empezar de nuevo; es convivir con lo existente, entenderlo con humildad, reducir riesgos, mejorar de a poco, migrar gradualmente sin romper el negocio. Es menos heroico que la reescritura épica, pero funciona muchísimo más seguido. La deuda heredada no se salda con un gran gesto; se va pagando, de a cuotas, mientras el sistema sigue dando servicio.
La conversación más difícil: explicarle al negocio#
Hasta acá hablé de la deuda desde el lado técnico, pero hay una mitad del problema que es, en realidad, una conversación con quienes no son técnicos. Porque la deuda técnica se paga con tiempo, y ese tiempo casi siempre compite con features nuevas, con pedidos del negocio, con cosas que sí se ven y que generan valor visible. Y acá está una de las habilidades más subestimadas de quien lidera tecnología: saber explicarle a alguien que no es técnico por qué a veces hay que frenar para arreglar algo que, desde afuera, parece que ya funciona.
Es una conversación difícil porque la deuda técnica es invisible para el negocio. Quien mira desde el lado comercial ve que el sistema anda, que los clientes lo usan, que todo parece bien. Pedir tiempo para “mejorar algo que ya funciona” suena, desde esa perspectiva, a un capricho de ingenieros perfeccionistas. Y a veces lo es, seamos honestos. Pero muchas otras veces es la diferencia entre un sistema que va a poder crecer y uno que va a empezar a frenar todo dentro de seis meses. El problema es que ese costo futuro no se ve hoy, y lo que no se ve es difícil de vender.
Lo que aprendí es que no sirve explicarlo en términos técnicos. Al negocio no le importa, ni tiene por qué importarle, qué tan elegante es nuestro código. Le importa el impacto: cuánto más lento vamos a entregar features si no pagamos esta deuda, qué riesgo de caída estamos corriendo, cuánto nos va a costar contratar gente nueva si nadie entiende el sistema, qué oportunidad vamos a perder cuando no podamos movernos rápido. La deuda técnica hay que traducirla al idioma del negocio, que es el del riesgo y el de la oportunidad, no el de la prolijidad. “El código está feo” no convence a nadie. “Si no arreglamos esto, el próximo cambio importante nos va a llevar el triple y con riesgo de romper producción” es una conversación que el negocio entiende, porque habla de tiempo y de plata, que es su idioma. Traducir es parte del trabajo.
Cómo decidir qué pagar y cuándo#
Una cosa es decir “la deuda que duele se paga y la que es solo fea se deja”, y otra es bajarlo a una decisión concreta el lunes a la mañana, con una lista de cosas para arreglar y un tiempo limitado. Acá es donde la gestión de la deuda deja de ser filosofía y se vuelve oficio. Lo que trato de mirar, ante cada pieza de deuda, son tres cosas distintas que conviene no mezclar.
La primera es cuánto duele hoy: si esa deuda está frenando al equipo ahora mismo, si cada cambio en esa zona cuesta el triple, si es la causa de bugs recurrentes. La segunda es cuánto va a doler mañana: si está en una parte del sistema que vamos a tener que tocar mucho en los próximos meses, o en un rincón que nadie va a visitar. Una deuda en código que vamos a reescribir igual el mes que viene no vale la pena pagarla; una deuda chica en el corazón de algo que vamos a extender sin parar, sí. Y la tercera es cuánto cuesta pagarla: porque hay deuda dolorosa pero carísima de saldar, y deuda menor que se arregla en una tarde. La combinación de esas tres —duele, va a doler, cuesta poco— es la que marca la prioridad real, y casi nunca coincide con “lo que más nos molesta a la vista”.
Esto importa porque el error más común no es ignorar la deuda; es pagarla en el orden equivocado. Equipos que dedican esfuerzo a embellecer una parte del sistema que nadie toca, mientras la deuda que de verdad los frena sigue ahí porque es menos visible o menos satisfactoria de arreglar. Pagar deuda también es una decisión de priorización, y como toda priorización, se hace bien con cabeza y mal por impulso. Lo satisfactorio de arreglar y lo importante de arreglar son dos cosas distintas, y conviene no confundirlas. El refactor que nos deja contentos no siempre es el que el sistema necesitaba.
La deuda también es una conversación de equipo#
Hay una dimensión de todo esto que es puramente humana y que aprendí a no descuidar: cómo el equipo se relaciona con su propia deuda. Un equipo que carga deuda en silencio, que no la nombra, que cada uno conoce sus rincones feos pero nadie los comparte, está peor que uno que la tiene mapeada y discutida, aunque la cantidad de deuda sea la misma. Porque la deuda que se habla se puede priorizar; la que cada uno se guarda, no.
Por eso trato de que hablar de deuda sea normal en el equipo, sin culpa ni vergüenza. Que alguien pueda decir “esto lo resolví con un atajo, lo dejo anotado para volver” sin sentir que confiesa un pecado. Que tomar deuda deliberada sea una decisión que se comparte, no algo que se esconde. Que la deuda heredada se cuente sin despreciar a quien la dejó. Cuando la deuda se vuelve un tema conversable, deja de crecer en la oscuridad y pasa a ser algo que el equipo gestiona junto. Y esto conecta con algo que escribí sobre cómo funciona un equipo de verdad: lo que sostiene a un grupo no es que cada uno sea brillante por separado, sino cómo comparten lo que saben. La deuda escondida prospera, justamente, donde no se comparte. Hacerla conversable es, en el fondo, un acto de salud del equipo antes que un acto técnico.
Como en casi todo, los extremos son malos consejeros, y la deuda técnica tiene dos. El extremo del perfeccionista, que no tolera nada que no esté impecable, que quiere refactorizar todo, que frena la entrega de valor por una pulcritud que el negocio no necesita. Y el extremo opuesto, el del abandono, que toma deuda sin parar, nunca paga nada, y deja que el sistema se pudra hasta que un día deja de poder cambiarse. Los dos terminan mal. El perfeccionista no entrega; el que abandona, entrega hasta que ya no puede.
El criterio, como casi siempre, vive en el medio incómodo. Tomar deuda cuando tiene sentido estratégico, y registrarla cuando la tomamos. Pagar la deuda que duele, la que está en el camino crítico, la que frena al equipo, y dejar en paz la que es solo fea. Hacer visible la que está escondida. Convivir con la heredada sin despreciarla ni idolatrar la reescritura. Y, todo el tiempo, traducirle al negocio por qué estas decisiones importan. No hay una fórmula; hay criterio, que es esa palabra que vengo repitiendo todo el año porque es, en el fondo, de lo único que se trata el oficio cuando las herramientas dejan de ser el problema.
Por qué esto importa más ahora#
Hay una razón por la que este tema, que es viejo como el software, se volvió más urgente justo ahora. Lo toqué cuando escribí sobre programar con IA y sobre los agentes: estas herramientas bajaron drásticamente el costo de generar código. Y cuando generar código es barato y rápido, es facilísimo acumular deuda a una velocidad que antes era impensable. Más código, más rápido, sin necesariamente más comprensión. Código que funciona pero que nadie diseñó del todo, que nadie entiende del todo, generado en conversaciones que ya no existen.
Eso no hace que la deuda técnica sea un tema del pasado; la vuelve más relevante que nunca. La capacidad de generar creció muchísimo; la capacidad de entender, mantener y pagar lo generado, no. Y esa brecha es, exactamente, deuda técnica esperando a hacerse visible. Por eso administrar la deuda con criterio, que siempre fue parte del oficio, se vuelve una de las habilidades más valiosas del momento. No porque la deuda sea nueva, sino porque ahora podemos fabricarla más rápido que nunca, y la disciplina de gestionarla no escaló a la misma velocidad que la facilidad de crearla.
Les dejo una pregunta para que la lleven a su propio sistema. Si tuvieran que separar la deuda de su sistema en esas tres pilas —la que ven, la que sospechan que está escondida, y la que heredaron sin haberla creado— ¿cuál de las tres les da más miedo, y cuál es la que menos están mirando? Porque casi siempre la que más nos va a costar no es la que tenemos a la vista quejándonos de ella, sino la que ni sabíamos que estábamos cargando. Y con la deuda, como con casi todo en tecnología, el primer paso para gestionarla no es pagarla: es animarse a mirarla de frente.