Software que começa pela evidência

A maioria dos softwares faz afirmações sem evidência. Um dashboard diz que a receita subiu. Um motor de recomendação diz que você vai gostar disto. Um escore de risco diz que este paciente é prioridade. Clique em qualquer um deles e pergunte por quê, e a resposta costuma ser silêncio, ou um tooltip que ninguém consegue rastrear até uma fonte. Passei a achar que essa é a falha de design mais profunda do software moderno, e em ferramentas científicas ela é desclassificatória.

O que significa começar pela evidência

A conclusão é a última coisa que o sistema produz, não a primeira. Antes de um número chegar à tela, o sistema precisa ter reunido as entradas que o sustentam, registrado quais foram usadas e mantido tudo isso preso à saída. O usuário precisa conseguir abrir qualquer afirmação e ver a trilha: este valor, destas fontes, transformado deste jeito, neste horário. Se a trilha não existe, a afirmação não vai para produção.

Parece caro. É mais barato do que a alternativa, que é ninguém confiar no sistema e todo mundo refazer o cálculo numa planilha para conferir.

A estrutura de dados é uma afirmação com anexos

Na prática, modelo saídas como afirmações. Uma afirmação tem um valor, uma confiança ou status e uma lista de itens de evidência. Cada item aponta para uma fonte, um local dentro dessa fonte e a transformação que o conectou à afirmação. Não é nada exótico. É um esquema pequeno com uma chave estrangeira. A disciplina está em se recusar a criar uma afirmação sem pelo menos um item de evidência, e em fazer a interface mostrar a evidência a um clique do valor.

Quando audito um sistema, o primeiro sinal de problema é uma tabela em que números importantes estão guardados sem nada apontando de volta para a origem. Significa que alguém calculou uma vez, estava confiante e seguiu em frente. Seis meses depois ninguém consegue reproduzir e ninguém tem coragem de apagar.

Instrumente antes de decidir

Começar pela evidência também vale para a construção do próprio software. Antes de adicionar uma funcionalidade que promete melhorar algo, quero a medição no lugar que mostraria se melhorou. Antes de otimizar uma query, quero o trace que mostra que ela é lenta. Antes de aceitar que a saída de um modelo é útil, quero o conjunto de avaliação e a linha de base. É o hábito do pré-registro, da ciência, aplicado à engenharia: diga o que espera, depois olhe.

Times resistem porque isso atrasa a primeira semana. Acelera todas as seguintes, porque discussões viram consultas.

Onde isso mais importa

Num instrumento científico, começar pela evidência não é uma propriedade agradável. É a diferença entre uma ferramenta e um gerador de boatos. Um sistema que sugere uma hipótese sobre doença cardiovascular precisa conseguir mostrar quais artigos, quais dados, qual raciocínio levaram até ali, e precisa ser honesto sobre o que não tem. Uma hipótese sem trilha de evidência não está acelerando a ciência. Está adicionando ruído a um campo que já tem ruído demais.

Esse é um dos princípios a que submeto a ELUCENIA: toda hipótese precisa de evidência. Não como slogan, como restrição. Se a evidência está vazia, a afirmação não existe.

O hábito se transfere

Depois de construir um sistema assim, não dá para voltar atrás. Você começa a olhar para todo dashboard perguntando de onde veio o número, e percebe com que frequência ninguém sabe. Esse desconforto é útil. É o mesmo desconforto que um bom cientista sente ao ler uma afirmação sem citação, e é exatamente o instinto que o software passou duas décadas treinando seus usuários a perder.