Construir sistemas que duram

Durar não é o mesmo que não quebrar. Um sistema que dura é aquele que continua podendo ser modificado por pessoas que não o construíram, sob condições que ninguém previu, sem que cada alteração exija coragem.

As forças que corroem essa propriedade não são adversariais. São ordinárias, previsíveis e chegam para todo mundo: as pessoas mudam de emprego, os fornecedores mudam de produto, o volume cresce. Cada uma ataca uma parte diferente do sistema, e vale examiná-las separadamente antes de falar do que têm em comum.

Rotatividade ataca o que só existe na cabeça de alguém

Quando alguém sai, o código fica. O que vai embora é o modelo do código: por que aquela fila tem aquele tamanho, quais dois módulos não podem ser reordenados, qual exceção é impossível de verdade e qual é apenas rara. Sobrevive o que foi externalizado — em nomes, em fronteiras, em duas linhas de texto ao lado da decisão.

O sintoma observável é a latência entre alguém chegar e conseguir fazer sozinho a primeira alteração segura. Essa latência é a medida mais honesta de quanto do sistema existe fora das pessoas. E há uma regra derivada que vale para qualquer equipe: toda restrição sustentada por disciplina é uma restrição que vai embora com quem a sustentava. Se a única coisa que impede uma chamada perigosa é o hábito de não fazê-la, o sistema não tem essa restrição — ele tinha uma pessoa.

Troca de fornecedor ataca o acoplamento não declarado

Trocar um fornecedor é o teste de esforço de uma fronteira. O custo da troca não é proporcional à importância do fornecedor; é proporcional a quanto do formato dele vazou para dentro do seu modelo. E o vazamento acontece por caminhos discretos: os identificadores dele guardados como chave nas suas tabelas, o vocabulário dele adotado no seu domínio, a semântica de erro dele espalhada pelo seu fluxo de controle, a latência típica dele assumida no desenho da sua interface.

A assimetria aqui é específica e brutal. Na integração inicial, manter uma camada de tradução custa uma interface e alguma disciplina de nomeação. Depois, a mesma camada custa uma migração de dados, porque a essa altura o vazamento não está mais no código: está no estado acumulado. Código se reescreve. Histórico se reconcilia, e reconciliação é o tipo de trabalho que consome cronograma sem produzir nada visível.

Uma fronteira é barata enquanto é uma decisão. Depois, ela é uma migração.

Crescimento de volume ataca o que era adequado

Volume raramente quebra a correção. Ele quebra as suposições sobre tempo, e o primeiro efeito costuma ser operacional, não técnico. O processo que dava para reexecutar à mão deixa de dar. O relatório que levava um minuto passa a levar a noite inteira e, por isso, passa a rodar uma vez por semana. A revisão manual que cobria tudo passa a cobrir uma parte.

Esse último é o mais importante e o menos notado: o crescimento converte, em silêncio, processos completos em processos amostrados. É uma mudança de controle que ninguém aprovou, que não aparece em nenhum registro e que só é descoberta quando algo passa exatamente pela parte que deixou de ser olhada. Nenhum alarme dispara, porque o sistema continua fazendo o que sempre fez — só que agora sobre uma fração do que existe.

Por que tudo isso é barato antes e caro depois

A observação central deste texto é que a curva de custo dessas propriedades não é linear. Ela é convexa, por três razões que se somam:

1. 01Acrescentar a propriedade depois exige aplicá-la ao estado que já existe. A mudança de código é pequena; a reconciliação do histórico não é, e é ela que consome o prazo.
2. 02Depois, a propriedade precisa ser instalada com o sistema em operação. Toda alteração passa a carregar risco de migração que a versão feita no desenho simplesmente não tinha.
3. 03Depois, ela precisa ser negociada com quem já depende do comportamento atual — inclusive do comportamento que nunca foi intencional, mas que se tornou observável e, portanto, virou contrato de fato.

A terceira razão é a que surpreende times experientes. Um sistema com uso real não tem apenas a interface que documentou; tem todo comportamento que alguém do lado de fora conseguiu observar e passou a usar. Corrigir uma dessas coisas mais tarde deixa de ser correção e passa a ser quebra, com aviso, prazo de transição e trabalho de migração feito por terceiros que não pediram nada disso.

O que é barato no desenho

Vale ser concreto sobre o tamanho real dessas decisões, porque a palavra arquitetura sugere um peso que elas não têm. Nomear uma fronteira custa uma conversa e um documento curto. Escrever por que um limiar tem o valor que tem custa uma frase, escrita no momento em que a razão ainda é óbvia para quem escreve. Tornar um estado consultável custa decidir onde ele mora antes de espalhá-lo. Tornar uma operação idempotente custa um identificador carregado desde a origem. Manter uma tradução na borda de um fornecedor custa uma interface. Nenhuma delas é sofisticada, e todas são difíceis de acrescentar no ano seguinte.

Quase tudo o que faz um sistema durar é barato exatamente enquanto ainda é reversível.

Há uma consequência desconfortável nisso. As decisões que mais determinam a vida útil de um sistema são tomadas na semana em que ele é menos importante, por quem tem menos informação, sob a pressão de mostrar algo funcionando. Não existe solução organizacional elegante para essa inversão. Existe uma solução chata: tratar essa lista curta como parte do que significa entregar, e não como qualidade a ser acrescentada quando houver folga — porque nunca há.

Publicamos isto como nota de pesquisa, e não como método. É o quadro contra o qual desenhamos hoje: três forças ordinárias, um conjunto pequeno de propriedades que resistem a elas, e uma assimetria de custo que explica por que quase ninguém as aplica no momento em que são baratas. Se a prática nos mostrar que uma dessas peças está errada, corrigimos em público, aqui.