Ideia principal

O contexto que absorve os e-mails de um condomínio começa com um arquivo context.md e uma frase: agregue e separe por tema. Esse nível se sustenta até percebermos que o estado atual apagou o histórico da obra — e acrescentamos um log cronológico. Ele se sustenta de novo até os homônimos e os nomes duplos produzirem fichas repetidas — e escrevemos diretrizes de negócio. Depois o arquivo passa das mil linhas e a janela do modelo se perde ali dentro — tiramos as diretrizes, e depois recortamos por tema. Depois o vocabulário técnico se repete em cada arquivo — centralizamos tudo num glossary.md.

Cada degrau tem, portanto, uma causa que dá para nomear, e essa causa é sempre uma falha do nível anterior, nunca uma melhoria desejada no abstrato. É isso que distingue uma subida de complexidade de um superengenheiramento: a primeira responde a uma necessidade que se manifestou, o segundo a uma arquitetura que achávamos bonita. O teste está disponível antes de cada andar — que problema concreto, já encontrado, este andar elimina?

A ordem que resulta disso também não é intercambiável: só dá para recortar direito por tema depois de ter tirado as regras de tratamento, senão não sabemos o que precisa ser copiado em cada pedaço. E a cada degrau temos um sistema que funciona — não uma obra pela metade que só vai servir quando estiver pronta.

Por que isso importa

Isso inverte a maneira de encarar um sistema descrito por outra pessoa. Diante de um modelo completo — pastas, manifestos de carregamento, notas atômicas ligadas —, a leitura natural é a de um plano a instalar; a leitura útil é a de uma trajetória, da qual só adotamos os andares cuja falha já encontramos.

Também dá um critério de decisão para as versões seguintes: mudamos de versão porque as necessidades cresceram, e constatar que uma necessidade não cresceu é razão suficiente para ficar onde se está.

Nuances e limites

Algumas falhas são previsíveis para quem já construiu um sistema parecido, e esperar que aconteçam custa uma migração que daria para evitar. A regra protege do superengenheiramento, não da ingenuidade.

E nem toda falha se manifesta como uma carência. A perda de precisão de um modelo num arquivo longo não produz alerta nenhum: ela degrada aos poucos respostas que continuam plausíveis, e o degrau seguinte só é vencido se alguém tiver nomeado o mecanismo de antemão.

Questões em aberto

• O que, num sistema em uso, indica que ele não basta mais, quando a falha não assume a forma de uma resposta visivelmente errada?