Todo programador deveria aprender com o DHH Featured Post

Eu ainda me lembro, com uma clareza que assusta, dos meus primeiros deploys no final dos anos 90. O ritual era quase artesanal, mas de uma simplicidade absurdamente eficiente. Eu tinha meu código — um emaranhado de PHP e HTML, provavelmente — rodando na minha máquina local com um WAMP ou XAMPP da vida. Quando estava "pronto", o processo era um só: abrir um cliente de FTP, arrastar os arquivos para uma pasta public_html num servidor compartilhado qualquer, e pronto. Estava no ar. O mundo podia ver. O ciclo completo, da ideia à produção, podia levar minutos.

Avance rápido para 2025. Hoje, para colocar um simples "Hello World" no ar, um desenvolvedor júnior precisa navegar por um labirinto que faria Teseu pedir um GPS. Ele precisa criar um repositório no Git, escrever um Dockerfile, talvez um docker-compose.yml para rodar localmente, configurar um pipeline de CI/CD em um arquivo YAML cuja sintaxe parece ter sido desenhada por um inimigo, esperar esse pipeline construir uma imagem, empurrá-la para um registro como o ECR ou o Docker Hub, para só então, talvez, um outro processo pegar essa imagem e, através de scripts de Terraform ou manifestos de Kubernetes, finalmente publicá-la em um cluster na nuvem, por trás de um load balancer, dentro de uma VPC, com as roles de IAM corretas.

Respire. Releia o parágrafo anterior. Em algum ponto dessa jornada, nós, como indústria, perdemos o rumo. Nos apaixonamos tanto pelas ferramentas, pelas abstrações e pela complexidade que esquecemos o objetivo final: entregar software que funciona. E é por isso que a recente palestra de David Heinemeier Hansson, o DHH, soou não como uma novidade, mas como um grito de sanidade em meio a um hospício de complexidade autoimposta.

Eu preciso ser transparente aqui: sou um grande fã do trabalho do David, mesmo nunca tendo programado em Rails. Ele é um gênio e encabeça dezenas de projetos fantásticos. É o tipo de desenvolvedor que eu sonhava ser, mas que, por caminhos da vida e do mercado, não pude. Ele tem a genialidade técnica de um Linus Torvalds, mas com uma dose de carisma, visão empreendedora e um pensamento crítico afiado que o torna único. Ele não apenas constrói coisas; ele questiona fundamentalmente como e por que as construímos. E sua última apresentação foi um soco no estômago da ortodoxia tecnológica atual. Ele verbalizou uma frustração que borbulha dentro de mim e de muitos veteranos da área há pelo menos duas década. A frase dele que ecoa na minha cabeça desde então é devastadora em sua simplicidade: "Não faz o menor sentido a quantidade de complexidade que a gente inseriu ao longo desse tempo."

Não, David. Não faz o menor sentido mesmo. E está na hora de falarmos sobre isso.

Por que pagamos uma fortuna por testes que rodam mais devagar?

Vamos começar pelo elefante na sala, ou melhor, na nuvem: o custo. A promessa original da nuvem era sedutora. Pague apenas pelo que usar. Escale infinitamente. Livre-se da dor de cabeça de gerenciar hardware. E, por um tempo, pareceu um negócio irrecusável. Migramos tudo. Aplicações, bancos de dados e, claro, nossos pipelines de automação.

É aqui que a palestra de DHH joga a primeira bomba. Ele questiona, com uma lógica irrefutável, por que diabos as empresas gastam centenas de milhares de dólares por ano em servidores de teste na nuvem — servidores que, na maioria das vezes, são comprovadamente mais lentos que a máquina que o desenvolvedor tem em sua própria mesa.

Pense na sua realidade. Quantas vezes você já não empurrou um commit e ficou olhando para a tela, esperando um pipeline de testes levar 15, 20, às vezes 30 minutos para ficar verde? Esse tempo não é só um número num dashboard. É um assassino silencioso de produtividade. O estado de flow, aquele mergulho profundo na resolução de um problema, é estilhaçado. Nesses 20 minutos, você vai pegar um café, olhar o Slack, se distrair com um e-mail. Quando o pipeline finalmente termina (muitas vezes em vermelho por um teste bobo), o esforço para voltar ao mesmo nível de concentração é imenso.

Na minha carreira, já vi projetos onde o deploy era um evento. Uma cerimônia que durava de uma a duas horas, às vezes um dia inteiro, e que paralisava a equipe. Tudo por conta de uma cadeia de processos lentos e caros rodando em "supercomputadores" alugados na AWS, Google Cloud ou Azure.

DHH expôs essa farsa de forma brilhante. Ele demonstrou um smoke test que, num servidor de nuvem padrão da indústria, levaria de 15 a 20 minutos. Em seu MacBook com chip Apple, rodou em 2 minutos e meio. Numa máquina Linux, o mesmo conjunto com mais de 30 mil parâmetros foi executado em pouco mais de 1 minuto.

A verdade nua e crua é que o hardware local evoluiu de forma exponencial. Um MacBook moderno ou um bom notebook Linux com processadores multi-core, dezenas de gigabytes de RAM e SSDs NVMe que atingem velocidades de leitura e escrita absurdas, são verdadeiras estações de trabalho de alta performance. E nós estamos usando esse poder todo para rodar um terminal, um VS Code e um navegador, enquanto terceirizamos o trabalho pesado para máquinas virtuais anêmicas e caras na nuvem, que muitas vezes compartilham recursos de forma ineficiente.

A provocação de DHH vai além: gastamos de 2 a 4 mil dólares por mês para rodar sistemas que poderiam, tranquilamente, operar a partir de um bom computador portátil. Isso não é otimização de custos, é um desperdício financeiro e de tempo de engenharia que deveria ser considerado criminoso.

O clímax de seu argumento foi o exemplo do evento Rails World 2025. Toda a infraestrutura — inscrições, vendas, chat, comunidade, fórum — rodou em um único servidor. E não era um supercomputador da NASA. Era uma máquina de 300 dólares, com mais de 200 GB de RAM e 16 núcleos, operando diretamente do closet de sua casa. Esse servidor aguentou o tranco de um evento global. Isso não apenas prova que é possível, mas expõe o quão inflada e desnecessária é a maior parte da infraestrutura que construímos para suportar aplicações que, realisticamente, nunca terão a escala do Facebook ou do Google. Nós nos preparamos para um apocalipse de tráfego que, para 99% das aplicações, jamais chegará. E pagamos um preço exorbitante por essa paranoia.

Será que esquecemos o poder que temos em nossas próprias mesas?

A velocidade dos testes locais não é apenas um detalhe técnico; é uma mudança de paradigma na experiência do desenvolvedor (o famoso DX - Developer Experience). Um ciclo de feedback rápido é a base do desenvolvimento ágil e iterativo. Se um desenvolvedor pode rodar a suíte completa de testes em um ou dois minutos, ele o fará com muito mais frequência. A cada pequena mudança. A cada refatoração. Ele pegará os erros mais cedo, ganhará confiança no seu código e se sentirá mais produtivo.

Quando esse ciclo leva 20 minutos, o comportamento muda. O desenvolvedor começa a "acumular" alterações antes de rodar os testes, porque o custo da espera é muito alto. Ele empurra o código para o servidor de CI e "reza" para que tudo passe. O processo se torna uma aposta, não uma verificação. A qualidade cai, a frustração aumenta.

"Ah, mas e a paridade de ambientes?", alguém irá gritar do fundo da sala. "Precisamos de Docker e da nuvem para garantir que o ambiente de desenvolvimento seja idêntico ao de produção!". Sim, esse é um argumento válido e um problema real que ferramentas como o Docker vieram resolver. Mas a questão que DHH nos força a encarar é: a solução se tornou mais complexa e dolorosa que o problema original?

Chegamos a um ponto onde a configuração para replicar o ambiente de produção localmente é, por si só, um projeto de engenharia. Consome tempo, recursos e exige um conhecimento específico que desvia o foco do desenvolvedor de sua tarefa principal: escrever a lógica de negócio da aplicação.

Estamos usando um canhão para matar uma mosca. Em vez de simplificar a produção para que se pareça mais com o desenvolvimento, nós complicamos o desenvolvimento para que ele imite a monstruosidade que criamos na produção. É um raciocínio invertido, que serve mais aos interesses dos provedores de nuvem e das consultorias de DevOps do que aos desenvolvedores e às empresas que os empregam. A verdade é que a maior parte das inconsistências entre ambientes poderia ser resolvida com boas práticas de desenvolvimento, gerenciamento de dependências e configurações baseadas em variáveis de ambiente — técnicas que existem há décadas.

Como transformamos o ato de publicar software em um ritual de burocracia?

Essa complexidade excessiva não vive apenas nos pipelines de teste. Ela permeou todo o ciclo de vida do desenvolvimento. Como mencionei no início, o contraste com o passado é gritante. Nos anos 90 e início dos 2000, era comum um único profissional ser responsável por tudo: back-end, front-end, banco de dados e o deploy via FTP. Não era perfeito, claro, mas era direto. O caminho entre o código e o usuário era uma linha reta.

Hoje, esse caminho é um labirinto de abstrações. O Docker, que prometia simplicidade com o "funciona na minha máquina, vai funcionar em qualquer lugar", trouxe consigo sua própria carga de complexidade. Agora precisamos escrever Dockerfiles, otimizá-los para ter múltiplas camadas, gerenciar versões de imagens, nos preocupar com vulnerabilidades nas imagens base. É uma nova disciplina por si só.

E acima disso, veio o ecossistema da nuvem. Para operar eficientemente na AWS, por exemplo, um profissional precisa entender de VPC, Subnets, Security Groups, IAM Roles, Policies, EC2, S3, RDS, ECS, EKS... a sopa de letrinhas é interminável. A complexidade é tamanha que criou um mercado para cursos e certificações que, na prática, atestam que você sabe navegar no painel de controle de um fornecedor específico. Pense nisso: precisamos de certificações para usar a infraestrutura que deveria, em tese, simplificar nossas vidas.

Antigamente, o conhecimento necessário para subir um sistema em PHP ou Perl em um servidor Apache era trivial e universal. Hoje, o conhecimento é específico do fornecedor e absurdamente complexo. O resultado? Os desenvolvedores gastam uma quantidade obscena de tempo que não estão, de fato, desenvolvendo. Estão configurando ambientes, debugando arquivos YAML, tentando entender por que o pod do Kubernetes não sobe ou por que uma permissão de IAM está bloqueando o acesso a um bucket S3.

Isso não é engenharia de software. É burocracia digital. É um desperdício de talento, tempo e dinheiro. Nós, como indústria, criamos um monstro de complexidade acidental que nos devora vivos, e ainda o chamamos de "boas práticas" ou "DevOps".

E se a solução for... menos? A aposta radical de DHH

Depois de diagnosticar a doença com um precisão, DHH não parou na crítica. Ele fez o que os verdadeiros engenheiros fazem: construiu uma alternativa. Em apenas dois meses, ele e sua equipe desenvolveram um sistema operacional próprio, baseado em Linux, chamado Omarchy.

Durante a palestra, ele instalou esse SO do zero em menos de cinco minutos. O sistema é projetado para ser uma plataforma otimizada e intuitiva para o que a maioria de nós realmente faz: rodar aplicações web. A proposta é radical: em vez de dar ao desenvolvedor um milhão de peças de Lego e um manual de 5 mil páginas (a abordagem da nuvem), Omarchy oferece uma plataforma coesa e otimizada, onde as melhores práticas já estão embutidas. O objetivo é permitir que testes e deploys voltem a ser questão de minutos, não de horas ou dias.

Essa abordagem não é nova para ele. É a mesma filosofia por trás do Ruby on Rails: "Convenção sobre Configuração". Em vez de forçar o desenvolvedor a tomar milhares de decisões triviais, o framework oferece um caminho padrão, um "trilho" que funciona bem para 80% dos casos, liberando o desenvolvedor para focar no que realmente importa: a lógica única de sua aplicação. Agora, ele está aplicando esse mesmo princípio à infraestrutura.

Isso, para mim, é a marca de um verdadeiro visionário. Ele não aceita o status quo. Ele o desafia, o desmonta para entender suas falhas e, se necessário, constrói algo do zero que seja fundamentalmente melhor. É a audácia de dizer "isso tudo está quebrado, e eu vou construir algo que funcione", que separa os seguidores dos líderes.

Muitos podem chamar essa abordagem de simplista ou ingênua. Dirão que ela não serve para a "escala do Google". E eles estão certos. Mas a verdade brutal é que a esmagadora maioria de nós não está e nunca estará construindo o próximo Google. Estamos construindo aplicações para empresas, para nichos de mercado, para comunidades. E para essa realidade, a arquitetura complexa e distribuída que virou padrão é um exagero custoso e ineficiente.

Recuperando a Sanidade

A palestra de DHH foi um chamado à razão. Um convite para darmos um passo para trás e olharmos criticamente para o monstro de complexidade que alimentamos nos últimos 15 anos. Passamos de uma era de simplicidade e autonomia para uma era de especialização fragmentada e dependência de fornecedores. Transformamos desenvolvedores de software, que deveriam estar criando valor, em especialistas de configuração de nuvem.

Não estou pregando um retorno ao FTP e ao código macarrônico. Estou defendendo um retorno aos primeiros princípios. Devemos nos perguntar a cada passo: essa ferramenta, essa camada de abstração, está realmente resolvendo um problema essencial, ou está apenas adicionando complexidade acidental? O custo (em tempo, dinheiro e carga cognitiva) compensa o benefício?

A nuvem é uma ferramenta poderosa. Contêineres são uma tecnologia fantástica. Mas eles são meios, não fins. A obsessão da indústria em adotar cada nova tecnologia como se fosse uma bala de prata nos levou a um ponto de saturação. Estamos mais lentos, mais caros e, arrisco dizer, muitas vezes produzindo software de menor qualidade, porque a maior parte da nossa energia mental é consumida pela infraestrutura, e não pelo produto.

O trabalho de DHH com Rails, e agora com projetos como o Omarchy, nos mostra que existe outro caminho. Um caminho de simplicidade, de produtividade, de foco no que realmente importa. Um caminho onde o poder computacional massivo que temos em nossas máquinas locais é aproveitado ao máximo. Um caminho onde o deploy volta a ser um evento trivial, não um ritual de sacrifício.

A nuvem é uma ferramenta, não uma religião. E talvez seja hora de pararmos de adorá-la e começarmos a usá-la de forma mais inteligente e pragmática. Ou, como DHH nos mostrou, talvez a solução mais poderosa seja simplesmente desligá-la e olhar para o poder que já reside em nosso próprio hardware.

A questão que deixo para você é: em seu projeto, em sua empresa, você está usando a ferramenta, ou a ferramenta está usando você?

Assista a aula completa: