"O software está ficando mais lento com mais rapidez do que o hardware fica mais rápido."
Desenvolvedores discutem se a “lei de Wirth” — a ideia de que o software fica mais lento mais rápido do que o hardware fica mais rápido — ainda se aplica, apontando apps web inchados, ferramentas baseadas em Electron, suítes pesadas de segurança e hops de rede de SaaS como evidência de que máquinas modernas muitas vezes não parecem mais ágeis do que as antigas. Muitos veem a causa raiz nos incentivos: empresas recompensam a entrega rápida de funcionalidades e o reaproveitamento multiplataforma em vez de profiling, eficiência algorítmica e testes em hardware de baixo desempenho, embora os usuários sofram rotineiramente com latência e clientes que consomem muitos recursos. Outros contrapõem que SSDs, CPUs multinúcleo e ferramentas melhores tornaram a computação cotidiana visivelmente mais rápida no geral, e que algumas stacks e bibliotecas modernas estão de fato se tornando mais eficientes.
Hardware do Desenvolvedor vs. Realidade do Usuário
- Muitos argumentam que os devs deveriam usar regularmente máquinas de baixo custo ou VMs limitadas às especificações do “5º percentil” para sentir a dor real do usuário e priorizar desempenho.
- Outros dizem que isso é contraproducente: as stacks modernas de desenvolvimento (IDE, Docker, bancos de dados, Node, etc.) já sobrecarregam máquinas boas; desacelerar o hardware só desperdiça tempo caro dos desenvolvedores.
- Compromisso sugerido: uma máquina de dev rápida, mas executar o produto em VMs/telefones limitados ou em máquinas de teste dedicadas de baixo desempenho.
Desempenho vs. Funcionalidades e Incentivos de Negócio
- Tema recorrente: as empresas, não os devs, definem as prioridades; funcionalidades e prazos quase sempre vencem o desempenho.
- Os usuários muitas vezes pedem novas capacidades em vez de velocidade, especialmente quando funcionalidades podem economizar dias enquanto ganhos de desempenho economizam horas.
- Alguns temem que isso reflita o paradoxo de Jevons: ganhos de eficiência acabam sendo gastos em mais funcionalidades e camadas, não em responsividade.
De Onde Vem a Lentidão
- Culpados frequentes mencionados: excesso de peso da web, apps Electron, frameworks demais, hops de SaaS/rede, queries N+1 no banco de dados, índices ausentes e arquiteturas excessivamente abstratas.
- Outros apontam que, no ambiente corporativo, “coisas customizadas” podem ser piores do que componentes prontos, bem escolhidos e eficientes.
- Ferramentas de segurança, telemetria e “corporate-ware” são descritas como grandes drenos de I/O e CPU.
A Lei de Wirth é Realmente Verdadeira?
- Alguns dizem que sim: apps do dia a dia, UIs e operações simples muitas vezes não parecem mais rápidas apesar dos ganhos de hardware de ordens de grandeza; exemplos de input lag e celulares lentos são citados.
- Outros contrapõem com relatos de máquinas modernas baratas parecendo muito mais rápidas do que PCs de meados dos anos 2000, especialmente com SSDs e redes melhores.
- Vários observam a falta de medições longitudinais rigorosas; a maior parte das evidências é anedótica.
Cultura de Otimização e Linguagens
- Alguns acham que “otimização é a raiz de todo mal” foi usado indevidamente para justificar nunca otimizar, e que muitas equipes nem sequer fazem profiling ou medição.
- Outros argumentam que a otimização ainda é valorizada onde importa (jogos, ferramentas de dados, bibliotecas orientadas a desempenho como ecossistemas Python mais rápidos), mas os casos de negócio costumam ser fracos.
- O thread destaca ganhos clássicos de desempenho: melhores queries de banco, índices, menos chamadas de rede e evitar camadas desnecessárias de abstração.
Direções Futuras e Ferramentas
- As pessoas sugerem ferramentas de limitação de rede/CPU, CI em hardware lento e conjuntos de dados realistas como formas práticas de manter o desempenho sob controle.
- As opiniões se dividem sobre se código gerado por IA vai piorar o inchaço (saída mais rápida do tipo “funciona, mas é lenta”) ou ajudar a otimizar, dependendo de como for usado.