Por que construir software é difícil: o custo da ambiguidade

Construir software é difícil porque o código é apenas a parte visível do sistema. O trabalho mais complexo é concordar sobre o que o sistema deve significar quando existem pessoas, dispositivos, tempo real e falhas reais.

Para um fundador, isso aparece como atrasos, retrabalho e um produto que funciona na demonstração, mas não no mundo real. Para um CTO, aparece como requisitos ambíguos, premissas conflitantes e integrações difíceis de reproduzir.

O bug mais caro pode ser uma pergunta sem resposta

Uma equipe pode escrever um código excelente e ainda construir a coisa errada. O que significa “autorizado”? Qual relógio decide se o acesso é permitido? O que acontece quando uma mensagem chega atrasada? “Nada aconteceu” significa sucesso, negação, timeout ou erro interno?

Fred Brooks explicou em No Silver Bullet que a dificuldade essencial está em especificar, projetar e testar o sistema conceitual. A ambiguidade mais cara costuma existir antes da primeira linha de código.

Uma integração real que falhou

Testei uma integração em tempo real com hardware edge. Outro aplicativo enviava uma solicitação de acesso a um prédio. A política de autorização era complexa, e precisávamos definir mensagens, payloads e sequência.

Meu teste local parecia correto. No teste real, falhou porque havia uma regra que não estava no meu modelo: o dispositivo verificava primeiro o horário. Fora do horário permitido, não fazia nada.

Esse “nada” não era mensagem, erro nem resposta de autorização. Era ausência de comportamento observável. O dispositivo não necessariamente estava quebrado; nossa compreensão compartilhada estava incompleta.

Mais condições criam mais realidades possíveis

O hardware podia operar de cinco formas ou mais dependendo do horário, do estado do dispositivo, da autorização, da conectividade e da ordem das mensagens. Um teste local cobre um caminho. A produção visita os caminhos que ninguém escreveu.

É por isso que sistemas distribuídos são difíceis: mensagens atrasam, duplicam, mudam de ordem, são rejeitadas ou ignoradas. Um payload válido pode ser inválido no estado atual.

Os princípios de Designing Data-Intensive Applications e do livro de SRE do Google reforçam a mesma ideia: confiabilidade, operação e falhas precisam fazer parte do design.

Comunicação também é arquitetura

Em software, comunicação não é apenas uma habilidade comportamental; é uma dependência técnica. Toda premissa não documentada vira um ramo oculto. Cada interpretação diferente de “aprovado”, “disponível” ou “processado” vira risco de compatibilidade.

Arquitetura também é o acordo entre as pessoas e os sistemas responsáveis por cada parte. Se as equipes não compartilham um modelo claro do problema, a arquitetura expõe essa lacuna.

IA não elimina a necessidade de clareza

A IA pode ajudar com pesquisa, implementação, testes e documentação. Mas normalmente ela faz o que pedimos. Se o objetivo estiver errado, as instruções forem ambíguas ou deixarmos decisões importantes no piloto automático, a IA pode acelerar a direção errada.

Isso não é motivo para evitar IA. É motivo para melhorar o sistema ao redor dela: definir o resultado, as restrições, as falhas inaceitáveis e quando uma pessoa precisa revisar o resultado.

O que líderes devem tornar explícito

• Qual resultado de negócio esse fluxo precisa proteger?
• Quais são os estados e transições válidos?
• Quais condições mudam o resultado?
• O que significam sucesso, negação, timeout e falha?
• Quem é responsável por cada decisão?
• Como um operador saberá o que aconteceu?
• O que precisa ser determinístico?

O objetivo não é eliminar toda incerteza. É decidir onde ela é aceitável e onde é perigosa. Uma recomendação pode ser probabilística; uma autorização, cobrança ou limite de segurança normalmente precisa de regras explícitas e observáveis.

Atrasos de software muitas vezes são atrasos de decisão e comunicação disfarçados. Equipes rápidas não deixam de pensar: resolvem cedo as perguntas certas e conectam o objetivo de negócio ao comportamento técnico.

A qualidade do código importa. Mas, antes de o código poder ser bom, a equipe precisa concordar sobre o que é um bom comportamento.

Isso já aconteceu na sua equipe? Uma funcionalidade parecia correta isoladamente, mas falhou quando o sistema completo, suas regras ocultas e as condições reais entraram em cena? Essa lacuna costuma ser o ponto de partida do trabalho de engenharia mais valioso.