Idea principal

El legacy se cuenta como una herencia: código antiguo, decisiones pasadas, arquitecturas frágiles, dependencias mal documentadas, elecciones que tenían sentido ayer. Presentado así, se sufre: se hereda, y uno se apaña.

La parte que no se sufre es la que se está escribiendo ahora. Un defecto transferido a otra persona, una especificación vaga aceptada sin discusión, una prueba nunca escrita, una regresión repetida a mano sprint tras sprint, una QA usada como red final, un código entregado deprisa y mal entendido: cada uno de estos gestos es una renuncia fechada, y cada uno se convierte en una línea del legacy que el equipo descubrirá dentro de dos años.

Lo que tienen en común no es la precipitación. Es un desplazamiento: la responsabilidad de la calidad abandona a quien todavía podía ejercerla, y el producto conserva el rastro de ese desplazamiento mucho después de que todo el mundo haya olvidado la restricción que lo motivó.

Por qué es importante

Esto convierte una fatalidad en algo arbitrable. Mientras el legacy sea una herencia, exige planes de recuperación; una vez visto como una producción corriente, se convierte en consecuencia de decisiones que se toman esta semana, y sobre las que se puede actuar sin presupuesto dedicado.

Da también una lista de indicadores adelantados: los gestos de aplazamiento citados son observables de inmediato, mientras que su efecto solo lo es al cabo de años.

Matices y límites

No todo aplazamiento es una falta. Algunas deudas se contraen a sabiendas, por una razón fechada, y se devuelven: la diferencia está en que se nombren como tales en el momento en que se asumen.

Y el legacy no viene solo de renuncias: una tecnología envejece, un mercado cambia, una arquitectura correcta se vuelve inadecuada sin que haya habido ningún gesto de aplazamiento.

Preguntas abiertas

• ¿Cómo reconocer, en el momento en que se hace, que un aplazamiento es una deuda nombrada y no una renuncia ordinaria?