Casi todas las conversaciones sobre deuda técnica empiezan igual. Ingeniería describe un código difícil de cambiar. Producto señala un roadmap que ya viene atrasado. Un founder pregunta cuántos sprints hacen falta para "limpiar todo".
Enfocarlo de esa manera casi garantiza una mala decisión.
Limpiar suena a algo finito: sacás el desorden, dejás el código prolijo y volvés al trabajo normal. El software no funciona así. Los clientes cambian. El mercado cambia. Los equipos cambian. El código cambia a la par. La pregunta es si arreglar esa deuda es un mejor uso del tiempo que todo lo demás que el equipo podría hacer.
La deuda técnica no es un problema de calidad de código. Es una decisión sobre dónde invertir el próximo dólar y la próxima hora de ingeniería.
Esperar es conservar un activo
La deuda sirve cuando compra algo más valioso de lo que cuesta. Con la deuda técnica pasa lo mismo. Una startup puede vivir con un proceso manual, un módulo acoplado o una arquitectura que no escala diez veces porque ese crecimiento quizás nunca llegue. Salir antes puede comprar aprendizaje, ingresos o una nueva ronda de financiamiento.
Ese es el argumento económico detrás de YAGNI. Como explica Kent Beck, "You Aren't Gonna Need It" nunca se trató de ahorrar el esfuerzo de escribir código. Se trata de no comprometerse con un diseño antes de tener la información necesaria.
Construir para un futuro imaginario tiene dos costos. El primero es perder opcionalidad. Cuando diseñás para un problema futuro imaginado (feature, cliente o escala), renunciás a esperar y aprender. Aunque aciertes, decidiste antes de tiempo. Si te equivocás, volvés a pagar para cambiar o eliminar ese diseño.
El segundo es el valor presente neto. Un diseño construido hoy para una feature que llega en tres meses adelanta el costo y demora el retorno. Supongamos que hacerlo "bien" cuesta USD 100.000 hoy. Una solución más chica cuesta USD 50.000 ahora y otros USD 100.000 para reemplazarla en dos años. La solución chica parece un desperdicio si solo comparás costos de ingeniería. Pero esos USD 50.000 pueden ser runway que la empresa no recupera. Pueden financiar el experimento que te diga si el producto necesita escalar. En dos años, USD 100.000 pueden ser una porción mucho menor de los ingresos o del capital.
AI no elimina ninguno de esos costos. Puede generar un framework o un servicio casi gratis, y eso vuelve más tentador construir de más. Pero código barato no significa que comprometerse antes de tiempo también sea barato. La empresa igual pierde opciones, mantiene más código, demora otro trabajo y puede entender menos el sistema que ahora tiene que mantener.
El valor de esperar no está en el código que evitás escribir. Está en poder tomar una decisión mejor cuando tenés más información.
La solución más chica solo tiene sentido si la empresa entiende la deuda, puede reemplazarla después y obtiene suficiente valor por esperar. La deuda accidental suele ser negligencia. La deuda deliberada puede ser estrategia.
Cuánto cuesta la deuda
La deuda financiera se vuelve peligrosa cuando los intereses no dejan dinero para invertir. La deuda técnica se vuelve peligrosa cuando su costo no deja tiempo para cambiar el producto.
Ese costo rara vez aparece en una línea llamada "deuda técnica". Aparece como:
- Features que obligan a tocar cinco sistemas distintos sin relación.
- Deployments que necesitan un senior y una ventana de mantenimiento.
- Incidentes causados por los mismos componentes que cambian frecuentemente.
- Costos de cloud que crecen más rápido que el uso.
- Workarounds de Customer Success que consumen horas de ingeniería en cada sprint.
- Ventas bloqueadas por seguridad, compliance, performance o integraciones.
Un módulo con código horrible que no cambió en tres años puede no costar casi nada. Un servicio prolijo que seis equipos tocan todas las semanas puede costar una fortuna. Los inventarios de code smells y los dashboards de "porcentaje de deuda" no muestran eso. Miden lo que ingeniería ve, no lo que el negocio paga.
Yo suelo tratar el roadmap técnico como un portfolio. El equipo puede usar su tiempo en cuatro tipos de trabajo:
Producto
Features, experimentos, nuevos casos de uso y cualquier cosa por la que un cliente pagaría.
Escala
Trabajo que permite atender más clientes, transacciones, integraciones o complejidad.
Riesgo
Trabajo que reduce la probabilidad o el costo de caídas, incidentes de seguridad, problemas regulatorios y pérdida de confianza.
Velocidad
Automatización, observabilidad, herramientas internas y todo lo que abarata o acelera el próximo cambio.
La mayoría de las empresas gasta demasiado en la primera categoría porque las features son visibles y siempre tienen un sponsor. Todo lo demás cae en "deuda técnica". Un agujero de seguridad, un límite de escala, un pipeline inestable y el humor de un ingeniero por un framework viejo terminan compitiendo como si fueran el mismo problema.
Nombrar el resultado cambia la conversación. "Refactorizar billing" describe trabajo. "Bajar de tres semanas a dos días el tiempo necesario para probar un precio" describe un retorno. Un founder puede comparar ese retorno con una feature.
Cómo decidir qué arreglar
Para cada deuda suelo hacer cinco preguntas:
- ¿Cuánto cuesta hoy? Demoras, incidentes, trabajo manual, ventas perdidas, cloud y carga cognitiva. Ignoro los problemas que solo existen en teoría.
- ¿Qué tan rápido crece el costo? La deuda en un componente estable y la deuda en la parte que más cambia tienen intereses distintos.
- ¿Cuándo se vuelve demasiado cara o riesgosa? Definir el límite comercial, financiero, operativo o regulatorio que obliga a actuar.
- ¿Se puede revertir la decisión? Una herramienta interna descartable no es lo mismo que un modelo de datos usado por todos los procesos o un proveedor que controla tus datos centrales.
- ¿Qué se demora para arreglarla? La feature, el experimento, el cliente o el runway al que se está renunciando.
Esto no produce un porcentaje universal ni una regla que diga "reservá el 20% de cada sprint". Las asignaciones fijas ignoran el contexto. Una startup buscando product-market fit y una scale-up regulada no deberían tomar las mismas decisiones. La misma empresa puede decidir distinto después de firmar un cliente enterprise grande.
La deuda sube en la lista cuando demora trabajo relacionado con ingresos o aprendizaje, su costo crece, crea un riesgo que la empresa no puede asumir, el sistema está por cruzar un límite o una inversión chica elimina trabajo repetido.
A veces esperar es lo correcto: el código es relativamente estable, la hipótesis de producto puede seguir sin probarse, etc. El reemplazo puede consumir runway que hace falta en otro lado. O un cambio de producto ya planeado puede eliminar la deuda.
Las dos decisiones pueden ser correctas. "Siempre pagar la deuda" no es una estrategia. "Moverse rápido hasta que se rompa", tampoco. Estrategia es saber qué límite importa hoy y qué opciones se necesitan conservar para mañana.
De deuda técnica a capital técnico
Reducir fricción tiene un techo. Cuando el código funciona suficientemente bien, otra ronda de limpieza aporta poco.
Luca Rossi llama a la alternativa capital técnico: trabajo de ingeniería que sigue devolviendo valor porque hace los próximos cambios más baratos, rápidos o seguros. Una plataforma de deployment, un sistema de experimentación, una herramienta interna, una capa de integraciones reusable o mejor observabilidad pueden sacar deuda y facilitar el trabajo futuro.
Las empresas no ganan por tener el código más limpio. Ganan porque aprenden y entregan más rápido sin aceptar riesgos que pueden matarlas.
La próxima vez que alguien proponga un sprint de deuda técnica, vale la pena preguntarse qué devuelve, qué riesgo elimina y qué vas a demorar para financiarlo.
