La deuda de compatibilidad forzada

El coste que aparece cuando ya es tarde

Hay proyectos de software que parecen avanzar bien durante un tiempo.
La primera versión funciona.
La segunda se adapta.
La tercera empieza a costar un poco más.

Y entonces llega un punto en el que cada cambio duele.

No porque el equipo no sepa desarrollar.
No porque la tecnología sea mala.
Sino porque el sistema empieza a arrastrar decisiones pasadas que ya no se pueden deshacer.

A eso lo llamamos deuda de compatibilidad forzada.

Qué es la deuda de compatibilidad forzada

La deuda de compatibilidad forzada aparece cuando un sistema tiene que seguir siendo compatible con lo que ya existe, aunque su estructura original ya no tenga sentido.

No hablamos de mantener versiones antiguas por comodidad.
Hablamos de no poder romper nada.

Datos ya introducidos.
Procesos ya en marcha.
Integraciones que dependen de estructuras antiguas.
Usuarios que trabajan sobre supuestos que ya no son válidos.

El sistema evoluciona, pero lo hace cargando con el pasado.

No es deuda técnica. Es algo peor.

La deuda técnica suele poder pagarse.
Refactorizas, limpias, mejoras.

La deuda de compatibilidad forzada no se limpia.
Se gestiona.

Cada decisión nueva tiene que convivir con decisiones antiguas.
Cada cambio necesita capas intermedias.
Cada mejora exige traducciones, conversiones o excepciones.

El software no se rompe.
Pero se vuelve pesado.

Cómo se genera (sin que nadie lo decida)

Esta deuda no aparece por mala praxis.
Aparece por decisiones razonables en su momento:

• “Ya lo ajustaremos más adelante”

• “De momento con esto nos vale”

• “No hace falta pensar ahora en ese escenario”

• “Si cambia, ya lo adaptaremos”

Todo eso funciona… hasta que deja de funcionar.

El problema no es decidir rápido.
El problema es no decidir bien lo que no se puede cambiar después.

El momento en que el proyecto empieza a frenar

La deuda de compatibilidad forzada no se nota al principio.
Se nota cuando:

• cada nueva funcionalidad cuesta el doble

• cualquier cambio pequeño requiere análisis largos

• aparecen módulos “raros” que nadie quiere tocar

• el sistema se vuelve frágil

• avanzar genera más miedo que ilusión

En ese punto, el proyecto sigue vivo, pero ya no es ágil.

Rehacer ya no es empezar de cero

Cuando esta deuda está presente, “rehacer” deja de ser una opción limpia.

No puedes borrar datos.
No puedes cambiar estructuras sin migrar.
No puedes simplificar sin romper usos existentes.

Rehacer significa:

• mantener compatibilidad

• escribir software que adapta software

• convivir con modelos antiguos y nuevos

• aumentar complejidad para poder avanzar

El sistema crece, pero cada vez cuesta más sostenerlo.

Arquitectura: la decisión que nadie ve… hasta que falla

La mayoría de estos problemas no tienen su origen en el código.
Tienen su origen en decisiones estructurales tempranas.

Cómo se modela la información.
Qué se considera estable y qué no.
Qué se deja abierto y qué se cierra desde el inicio.

Cuando estas decisiones se posponen, el precio no se paga el primer día.
Se paga cuando el proyecto ya no puede parar.

No todo proyecto necesita evitarla

No todos los sistemas necesitan una arquitectura pensada para diez años.
No todos los proyectos justifican ese esfuerzo.

Pero cuando un sistema:

• va a crecer

• va a vivir en el tiempo

• va a acumular información

• va a ser base de decisiones futuras

ignorar esta deuda no la elimina.
Solo la desplaza.

La pregunta que conviene hacerse antes

Antes de empezar un proyecto que se espera que evolucione, conviene hacerse una pregunta sencilla:

¿Hay decisiones que, si las tomamos mal ahora, no podremos corregir después?

Si la respuesta es sí, ahí es donde merece la pena parar y pensar.

Hay otro patrón que suele aparecer antes de este, y que muchas veces pasa desapercibido.

Sistemas que se entregan sin una puesta en marcha real.
Herramientas que existen, pero que no terminan de usarse.
Soluciones que funcionan técnicamente, pero no se integran en el día a día.

A esto lo llamamos el síndrome del software vacío.

Cuando un sistema no se valida en uso real desde el inicio, las decisiones estructurales se toman a ciegas. Y cuando ese sistema empieza a crecer, la deuda no tarda en aparecer.

Puedes leer más sobre este patrón aquí:

 

La deuda de compatibilidad forzada no es un error puntual.
Es una consecuencia.

No aparece cuando algo falla.
Aparece cuando algo funciona… pero no estaba preparado para crecer.

Detectarla tarde no suele romper el proyecto.
Pero casi siempre lo vuelve lento, caro y difícil de sostener.

Y eso también es una forma de fallo.