A Lei de Tesler e o Pecado da Complexidade Invisível

Complexidade não some. Ela migra.

Essa é a Lei de Conservação da Complexidade, formulada por Larry Tesler nos anos 80, e amplamente ignorada por quem mais deveria temê-la: engenheiros de software.

No universo de design de produto, a lei é quase um mantra. Quando um formulário elimina um campo, alguém no backend passa a inferir aquela informação. Quando uma interface esconde uma opção avançada, um engenheiro de suporte passa a receber o ticket. A complexidade que sumiu da tela apareceu em outro lugar, com outra cara e outro custo.

Na engenharia de software, a lei opera com a mesma intensidade, mas com uma diferença fatal: o destino da complexidade costuma ser invisível até o momento em que ela cobra sua dívida.

E esse momento, invariavelmente, é o pior possível.

A Ilusão da Abstração que Resolve

Toda decisão arquitetural que parece simplificar é, na prática, uma decisão sobre onde alocar complexidade.

Adotar um framework de ORM elimina a complexidade de escrever SQL. Mas transfere para o desenvolvedor a responsabilidade de entender o que aquele framework gera em tempo de execução (ex: quando ele vai ao banco, quantas queries produz, qual é o plano de execução resultante). A complexidade do SQL não desapareceu. Ela foi encapsulada.

Encapsulamento sem compreensão é uma bomba com timer.

Adotar uma plataforma de mensageria gerenciada elimina a complexidade operacional de manter brokers. Mas transfere para a arquitetura a responsabilidade de lidar com duplicação de mensagens, ordenação, falhas de idempotência e latência. A complexidade do protocolo não desapareceu. Ela foi terceirizada. E terceirização sem contrato explícito de falha é ingenuidade camuflada de pragmatismo.

Adotar um BaaS (Banking as a Service), um iPaaS (Integration Platform as a Service), ou qualquer plataforma que prometa "sem configuração" elimina a complexidade de infraestrutura. Mas transfere para o produto a dependência de rate limits, modelos de custo opacos e roadmaps fora do seu controle. A complexidade operacional não desapareceu. Virou risco de vendor lock-in com EBITDA embutido no preço do serviço.

A abstração não é uma solução. É uma decisão sobre quem paga a conta da complexidade e quando.

O problema não está em abstrair. Abstrações habilitam a evolução de sistemas. O problema está em abstrair sem consciência do destino. Em tratar a complexidade como algo que pode ser eliminado, quando ela apenas muda de endereço.

Onde a Complexidade Escondida Cobra o Preço

Complexidade alocada de forma irresponsável não quebra o build no dia do deploy. Ela apodrece silenciosamente, manifestando-se seis meses depois sob o sintoma clássico da lentidão inexplicável.

O sistema funciona. Nada cai. Mas adicionar um novo meio de pagamento leva três vezes mais tempo do que no ano passado. Cada refactor exige expedições arqueológicas. O desenvolvedor original que entendia os atalhos já saiu da empresa, e quem ficou não tem como saber onde estão as minas terrestres.

Isso é dívida de complexidade acumulada. Ela é letal porque o SonarQube não a detecta e o pipeline não a bloqueia. Ela só aparece quando o negócio exige velocidade e a engenharia descobre que os pés do time estão presos em concreto. O que levava duas semanas no primeiro ano, agora leva dois meses.

Não porque o time ficou pior. Porque a complexidade acumulada nos lugares errados passou a cobrar juros compostos sobre cada decisão nova.

O Arquiteto e a Responsabilidade do Destino

A Lei de Tesler não é uma sentença de resignação. Ela é uma bússola de responsabilidade.

Se toda decisão arquitetural aloca complexidade, então a pergunta que o arquiteto precisa responder não é "como eliminamos complexidade?". Essa pergunta não tem resposta, porque a premissa é falsa. A pergunta correta é: para onde estamos empurrando a complexidade, e esse destino é consciente e sustentável?

Existem três destinos possíveis para complexidade em sistemas de software:

Para o usuário. O sistema é mais simples internamente, mas o usuário precisa entender mais, configurar mais, ou tolerar mais falhas visíveis. Às vezes essa é a troca certa, especialmente quando o usuário tem contexto suficiente para gerenciar o que recebe. Mas precisa ser uma decisão explícita, não um efeito colateral de um prazo.

Para a plataforma. A complexidade vai para uma camada de infraestrutura, orquestração ou serviço gerenciado. O custo se materializa em latência adicionada, dependências externas, custo de operação e limitações de observabilidade. Novamente, pode ser a troca certa. Mas o contrato precisa estar na mesa.

Para o engenheiro. A complexidade fica implícita no código, nas convenções não documentadas, nas decisões que só existem na cabeça de quem as tomou. Esse é o destino mais perigoso, porque não tem dono formal, não tem custo visível e se acumula silenciosamente até se tornar o principal ativo de risco do sistema.

O terceiro destino é o mais comum. E é o que transforma sistemas vivos em sistemas que ninguém tem coragem de tocar.

Complexidade Explícita vs. Complexidade Acidental

Nem toda complexidade é igual. Essa é a distinção que separa arquitetura de artesanato.

Complexidade essencial é aquela que existe porque o problema é genuinamente complexo. Um sistema de autorização de transações financeiras é complexo porque o domínio é complexo: concorrência, consistência, reversibilidade, auditoria. Essa complexidade não pode ser eliminada. Pode ser gerenciada.

Complexidade acidental é aquela que existe porque as decisões de implementação a criaram. Camadas de abstração desnecessárias, acoplamentos implícitos, convenções não documentadas, contratos informais entre módulos. Essa complexidade pode ser eliminada. E precisa ser, porque ela não protege nenhum valor de negócio, ela apenas drena velocidade de evolução.

A Lei de Tesler diz que a complexidade essencial é conservada. O que ela não diz, mas precisa ser dito, é que a complexidade acidental é adicionada, não conservada. Ela é criada por escolhas ruins e acumulada por ausência de deliberação.

O trabalho do arquiteto é duplo: gerenciar a complexidade essencial com rigor, e eliminar a complexidade acidental.

Complexidade essencial bem gerenciada é robustez. Complexidade acidental acumulada é entropia com CNPJ.

O Custo de Negócio que Ninguém Coloca no Budget

Quando a complexidade é mal alocada de forma sistemática, o impacto não fica limitado ao repositório de código. Ele vaza para o P&L da companhia através de três vetores:

O custo de Onboarding: Sistemas com complexidade escondida nas abstrações exigem meses para que um engenheiro consiga contribuir com segurança. O conhecimento está nos desenvolvedores originais, não na arquitetura. Quando eles saem, o custo de reposição não é o salário do substituto, mas os meses de produtividade perdida desenterrando o que foi ocultado.

A hemorragia do MTTR: Sistemas onde a complexidade foi empurrada para camadas opacas produzem falhas sem causa raiz localizável. O incidente existe, o impacto é mensurável, mas a origem é arqueologia. Cada hora de war room é OPEX queimado rastreando uma decisão arquitetural que ninguém lembra ter tomado.

O Custo de Oportunidade: Quando o sistema se torna lento demais para evoluir, a empresa perde capacidade de resposta. Features que os competidores entregam em semanas levam trimestres. A janela de oportunidade fecha enquanto o time tenta entender no que está pisando.

Esses três vetores raramente aparecem no relatório que aprovou a abstração original. E é por isso que a lei continua sendo violada sistematicamente:

O custo da complexidade mal alocada é diferido. O benefício da abstração é imediato.

Síntese: Tornar o Invisível Visível

A Lei de Tesler não pede que a engenharia renuncie à abstração. Ela pede maturidade suficiente para fazer a pergunta certa antes de cada decisão.

Não "como simplificamos isso?", mas "para onde vai a complexidade que estamos removendo daqui?".

Não "qual framework resolve esse problema?", mas "qual é o contrato de complexidade que esse framework nos impõe e quem no time é capaz de honrá-lo?"

Não "que plataforma gerencia isso por nós?", mas "quais são os limites, os custos e as falhas dessa plataforma que passamos a herdar?"

Arquitetura de software não é a arte de eliminar complexidade. É a disciplina de torná-la explícita, alocada com intenção e sustentável ao longo do tempo.

Complexidade invisível não é arquitetura elegante.

É passivo não declarado no balanço técnico. E passivo oculto, inevitavelmente, desconta no EBITDA - sempre.