Idea principal

Describir un software supone fijar un instante: una versión del código, y todo lo que gira con ella — la base tal como está en esa versión, las pantallas de esa versión, las traducciones de esa versión. Es la foto, y define lo que tiene derecho a entrar.

Una exportación de base de datos hecha unos meses antes parece, sin embargo, utilizable: describe el mismo producto, poco más o menos. En realidad describe un producto más antiguo, y ese "poco más o menos" es precisamente lo que se buscaba. En una parte entera, había objetos presentes en el código que no tenían ninguna tabla correspondiente en la exportación — y la conclusión que se sacó fue que no existían.

La regla no es "comprobar la fecha antes de concluir", porque esa vigilancia no se sostiene en el tiempo. Es más radical: una fuente de otra fecha se sustituye por una versión al día, o se prescinde de ella.

Por qué es importante

Es lo que impide un error mudo. Una fuente caducada no produce un mensaje de error: produce una ausencia, y una ausencia se lee como una información — "este objeto no existe" — cuando no dice nada.

Y la regla se controla sin juicio: cada fuente lleva su versión, o queda fuera del perímetro. Es una condición de admisión, no una precaución de lectura.

Matices y límites

La exigencia solo vale para las fuentes que se supone que describen el estado del producto. Los materiales que recogen lo que la gente dice — actas de entrevistas, tickets — están datados por naturaleza y conservan su valor: no describen el producto, describen un uso.

La restricción tiene un coste real: reconstruir una fuente en la versión correcta lleva tiempo, y la tentación de usar la que se tiene a mano vuelve en cada parte.

Preguntas abiertas

• ¿Con qué ritmo hay que rehacer la foto, sabiendo que cada desfase transforma progresivamente las fuentes disponibles en fuentes inadmisibles?