A cerca de Chesterton
O que G. K. Chesterton, Benoit Mandelbrot e Nassim Taleb podem nos ensinar sobre tecnologia.
O período entre as duas Grandes Guerras foi marcado por importantes mudanças sociais, retroalimentadas por desastres econômicos como a Grande Depressão de 1929. Nessa época, muito se falou de política, progresso, tecnologia. Muitos eram os reformadores – tudo parecia errado.
Um homem, porém, ousou questionar o ritmo das mudanças. Ele não era contra o progresso, mas pregava humildade frente ao impacto do desconhecido, e defendia uma filosofia arraigada nos princípios básicos e universais que deveriam servir de alicerces para a nova sociedade que se desenhava. Esse homem era Gilbert K. Chesterton.
Mas o que esse simpático inglês, grande em altura e em largura, autor prolífico que analisou a sociedade de seu tempo, tem a ver com tecnologia, inteligência artificial, e todas as mudanças paradigmáticas que programadores e engenheiros de software tem sido submetidos, quase que forçosamente, nos últimos anos? Hoje eu gostaria de explorar o conceito da Cerca de Chesteron.
There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.” – G. K. Chesterton, The Thing (1929).
Embora Chesterton escrevesse apontando para os reformistas de sua época, o princípio aludido é sólido e aplicável a diversas outras áreas da vida, como na programação. De forma concisa1, a Cerca de Chesterton pode ser entendida como:
Do not remove a fence until you know why it was put up in the first place.
Em outras palavras, devemos assumir que qualquer norma, tradição, mecanismo ou código existem por uma razão, e a falha em perceber sua utilidade não necessariamente significa que não há valor em conservá-lo. Pelo contrário, é prudente que qualquer mudança seja feita somente conhecendo detalhadamente seu funcionamento e origem, de modo que as consequências da alteração possam ser ponderadas antes de sua implementação.
É necessário evitar o cinismo de dizer "ora, então quer dizer que nunca devemos mudar nada e permanecer sempre como está?". Não é isso que o princípio de Chesterton prega, como explicado acima, mas existem algumas heurísticas que ajudam nesse entendimento. Umas delas é o chamado Efeito Lindy.
Esse termo, matematicamente concebido por Benoit Mandelbrot e culturalmente popularizado por Nassim Taleb em livros como Antifragile e Skin in the Game, propõe que:
The future life expectancy of non-perishable things (like ideas, books, technologies) is proportional to their current age. In other words, the longer something has survived, the longer it's likely to survive.
Se combinarmos a ideia do Efeito Lindy com a Cerca de Chesterton, podemos concluir que quanto mais antiga for a cerca, maior é a probabilidade de que ela esteja ali por uma razão, e portanto por mais tempo espera-se (matematicamente falando) que ela ali permaneça. Mandelbrot definiu probabilisticamente o que Chesterton percebeu filosoficamente.
Mas por que esse texto está na Code Capital e não na minha newsletter Ensaios? Pois eu acredito que as proposições acima se aplicam perfeitamente ao nosso objeto de estudo, a tecnologia.
É extremamente tentador refatorar um projeto para utilizar o framework da moda, que sempre anunciará dezenas de melhorias: agora ele é blazing fast, mais fácil, tem um menor startup time, ou talvez um menor build time. Foi reescrito em Rust ou Go. Utiliza paradigmas mais modernos. Foi comprado pela Meta, ou open-sourced pela Microsoft. Muitas são as razões que convidam-nos a mudar.
No entanto, você entende por quê mudar? É capaz de analisar os impactos negativos da mudança (não somente os positivos)? Talvez o seu framework atual faça algo melhor que o novo que você ainda não se deu conta.
Quando fui chamado para iniciar um projeto do zero numa startup americana em 2019, a tecnologia escolhida foi o Gatsby, que na época era compatível em tamanho com o Next.js. A razão por trás era que o app precisava ser muito forte em SEO, e escalar para dezenas ou centenas de milhares de páginas estáticas, algo que o Gatsby se propunha a fazer.
Quatro anos depois, o projeto havia evoluído e o número de páginas estáticas já não era tão grande assim. Ademais, o Gatsby estava praticamente morto, derrotado em números e hype pelo Next.js, que preparava uma mudança significativa para um novo paradigma, o app router. Unindo todos esses motivos, decidimos por uma lenta e penosa migração. Embora o processo tenha valido a pena, esbarramos em diversos contratempos que eram resolvidos pelo Gatsby mas precisaram ser laboriosamente corrigidos no framework novo.
E assim até hoje se faz no mundo da programação. Sistemas críticos, como os que vemos em setores bancários e de aviação, são mantidos em tecnologias ditas ultrapassadas, mas que personificam o Efeito Lindy e fariam Chesterton gargalhar alegremente: você arriscaria refatorar um módulo em COBOL que roda as mesmas funções por 60 anos? Eu tenho uma definição diferente de viver perigosamente...
Quando falamos de tecnologia, existem centenas de formas de se abordar um determinado problema. Embora possamos objetivamente argumentar que um código roda mais rápido que outro, ou que um framework se expõe a mais vetores de ataque do que a alternativa, é praticamente impossível cravar qual forma de execução é melhor, uma vez que isso também depende da familiaridade do programador com a ferramenta em questão.
Essa é, inclusive, uma das grandes vantagens da IA: aproximar a tecnologia do programador, reduzindo a interface entre eles, de modo que com linguagem natural e raciocínio humano possamos escolher the best tool for the job – cientes de que "a melhor ferramenta" é também uma função do seu operador.
O mundo da tecnologia forçará novidades a torto e a direito em você. Mas cabe a nós decidirmos, com a humildade que pregava Chesterton, se é vantajoso adotarmos a mudança. Muitas vezes, essa constante busca pela ferramenta mais quente do mercado é contraproducente e afasta-nos do objetivo principal: resolver problemas do mundo real, criar uma empresa, vender produtos, ganhar dinheiro, etc.
Pieter Levels, um dos programadores mais famosos da atualidade, empreendedor e indie hacker, que gera mais de $500k por mês com todos seus apps somados, admitiu que seu stack padrão é... PHP + jQuery! Qualquer um trabalhando com desenvolvimento web hoje provavelmente achará isso chocante. Esse foi o stack que aprendi a programar, em 2012, quando entrei nesse mundo. Mas o Efeito Lindy é implacável: quanto mais tempo uma tecnologia vive, mais ela é esperada viver, e Pieter é a prova viva de que você consegue se manter mais produtivo se evitar ceder aos impulsos de consumir o que a indústria tech tenta te empurrar.
Mas isso não significa que Pieter ignora os avanços da tecnologia. Ele também se tornou famoso por aderir ao vibe coding e lançar jogos em Three.js (mesmo sem ter experiência na área), e tem sido um grande proponente de ferramentas como Cursor e Claude Code. Não se interessou em aprender sobre o React state2, mas não se furtou em acelerar seus projetos com inteligência artificial. Pieter sabe que tecnologia é um meio, não um fim.
Sejamos responsáveis ao adotar nossas tecnologias, mas implacáveis em aumentar nossa produtividade. Ponderemos os riscos de adotar o que é mutável por natureza. Como Newton, construímos sobre o ombro de gigantes. Reconheçamos, pois, o valor daqueles que já serviram de escada para muitos antes de nós.
Tanto o termo Chesterton's Fence quanto sua definição simplificada foram tomadas do excelente artigo Chesterton’s Fence: A Lesson in Thinking (https://fs.blog/chestertons-fence).