La deuda técnica es el motivo por el que un cambio que debería tardar dos días acaba tardando dos semanas. No es un concepto abstracto de programador: es tiempo de desarrollo que deja de dedicarse a nada nuevo porque se va en sostener lo que ya existe, y ese tiempo sale del mismo presupuesto que un responsable de marketing o de sistemas aprueba cada trimestre. Este artículo explica de dónde sale, cuánto cuesta en cifras concretas y cómo decidir, con criterios y no con intuición, cuándo conviene parchear y cuándo reescribir.
Qué es la deuda técnica en un proyecto web
La deuda técnica aparece cada vez que un equipo elige la solución rápida en vez de la correcta para cumplir un plazo: un formulario sin validar bien, una integración a medias con el CRM, una librería que nadie ha actualizado en tres años. La primera vez no se nota. El coste llega después, cuando cada función nueva necesita rodear el problema en vez de resolverlo.
La deuda técnica es el interés que paga un equipo de desarrollo por haber ido rápido ayer, cobrado en el tiempo que necesita hoy para hacer cualquier cambio.
No toda deuda es un error de gestión. Lanzar una tienda online a tiempo para una campaña con una integración provisional puede ser la decisión correcta, siempre que alguien anote que es provisional y se reserve tiempo para saldarla. El problema no es contraerla: es no saber cuánta se tiene ni cuándo toca pagarla.
Cómo se acumula el código heredado en tu web
El código heredado no llega de golpe: se acumula en capas, cada una añadida por un proveedor distinto sin documentación del anterior. Una web que empezó como una plantilla sencilla termina con tres sistemas de reservas superpuestos porque cada agencia resolvió el mismo problema sin tocar lo que ya funcionaba, por miedo a romperlo.
El síntoma más claro es el tiempo que tarda un cambio pequeño. Si mover un botón de sitio obliga a revisar media docena de archivos sin relación aparente, el código ya no describe lo que el negocio necesita hoy: describe el histórico de decisiones de quien lo tocó. Una auditoría técnica antes de contratar el siguiente cambio suele costar menos que descubrirlo a mitad de un desarrollo que no avanza.
El coste real de la deuda tecnológica acumulada
El coste de la deuda tecnológica no aparece en ninguna factura como partida propia: se reparte entre cada tarea que tarda más de lo previsto. Por eso es tan fácil de ignorar en un presupuesto y tan difícil de justificar cuando hay que pedir tiempo para corregirla en vez de para construir algo nuevo.
Trece horas y media a la semana en parches
El estudio Developer Coefficient de Stripe, con más de 1.000 desarrolladores encuestados, midió que los equipos dedican de media 17,3 de las 41,1 horas semanales a mantenimiento y código problemático, y que 13,5 de esas horas van directamente a deuda técnica: un tercio de la capacidad total de desarrollo. Para un equipo de cinco personas trabajando en la web y las integraciones de una empresa, eso equivale a más de un puesto y medio a tiempo completo dedicado, cada semana, a sostener lo que ya existe.
Señales de alerta en un sistema legado
No hace falta un informe técnico para detectar que un sistema legado empieza a pesar más de lo que aporta. Casi siempre se nota primero fuera del código, en cómo trabaja el equipo:
- Cada despliegue nuevo obliga a probar funciones que no se han tocado, porque nadie está seguro de qué depende de qué.
- Los presupuestos de desarrollo crecen sin que el número de funciones nuevas lo haga en la misma proporción.
- Actualizar una librería o el propio gestor de contenidos da miedo, y por eso se pospone hasta que deja de recibir soporte.
- Solo una o dos personas entienden partes enteras del sistema, y ninguna documentación las sustituye.
Cuando dos o más de estas señales conviven durante varios trimestres seguidos, seguir parcheando ya no es la opción barata: es la que retrasa el problema y lo encarece.
Parchear o reescribir: qué conviene en cada caso
La respuesta correcta casi nunca es todo o nada. Un sistema puede tener partes sanas que no necesitan tocarse y una sola pieza, el checkout, el formulario de leads, la integración con el CRM, que concentra la mayor parte del problema.
Cuándo el parche es la opción correcta
Parchear tiene sentido cuando el problema está acotado, el sistema seguirá en uso poco tiempo o el negocio no puede permitirse una parada. Una tienda que factura la mayor parte del año en campaña no va a migrar su pasarela de pago en octubre, por muy vieja que esté: se refuerza lo que hay, se documenta el riesgo y se planifica el cambio para la temporada baja. El parche también es correcto cuando sirve para ganar el tiempo necesario para diseñar bien la alternativa, no para evitarla indefinidamente.
Cuándo conviene migrar en lugar de parchear
Migrar compensa cuando cada parche nuevo cuesta más que el anterior y toca una parte distinta del sistema, señal de que el problema es de arquitectura y no de una función concreta. También cuando el software depende de una versión sin soporte, de PHP, de un framework o de un gestor de contenidos, porque entonces cada vulnerabilidad nueva queda sin parche oficial. Una reescritura planificada, por fases y sin parar el negocio, suele salir más barata que seguir sumando remiendos a una base que ya no aguanta más.
| Criterio | Parchear | Reescribir |
|---|---|---|
| Coste inicial | Bajo | Alto |
| Riesgo de parada | Bajo | Medio si se planifica por fases |
| Coste a 2-3 años | Crece con cada parche | Se estabiliza tras la migración |
| Cuándo elegirlo | Problema acotado o sistema con vida corta | Software sin soporte o arquitectura agotada |
Cómo frenar la deuda tecnológica cada sprint
Frenar la deuda tecnológica no exige parar el desarrollo: exige tratarla como una partida más del presupuesto, no como una excepción. Las empresas con menos deuda acumulada no son las que nunca la contraen, sino las que la pagan de forma regular en vez de dejarla crecer sin control.
En la práctica funciona reservar un porcentaje fijo de cada sprint, entre el 15% y el 20% es habitual, a corregir lo que ya existe antes de sumar funciones nuevas, y exigir a cualquier proveedor que documente qué decisiones toma como provisionales y cuándo se revisarán. Un mantenimiento continuo con revisiones trimestrales detecta la deuda cuando aún es barata de corregir, en vez de cuando ya bloquea la campaña que marketing necesita lanzar la semana que viene.
Preguntas frecuentes sobre deuda técnica
¿Qué es exactamente la deuda técnica?
Es el coste adicional que asume un equipo de desarrollo cuando prioriza la rapidez sobre la solución correcta. No es un fallo puntual: es la diferencia acumulada entre el código que existe y el que el negocio necesitaría para avanzar sin fricción.
¿Cómo se mide la deuda técnica de una web?
No hay una cifra única válida para todos los casos. Se aproxima combinando el tiempo que tardan los cambios pequeños, la frecuencia de errores tras cada despliegue y si el software depende de versiones sin soporte oficial.
¿Cuánto cuesta ignorar la deuda técnica?
Según Stripe, los equipos dedican de media un tercio de su tiempo a mantenimiento y código problemático en vez de a funciones nuevas. Ese tiempo se paga igual, se use en corregir un fallo o en construir algo nuevo.
¿Quién debe decidir si se parchea o se reescribe?
La decisión técnica corresponde al equipo de desarrollo, pero el presupuesto y el calendario los marca quien dirige marketing o sistemas. Por eso conviene pedir siempre el porqué en términos de negocio, no solo de código.