Ideia

A complexidade de uma funcionalidade se paga fora do código, na adoção, no suporte e na documentação

Info

Escrito originalmente em francês. Traduzido por IA — o sentido foi preservado, não a prosa.

Ideia principal

A complexidade de um produto normalmente é lida no código — tamanho dos arquivos, número de camadas, dependências. Essa é a parte mais barata. Uma funcionalidade entregue se paga depois no usuário que precisa entender para que ela serve, nos tickets de suporte que ela abre, na documentação que é preciso escrever e manter, na coerência de uma experiência que se embaralha a cada acréscimo, e na capacidade da organização de explicar o que está fabricando.

Essas frentes não aceleram. Quando o código vira o elo rápido, os gargalos se deslocam para a revisão, a segurança, o enquadramento funcional, a integração e a absorção humana — que ficam até mais críticos do que antes, já que recebem mais.

Um produto fica, portanto, ilegível, tanto para os usuários quanto para os times, assim que acrescentamos funcionalidades mais rápido do que entendemos o uso delas. Produzir mais código não é produzir mais valor; é deslocar a fatura para áreas que não a provisionaram.

Por que isso importa

Isso muda o que contamos quando decidimos sobre um acréscimo. O custo de desenvolvimento, agora baixo, deixa de ser um indicador do custo total, e uma estimativa que para no código subestima sistematicamente o que uma funcionalidade compromete.

Também dá ao suporte e à documentação um status de alerta antecipado: são os primeiros lugares onde uma complexidade decidida em outro lugar vira mensurável.

Nuances e limites

Nem toda complexidade recai sobre o usuário. Uma funcionalidade invisível, ativada por padrão e sem superfície de uso, pode pesar bastante no código sem custar nada em adoção nem em suporte — a fatura continua inteira, mas fica dentro do time.

E o raciocínio tem um limite: uma organização que só entregasse o que o suporte absorve sem esforço entregaria pouco e deixaria um concorrente ocupar o espaço. A questão é a provisão, não a abstenção.

Questões em aberto

  • Como estimar, antes de entregar, a carga de adoção e de suporte de uma funcionalidade, de outro jeito que não constatando depois os tickets que ela gera?