Programar ficou mais fácil ou apenas trocamos dificuldades?

TL;DR

• No DOS, a dificuldade era o hardware: memória apertada, processamento limitado, ferramentas simples. Disciplina obrigatória.
• No Windows, a dificuldade virou instalação: eventos, DLLs, componentes, máquina do cliente que nunca se comportava igual à do dev.
• Na Web, a dificuldade explodiu em superfície: segurança, autenticação, integrações, nuvem, escala — e uma cadeia de pacotes de terceiros que ninguém controla.
• Hardware milhares de vezes mais rápido foi consumido por sistemas milhares de vezes mais pesados. O ganho líquido de simplicidade é menor do que parece.
• Escrever menos código não é administrar menos complexidade — na maioria das vezes é exatamente o contrário.

~ 8 min de leitura · 1342 palavras

A era do aperto: quando cada byte contava

O gargalo do desenvolvimento no DOS não era lógica de negócio — era física. O DOS dava 640 KB de memória convencional, e cada byte tinha dono. Eu lembro de passar semanas brigando com memória estendida, overlays, drivers de rede que consumiam os 20 KB que faltavam pra rotina de nota fiscal caber. A diferença entre o sistema rodar e travar na frente do cliente às vezes era uma variável global a mais ou um arquivo aberto de menos.

Isso criava uma disciplina que hoje soa quase exótica. Ninguém alocava memória sem saber onde ia liberar. Ninguém escrevia uma rotina sem pensar quantas vezes ela ia rodar no dia. O cliente que emitia 300 notas por dia não tolerava uma tela 10% mais lenta — e a gente não tinha a opção de mandar ele comprar um servidor maior. O computador era o que era.

A parte boa dessa era: o raio de acidentes era pequeno. O programa tinha controle do loop, do arquivo, da tela. Quando algo dava errado, o problema estava em código que eu tinha escrito, num ambiente que eu conhecia. Debugar era difícil, mas o universo de suspeitos era curto.

A parte que era pesada de verdade: tudo o que hoje vem pronto — interface, relatório, impressão fiscal — era feito à mão, linha por linha. A dificuldade daquela era era construir.

A era da instalação: a dificuldade saiu da lógica e entrou na máquina do cliente

O Windows mudou o inimigo. A lógica de negócio ficou — eu continuava resolvendo baixa de estoque, CFOP, crédito de cliente — mas em volta dela cresceu uma camada nova de problemas que não tinham nada a ver com o negócio do cliente: eventos, DLLs, componentes de terceiros, instalação.

Quem nunca viveu aquela era de “funciona na minha máquina” não sabe o custo disso. O sistema testado no meu desktop travava no computador do cliente por causa de uma versão de DLL registrada por outro aplicativo. Instalação de sistema comercial em Windows nos anos 2000 era parte engenharia, parte adivinhação: dependências, drivers de impressora fiscal, permissões de rede, Windows 98 vs 2000 vs XP. A mesma rotina de baixa de estoque que no DOS era um seek num arquivo .DBF agora tinha que lidar com lock de rede, concorrência entre 5 máquinas, e o usuário clicando em qualquer botão em qualquer ordem.

Foi ali que aprendi uma coisa que carrego até hoje: cada camada de abstração que facilita o desenvolvimento adiciona uma camada de ambiente que pode falhar. O código ficou mais fácil de escrever. O sistema ficou mais difícil de garantir. E essa equação nunca mais deixou de valer — só se intensificou.

A era da complexidade distribuída: quando o problema virou superfície

A Web levou essa equação pra um nível que eu não teria acreditado em 1996. Hoje, antes de uma tela de pedido funcionar, uma cadeia inteira precisa funcionar junto: autenticação com token, API em HTTPS, certificado válido, CDN, banco de dados, rede, navegador, e dezenas de pacotes npm ou NuGet que ninguém do meu time escreveu mas todos respondem por ele.

Problemas que eram impensáveis no DOS são hoje parte do dia a dia. Um pacote de terceiro publica um breaking change e o build quebra num commit que ninguém meu fez. Uma vulnerabilidade é descoberta numa biblioteca transitive — três níveis abaixo do que eu escolhi instalar — e o meu sistema em produção entra na lista de expostos. Um CDN fica fora do ar e o sistema do cliente “quebra” sem uma linha do meu código ter mudado. Já passei por as três situações. Nenhuma delas tem equivalente na era do aperto; lá, o pior cenário era o disco cheio.

Em compensação, dificuldades que dominávamos de cor simplesmente morreram. Ninguém mais configura memória estendida. Ninguém mais escreve driver de impressora matricial. Ninguém mais sofre com o usuário desligando o micro no meio da gravação sem janela de transação pra proteger. O que a era do aperto cobrava, ela cobrava de todo mundo, sempre. O que a era da Web cobra cobra de forma distribuída, imprevisível e em camadas que mudam sozinhas.

O paradoxo: hardware milhares de vezes mais rápido, sistemas milhares de vezes mais pesados

Aqui está o número que me incomoda. O computador médio de 2026 é ordens de magnitude mais rápido e maior que o 486 onde eu compilava Clipper. E em compensação o sistema médio consome, em uma aba de navegador, mais memória do que aquela máquina tinha inteira.

Para onde foi o ganho? Parte virou experiência — gráficos, responsividade, acessibilidade, coisas genuinamente melhores. Mas boa parte virou camadas de infraestrutura que existem para administrar a própria complexidade que a indústria criou: runtimes, frameworks, containers, orquestração, observabilidade. O hardware ficou poderoso e a complexidade consumiu o poder. Não é coincidência — é a mesma regra de sempre: o software cresce até preencher os recursos disponíveis. Law, não acidente.

Isso muda o jeito de avaliar ferramenta nova. A pergunta certa nunca foi “isso me faz escrever código mais rápido?”. A pergunta certa é: “quando isso falhar, quem diagnostica, e quanto tempo leva?”. Ferramenta que acelera o início e esconde o custo de operação é empréstimo, não ganho.

Escrever menos código, administrar mais complexidade

O argumento favorito da indústria é: “você não precisa mais escrever isso — use o framework, instale o pacote”. E é verdade. Eu uso e recomendo. O que o argumento omite é o troco: cada linha que deixo de escrever vira uma linha de terceiro que preciso administrar — versão, atualização, compatibilidade, licença, segurança, disponibilidade.

No DOS, meu universo de dependências cabia numa folha: o compilador, a BDE ou os RDDs, o driver de rede. Hoje, um projeto web médio carrega centenas de dependências transitivas. Eu não escolhi centenas de nada — elas vieram de carona nas que escolhi. Cada uma é um pedaço do meu sistema que um desconhecido pode mudar.

Isso não é um apelo pra voltar a escrever tudo à mão — seria insano, e eu mesmo não faria. É um apelo de contabilidade honesta: a complexidade não sumiu, ela migrou do código que você escreve para o grafo de código que você aprova. E grafo aprovado sem acompanhamento é dívida que vence sem aviso.

A dificuldade migrou de camada

Então, a resposta pra pergunta do título, com 30 anos dos três lados: não, programar não ficou mais fácil — a dificuldade mudou de lugar. Da memória da máquina para a cadeia de dependências. Da rotina para a superfície de ataque. Do código que escrevo para o sistema que opero. As ferramentas modernas são genuinamente melhores no que prometem: derrubaram a barreira de entrada a um nível que em 1996 seria fantasia. Mas a dificuldade de entregar software confiável em produção continua inteira — apenas se deslocou para onde a disciplina antiga não olhava.

É o que eu levo pra decisão de stack hoje: antes de adotar qualquer coisa que “facilita”, eu pergunto onde essa facilidade vai morar quando o sistema estiver em produção. Quem segura a dependência quando ela quebrar? Quem monitora a superfície nova? Quem entende a camada que o framework esconde? Facilidade de início com resposta “não sei” para essas três perguntas não é simplificação — é transferência de problema com juros, cobrada depois, quando o sistema já é meu.

Leitura relacionada

• Do DOS à Web: mudou tudo, menos o problema que o software precisa resolver — a mesma jornada de três eras, pelo ângulo das regras de negócio.
• O que um programador de 1995 estranharia em 2026 — a visão do outro lado da transição.
• Dívida técnica que IA generativa acelera em vez de resolver — quando a ferramenta que facilita o início piora o custo de operação.

—

*Roberto Brandini é desenvolvedor de software empresarial há 30 anos. Começou profissionalmente em Clipper/DOS em 1996, passou por Windows e Web, e é fundador da DP Sistemas e criador do Posseidom, ERP que atende varejo, atacado, distribuidoras e indústrias no Brasil. Este post faz parte da série “Tecnologia ontem versus hoje”.*