Idea principal

Cada ficha de un repositorio de producto lleva un diario donde se añaden entradas sin corregir nunca las anteriores. Una entrada que cita una versión del código señala que el producto ha cambiado. Una entrada que no la cita señala otra cosa: es nuestra comprensión la que ha cambiado, no el software.

La distinción parece menor en el momento de escribirla. Es ella la que permite, seis meses después, responder a una pregunta que nadie sabe tratar de otro modo: ¿se corrigió una ficha, o evolucionó el producto? Sin ella, los dos movimientos se confunden en un mismo "actualizado el".

El mecanismo de mantenimiento se sostiene con ella: la versión de referencia sirve de cursor y da, mediante un comando, la lista de lo que se ha movido en el producto desde la última actualización, es decir, la lista de lo que queda por consignar.

Por qué es importante

Eso separa dos naturalezas de obsolescencia que piden gestos distintos. Una ficha atrasada respecto al producto se pone al día mecánicamente, releyendo las fuentes de la nueva versión. Una ficha corregida porque se había entendido mal exige una pregunta: ¿qué nos engañó, y esa causa ha desaparecido?

Permite también juzgar la fiabilidad de una descripción: una ficha cuyo diario solo recoge correcciones de comprensión se escribió demasiado deprisa.

Matices y límites

El mecanismo supone que una versión del producto sea citable: un repositorio, un número de release. En un sistema sin una referencia versionada clara, la distinción se vuelve declarativa y se desgasta.

Y el diario por adición crece sin límite: a partir de cierto volumen hay que saber qué hacer con él, y ese es un problema que esta nota no resuelve.

Preguntas abiertas

• ¿A qué ritmo actualizar la versión de referencia, sabiendo que cada aplazamiento alarga la lista de lo que habrá que consignar de golpe?