La Deuda Técnica, Explicada para No Ingenieros

Qué es la deuda técnica, en lenguaje claro

El software se construye a partir de decisiones, miles de ellas, la mayoría invisibles para cualquiera fuera del código. Cuando un desarrollador necesita añadir una funcionalidad, normalmente hay un camino rápido y un camino cuidadoso. El camino rápido la hace funcionar hoy pero deja el código subyacente más desordenado, más difícil de seguir, o más enredado con todo lo que lo rodea. El camino cuidadoso toma más tiempo ahora pero mantiene los cimientos limpios. La deuda técnica es lo que acumulas cada vez que eliges rápido sobre cuidadoso y no vuelves a ordenar.

Lo importante de entender es que el software sigue funcionando. La deuda técnica no es un error y no es software roto. Desde afuera, un producto que carga mucha deuda y uno que no carga ninguna pueden verse idénticos para tus clientes. La diferencia aparece internamente, en lo difícil que es cambiar la cosa. La deuda es la brecha entre el código que tienes y el código que necesitarías para seguir moviéndote rápido, y se paga no en dinero sino en tiempo de desarrollador en cada cambio futuro.

La analogía del préstamo, y por qué realmente encaja

La razón por la que la palabra deuda se quedó es que la mecánica realmente refleja un préstamo financiero. Cuando tomas un atajo, pides prestado tiempo. Consigues entregar ahora usando un esfuerzo que en realidad aún no has gastado. Ese es el capital. Luego, como el código está más desordenado de lo que debería, cada tarea futura que lo toca cuesta un poco más. Ese recargo recurrente es el interés, y como el interés real, se acumula. Mientras más tiempo dejes la deuda en su lugar y más código nuevo amontones encima, más pagas en cada lanzamiento.

Este encuadre es útil porque hace concreta la concesión para los tomadores de decisiones no técnicos. Pedir prestado para alcanzar una fecha de lanzamiento, ganar un trato, o probar una idea antes de invertir mucho puede ser una jugada de negocio perfectamente sólida, exactamente como tomar un préstamo para aprovechar una oportunidad puede serlo. El peligro es el mismo que con el dinero: la deuda que nunca reconoces y nunca saldas sigue cobrando interés hasta que los pagos desplazan todo lo demás. Muchos equipos de software gastan la mayor parte de su semana sirviendo el interés y se preguntan por qué nada nuevo se entrega jamás.

Deuda buena versus deuda mala

No toda deuda técnica es un problema, y tratar cada atajo como un pecado es su propio error. La distinción útil es si la deuda se tomó deliberada y prudentemente, o imprudentemente. La deuda deliberada y prudente es una elección consciente: el equipo entiende que está tomando un atajo, sabe aproximadamente cuánto costará la limpieza, y decide que la velocidad vale la pena por una buena razón. Esa deuda se anota en alguna parte y se revisa. Es una herramienta, y los equipos senior la usan a propósito.

La deuda imprudente es la que nadie eligió y nadie rastreó. Viene de apresurarse sin entender las consecuencias, de la inexperiencia, de copiar y pegar en lugar de pensar, o de una cultura que nunca hace tiempo para limpiar. El equipo está asumiendo deuda pero la trata como gratis, así que nunca aparece en ninguna lista y nunca se salda. La deuda mala también se acumula pasivamente con el tiempo: una decisión sensata de hace tres años se convierte en deuda a medida que el producto crece, las dependencias envejecen, y el mundo alrededor del código avanza. El objetivo no es deuda cero, lo cual no es ni realista ni vale el costo. El objetivo es mantener tu deuda deliberada, visible, y atendida.

• ▸Prudente y deliberada: un atajo rastreado tomado a propósito para alcanzar un plazo real, con un plan para revisarlo.
• ▸Imprudente y deliberada: saltarse lo básico como pruebas o revisión bajo presión, sabiendo más y haciéndolo de todos modos.
• ▸Prudente pero inadvertida: una decisión pasada razonable que solo se convirtió en deuda a medida que el producto y el mundo cambiaron.
• ▸Imprudente e inadvertida: deuda creada por inexperiencia o descuido que nadie reconoció como deuda en absoluto.

Cómo se acumula la deuda y por qué ralentiza el trabajo futuro

La deuda rara vez llega en un evento dramático. Se acumula un pequeño compromiso a la vez, y la ralentización que causa es igual de gradual, que es lo que la hace tan fácil de ignorar hasta que es severa. Cada atajo hace el código un poco más difícil de leer, un poco más interconectado, un poco más frágil. Individualmente, ninguno de estos importa. Juntos, significan que un cambio que debería tomar un día toma una semana, porque el desarrollador tiene que entender una maraña de decisiones pasadas y evitar cuidadosamente romper otras tres cosas conectadas a la que pretendía tocar.

Por eso los sistemas muy endeudados se vuelven más lentos con el tiempo en lugar de más rápidos, lo cual se siente al revés para cualquiera que espere que un equipo acelere a medida que aprende el producto. El interés es trabajo real: tiempo gastado descifrando código confuso, volviendo a probar cosas que no deberían haber estado en riesgo, arreglando las roturas que el atajo hizo probables, y rodeando limitaciones en lugar de eliminarlas. La gente nueva tarda más en volverse productiva porque el sistema es más difícil de aprender. Y la deuda más riesgosa se acumula en silencio, así que la cuenta a menudo llega en el peor momento posible, cuando intentas moverte rápido para un lanzamiento o un cliente y los cimientos no te dejan.

Las señales de que tienes demasiada

No necesitas leer el código para saber si la deuda técnica te está perjudicando. Los síntomas aparecen en el negocio, en los cronogramas, en la moral, y en el lenguaje que usa tu equipo. La señal más clara es que todo simplemente toma más tiempo del que solía, y más del que razonablemente debería. Pequeñas solicitudes que deberían ser rápidas se convierten en esfuerzos de varios días, y las estimaciones siguen subiendo para trabajo que suena simple. Cuando tu equipo empieza a inflar cada estimación por miedo, ese miedo es información.

Las otras señales tienen que ver con la fragilidad y la confianza. Los lanzamientos que solían ser rutinarios se convierten en eventos tensos donde algo inesperado se rompe en algún lugar no relacionado. Arreglar una cosa rompe de manera confiable otra. Y lo más revelador de todo, tus desarrolladores se vuelven reacios a tocar ciertas partes del sistema, hablando de ellas como aterradoras o malditas y rodeándolas en lugar de mejorarlas. Cuando ingenieros capaces tienen miedo de cambiar el software que les pagaste para construir, la deuda ha cruzado de un costo manejable a un verdadero lastre para el negocio.

• ▸Los cambios rutinarios toman mucho más tiempo del que solían, y las estimaciones siguen subiendo para trabajo que suena simple.
• ▸Los lanzamientos son frágiles y estresantes, con roturas inesperadas en lugares que nadie tocó.
• ▸Arreglar una cosa rompe regularmente otra, así que cada cambio se siente riesgoso.
• ▸Los desarrolladores tienen miedo visible de ciertas áreas y evitan cambiarlas en lugar de mejorarlas.
• ▸Incorporar nuevos ingenieros toma mucho más tiempo porque el sistema es difícil de entender.
• ▸Una porción creciente de cada semana se va en mantenimiento y apagar incendios en lugar de trabajo nuevo.

Cómo gestionarla sin detener todo

El instinto, una vez que un líder entiende el problema, suele ser detenerlo todo y reescribir todo limpio. Resístelo. Las reescrituras completas están entre las cosas más riesgosas que un equipo de software puede intentar, toman mucho más tiempo de lo que cualquiera espera, y congelan el valor nuevo mientras el trabajo se arrastra. El enfoque mucho mejor es un saldo constante e incremental tejido en el trabajo normal en lugar de un proyecto dramático de detener-el-mundo. Gestionas la deuda técnica como gestionas la deuda financiera: no entrando en pánico, sino haciéndola visible, presupuestándola, y saldándola de forma consistente.

Empieza por hacer la deuda visible. Pídele a tu equipo que nombre las peores áreas y aproximadamente cuánto cuestan, para que la deuda deje de ser una queja vaga y se convierta en una lista que puedas priorizar. No toda la deuda vale la pena saldar; concéntrate en la deuda que vive en código que cambias a menudo, porque ahí es donde el interés es más alto. La deuda en un rincón estable que nadie toca normalmente puede dejarse en paz. Luego presupuéstala deliberadamente, reservando una porción constante de cada ciclo, para que el saldo sea una expectativa normal en lugar de una pelea cada vez. Un patrón práctico es mejorar el código a medida que pasas por él: cuando un desarrollador ya está trabajando en un área desordenada para una funcionalidad, limpia un poco mientras está ahí. Con el tiempo esto mantiene las partes que más tocas cada vez más sanas sin nunca detener la entrega.

Sobre todo, trata la nueva deuda como una decisión en lugar de un accidente. Cuando el equipo toma un atajo, hazlo a propósito, anótalo, y acuerda cuándo lo revisarás. Los equipos que se mantienen rápidos durante años no son los que nunca asumen deuda. Son los que siempre saben cuánta están cargando y nunca dejan que el interés se les adelante.

• ▸Hazla visible: que el equipo nombre las peores áreas y estime cuánto te cuesta cada una.
• ▸Prioriza por rotación: salda la deuda en código que cambias a menudo, y deja en paz las áreas estables que no se tocan.
• ▸Presupuéstala: reserva una porción constante de cada ciclo para el saldo, para que se espere, no se negocie cada vez.
• ▸Mejora sobre la marcha: limpia el área en la que ya estás trabajando en lugar de esperar un proyecto dedicado.
• ▸Evita la reescritura de golpe: prefiere la mejora constante e incremental antes que congelar la entrega para empezar de cero.
• ▸Asume nueva deuda a propósito: anótala y decide de antemano cuándo la devolverás.