La deuda técnica es el precio acumulado de las decisiones rápidas de ayer. Un atajo en el código aquí, un sistema que se quedó pequeño y se parcheó allá, una integración hecha con prisa que nunca se rehízo. Cada atajo, como una deuda real, se paga con intereses: encarece y ralentiza todos los cambios futuros que toquen esa zona del sistema.
La metáfora financiera no es decorativa, es exacta. Igual que un préstamo, la deuda técnica tiene principal (el arreglo pendiente) e intereses (la fricción que añade a todo lo demás mientras no se arregla). Y como una hipoteca a la que solo se le pagan intereses, puede sostenerse durante años sin que nadie la cancele, drenando capacidad mes a mes.
Las cuatro formas en que se acumula
Conviene desmontar la idea de que deuda técnica es 'código feo'. Tiene cuatro caras, y las más caras no están en el código:
- De código. Atajos, duplicación, falta de pruebas. Es la más visible y, normalmente, la más barata de pagar.
- De arquitectura. Decisiones de diseño que envejecieron mal: un monolito que ya no se puede tocar sin riesgo, dependencias enredadas. Cara y lenta de pagar.
- De datos. Esquemas inconsistentes, duplicados, campos que significan cosas distintas en sitios distintos. Es la que bloquea los proyectos de analítica e IA.
- De infraestructura. Sistemas operativos sin soporte, dependencias sin actualizar, versiones que ya nadie mantiene. Es la que se convierte en agujero de seguridad.
Las empresas que crecen rápido acumulan las cuatro a la vez, y casi siempre sin un registro de dónde están ni cuánto frenan.
Cuánto cuesta, en cifras que entiende un CFO
20-40% del valor del patrimonio tecnológico de una empresa es deuda técnica: McKinsey.
McKinsey puso números a esto en uno de los pocos estudios serios sobre el tema. Los CIOs estiman que la deuda técnica equivale al 20-40% del valor de todo su patrimonio tecnológico, antes de depreciación. Y las empresas pagan de media un 10-20% adicional sobre el coste de cualquier proyecto nuevo solo para sortear la deuda existente: un proyecto que debería costar 100 cuesta 120 porque hay que rodear lo que ya está mal construido.
El caso que cita McKinsey lo aterriza: un gran banco descubrió que sus más de mil sistemas generaban en conjunto más de 2.000 millones de dólares en costes de deuda técnica. No por una catástrofe puntual, sino por acumulación silenciosa a lo largo de años de atajos razonables tomados de uno en uno.
La deuda técnica no se manifiesta como un fallo, sino como lentitud. La empresa no nota que paga intereses; solo nota que cada vez cuesta más mover el sistema.
Dónde se va, de verdad, el tiempo del equipo
El coste también se mide en la productividad del recurso más escaso de una empresa: quien construye. Según el estudio Developer Coefficient de Stripe, los desarrolladores dedican alrededor del 42% de su semana a lidiar con deuda técnica y código de baja calidad. Casi la mitad del tiempo del perfil más caro y más difícil de contratar se va en pelear con lo que ya existe, no en crear lo nuevo que el negocio pide.
A escala macro, el Consortium for Information and Software Quality estimó el coste de la mala calidad del software en Estados Unidos en 2,41 billones de dólares, con 1,52 billones en deuda técnica acumulada. La mecánica es idéntica en una empresa de 300 millones de facturación que en la economía entera: lo que no se mantiene, se encarece, y el interés se cobra en la moneda que más le importa a una empresa que crece, la velocidad para cambiar.
Por qué es una decisión de dirección, no un capricho de ingenieros
La tentación es tratar la deuda técnica como un asunto interno de los técnicos. Es un error de encuadre. La deuda técnica fija la velocidad máxima a la que la empresa puede cambiar: lanzar un producto, abrir un mercado, responder a un competidor, cumplir una nueva norma. Cuando el negocio pide algo y la respuesta siempre es 'tres meses', el cuello de botella rara vez es la pereza del equipo. Es la deuda que arrastra el sistema bajo sus pies.
Gestionarla bien no significa parar el negocio para reescribirlo todo. Significa decidir con criterio qué deuda se paga, cuándo y por qué, en función de qué frena más al negocio. McKinsey calcula que las empresas que la gestionan así liberan hasta un 50% más del tiempo de sus ingenieros para dedicarlo a lo que genera valor. No es un coste: es velocidad recuperada.
La pregunta útil para un comité de dirección no es si tienen deuda técnica, la tienen, toda empresa la tiene. Es si saben cuánta, dónde duele más, y qué les está costando en velocidad de negocio el no haberla tocado. La empresa que puede responder eso controla su tecnología. La que no, descubre el límite el día que el mercado le pide ir rápido y el sistema no la deja.