Ideia principal

Cada ficha de um repositório de produto carrega um diário no qual as entradas são acrescentadas sem nunca corrigir as anteriores. Uma entrada que cita uma versão do código sinaliza que o produto mudou. Uma entrada que não cita nenhuma sinaliza outra coisa: foi a nossa compreensão que mudou, não o software.

A distinção parece menor na hora de escrever. É ela que permite, seis meses depois, responder a uma pergunta que ninguém sabe tratar de outro jeito: corrigimos uma ficha, ou o produto evoluiu? Sem ela, os dois movimentos se confundem em um mesmo "atualizado em".

O mecanismo de manutenção se sustenta nela: a versão de referência serve de cursor e entrega, com um comando, a lista do que mudou no produto desde a última atualização — ou seja, a lista do que ainda falta registrar.

Por que isso importa

Isso separa duas naturezas de obsolescência que pedem gestos diferentes. Uma ficha atrasada em relação ao produto se recupera mecanicamente, relendo as fontes da nova versão. Uma ficha corrigida porque tínhamos entendido errado pede uma pergunta: o que nos enganou, e essa causa desapareceu?

Também permite julgar a confiabilidade de uma descrição: uma ficha cujo diário só traz correções de compreensão foi escrita rápido demais.

Nuances e limites

O mecanismo pressupõe que uma versão do produto seja citável — um repositório, um número de release. Em um sistema sem referência versionada clara, a distinção vira declarativa e se desgasta.

E o diário só por acréscimo cresce sem limite: passado certo volume, é preciso saber o que fazer com ele, e esse é um problema que esta nota não resolve.

Questões em aberto

• Em que ritmo atualizar a versão de referência, sabendo que cada adiamento aumenta a lista do que será preciso registrar de uma vez só?