La deuda técnica es una decisión de producto
· 6 min de lectura
En mi equipo actual hemos reducido la deuda técnica en torno a un 80%. Cuando lo cuento, la pregunta casi siempre es técnica: qué herramienta, qué refactor, qué patrón. Mi respuesta decepciona un poco: lo decisivo no fue técnico.
La deuda técnica se suele presentar como un problema de ingeniería que ingeniería tiene que resolver en sus ratos libres. Creo que ese planteamiento es justo la razón por la que casi nunca se resuelve.
La tesis
La deuda técnica no se paga con sprints de limpieza. Se paga haciéndola visible en el mismo idioma que el resto del roadmap.
Mientras la deuda viva en un documento de ingeniería que solo lee ingeniería, siempre perderá contra la siguiente funcionalidad. No porque producto no la valore, sino porque no puede comparar algo que entiende (“esta feature aporta X”) con algo que no (“este módulo está mal acoplado”).
La metáfora original de Ward Cunningham ya lo decía: la deuda no es mala por definición. Pedir prestado para salir antes al mercado puede ser una decisión excelente. Lo malo es no saber cuánto debes ni cuánto interés pagas. Y decidir cuándo endeudarse y cuándo amortizar es, por definición, una decisión de producto.
Cómo medirla
Lo primero es dejar de hablar de la deuda en abstracto. “Hay mucha deuda” no permite priorizar nada. Lo que funciona es traducir cada deuda a su interés, es decir, a lo que nos cuesta seguir teniéndola:
| Deuda (en idioma de ingeniería) | Interés (en idioma de producto) |
|---|---|
| “El servicio de pedidos está muy acoplado” | Cada cambio en checkout tarda el doble y rompe algo en otro sitio. |
| “No hay tests en el módulo de precios” | Nadie quiere tocarlo; las mejoras de pricing se aplazan. |
| “Cada equipo formatea las respuestas de API a su manera” | Integrar un servicio nuevo cuesta días en lugar de horas. |
| “La configuración se edita a mano” | Los errores llegan a producción y se arreglan con prisas. |
La columna de la derecha es la que importa. No hace falta que sea exacta; basta con que sea concreta y que alguien de fuera de ingeniería pueda entenderla.
Para el seguimiento funcionan indicadores sencillos, que no requieren un proyecto de métricas:
- Frecuencia de cambio × dolor. El código que nadie toca puede estar feo sin hacer daño. La deuda que importa está donde se trabaja cada semana.
- Incidencias por área. Si los errores en producción se concentran en dos módulos, ya sabes dónde está la deuda que cobra intereses.
- Tiempo de entrega por tipo de cambio. Si los cambios en una zona tardan sistemáticamente más que en el resto, hay una razón.
Cómo priorizarla frente a features
Una vez la deuda tiene un interés visible, ya se puede comparar con lo demás. A partir de ahí, mi criterio es sencillo:
1. Pagar la deuda donde vas a construir. El mejor momento para sanear un módulo es justo antes de añadirle funcionalidad. La refactorización deja de ser un coste aparte: es parte de entregar la feature más rápido y con menos riesgo. Producto no tiene que elegir entre los dos.
2. Dejar en paz la deuda de las zonas tranquilas. Rehacer código estable que nadie toca es la forma más cara de sentirse productivo. Si no cobra intereses, no corre prisa.
3. Ponerle nombre a la deuda nueva. Endeudarse a propósito para llegar a una fecha es legítimo, siempre que quede registrado: qué atajo se toma, qué costará y cuándo se revisa. La deuda peligrosa es la que nadie decidió.
4. Un presupuesto pequeño y constante vale más que un gran proyecto. Los “trimestres de deuda técnica” tienden a cancelarse en cuanto aparece una prioridad comercial. Un porcentaje sostenido de cada ciclo, en cambio, sobrevive a casi todo.
Nada de esto es una regla de ingeniería. Son acuerdos entre ingeniería y producto, y por eso funcionan: los dos lados entienden qué se gana y qué se pierde.
Estándares de código como prevención
Pagar deuda es la mitad del trabajo. La otra mitad es generar menos.
Parte de nuestro trabajo fue definir e implantar estándares de programación para todo el departamento. No hablo de una guía de estilo que nadie lee, sino de acuerdos sobre cómo se estructura un servicio, cómo se nombran las cosas, cómo se gestionan los errores y qué se revisa en una code review.
Los estándares reducen la deuda por una razón poco intuitiva: la mayor parte de la deuda no nace de malas decisiones, sino de muchas decisiones razonables tomadas de forma distinta. Cinco formas razonables de resolver lo mismo suman un sistema que nadie entiende entero. Un estándar elimina cuatro y libera la atención para lo que de verdad es nuevo.
Para que un estándar se cumpla, he visto que funcionan tres cosas:
- Que lo haga cumplir una máquina, no una persona. Todo lo que pueda comprobar un linter, un formateador o el CI no debería consumir tiempo de revisión humana.
- Que se escriba con los equipos, no para ellos. Un estándar impuesto se respeta mientras alguien vigila.
- Que explique el porqué. Las reglas sin motivo se rompen en cuanto estorban. Las que lo tienen se pueden discutir y mejorar.
Las herramientas internas van en la misma línea. Cuando una tarea repetitiva se hace a mano, cada persona la hace a su manera y cada variante deja un pequeño rastro de deuda. Automatizarla con una herramienta compartida la estandariza sin necesidad de pedírselo a nadie. En nuestro caso, algunas de esas herramientas aceleraron hasta un 95% la creación de contenido de otros equipos y redujeron sus errores.
Lo que no funciona
Hay patrones que se repiten en casi cualquier conversación sobre deuda técnica, y que conviene evitar:
- La reescritura total. Promete resolverlo todo a la vez, tarda el triple de lo previsto y mientras tanto hay dos sistemas que mantener. Casi siempre es mejor sustituir por partes.
- El inventario infinito. Listar toda la deuda existente sin priorizarla genera una lista tan larga que paraliza en lugar de ayudar.
- La deuda como moneda de negociación. Si ingeniería usa la deuda para justificar retrasos, producto deja de creerse cualquier conversación sobre el tema.
- Medir líneas de código o code smells aislados. Son fáciles de contar, pero no dicen dónde duele.
La conclusión incómoda
Si la deuda técnica de tu equipo no baja, probablemente el problema no es de capacidad técnica. Es que la deuda no está en la misma conversación que todo lo demás.
Sacarla de ahí exige algo menos glamuroso que un gran refactor: traducirla a coste, decidir con producto qué se paga y qué no, y evitar que vuelva a crecer con estándares que nadie tenga que recordar. Reducir la deuda no es un proyecto técnico: es una forma de tomar decisiones de producto con toda la información delante.