A Sabedoria Tediosa: Desconstruindo "Choose Boring Technology"

Muita gente olha pra filosofia "Choose Boring Technology" do Dan McKinley e acha que ele tá sendo contra o progresso ou até que é um apelo ao Ludismo, mas essa é uma interpretação bem equivocada. Na verdade, eu vejo isso como uma abordagem refinada para gerenciar riscos, otimizar nossos recursos e impulsionar o desempenho de uma organização no longo prazo. O segredo não é fugir do novo, mas escolher com consciência o que é previsível e estável. Afinal, quem não quer paz de espírito na hora de colocar um sistema em produção?

Definindo "Tedioso": Previsibilidade e Ignorância Produtiva

Para a gente entender essa filosofia, o primeiro passo é mudar o que a gente entende por "tedioso". No vocabulário do McKinley, "tedioso" não quer dizer que a ferramenta é ruim, desinteressante ou ultrapassada; quer dizer que ela é muito bem compreendida. Uma tecnologia tediosa é aquela que a gente conhece as capacidades e, o que é mais importante, sabe exatamente como ela quebra. PostgreSQL, Python, PHP e cron são "tediosos" não porque falta poder pra eles, mas porque o comportamento deles sob estresse e suas limitações já foram documentados e resolvidos por anos de uso real.

Isso bate certinho com o que o Kent Beck chama de "Ignorância Produtiva". Num cenário onde tudo muda o tempo todo, não adianta a gente fingir que sabe tudo, né? A ignorância produtiva é aceitar que a gente não domina certas coisas e decidir focar o aprendizado onde ele realmente faz a diferença. Quando a gente escolhe o "tedioso", a gente admite que não quer gastar neurônio aprendendo o último framework da moda se o que a gente já tem resolve o problema de negócio com maestria.

Eu acredito que a previsibilidade é o que salva a gente de surpresas desagradáveis na engenharia de software, que já é uma disciplina complexa por natureza. Tecnologias novas aumentam essa complexidade de um jeito perigoso, trazendo os "desconhecidos desconhecidos" - problemas que a gente nem imaginava que existiam, bem diferentes daqueles que a gente já sabe como planejar, tipo uma partição de rede.

Essas inovações estão cheias de imprevistos: a gente não sabe como elas vão se comportar quando o sistema crescer ou que tipo de erro bizarro podem causar. Já uma ferramenta considerada "tediosa" já transformou quase todos os seus mistérios em fatos conhecidos através do uso por milhares de pessoas. Se a gente tiver um problema, a solução provavelmente tá a uma pesquisa rápida de distância. Essa paz de espírito tira um peso enorme das costas do time e deixa a gente focar no que o cliente realmente precisa, em vez de ficar caçando bug em ferramenta que a gente nem entende direito.

A Economia do "Token de Inovação"

Para dar contexto à adoção de tecnologias novas, o McKinley traz uma metáfora que eu gosto muito: os "tokens de inovação". Ele diz que cada empresa tem um estoque bem limitado desses tokens - talvez só uns três. Eles representam nossa capacidade de fazer algo realmente criativo e arriscado. E como qualquer recurso escasso, a gente tem que gastar esses tokens com muita inteligência, como se fosse o capital financeiro da empresa.

Essa ideia transforma a escolha técnica numa decisão de estratégia pura. Gastar um token de inovação em algo básico, como trocar um banco de dados que o time já domina por um "moderno", é um risco altíssimo pra algo que não traz diferencial nenhum pro negócio. O cliente ganha alguma vantagem se o seu banco de dados é a última novidade? Provavelmente não. A vantagem vem do produto que a gente constrói em cima dele. Se a gente queima nossa inovação na infraestrutura, a gente fica sem "bala na agulha" pra inovar onde o cliente realmente percebe valor.

No fundo, liderar tecnologia é gerenciar riscos. Eu vejo que a função do líder é alocar esse orçamento de risco da melhor forma. Escolher o "tedioso" pro que é base é como investir em ativos estáveis pra garantir que o alicerce da empresa seja firme. Isso preserva nossos tokens de inovação praquelas apostas de alto risco e alta recompensa que vão realmente mudar o jogo no mercado.

Custo real da tecnologia: Sobrecarga cognitiva e operacional

A gente costuma escolher ferramentas achando que elas são as melhores pra aquele momento, mas acaba esquecendo do custo invisível. O McKinley sempre lembra que o preço de uma tecnologia vai muito além do desenvolvimento inicial. Tem o custo de manter tudo rodando e a carga mental que isso gera pra todo mundo.

Essa sobrecarga aparece na necessidade de criar novas estratégias de monitoramento, novos testes e treinamento pro time. Cada coisa nova que a gente coloca no stack fragmenta o conhecimento e a atenção de todo mundo. O caso da Etsy ilustra bem essa armadilha: contrataram gente que só sabia Python e acabou criando uma camada desnecessária no sistema que demorou anos pra ser eliminada. Foi uma otimização rápida que gerou uma dor de cabeça global e atrasou o sucesso da empresa.

Por outro lado, quando a gente se contém e usa o que já conhece, os benefícios aparecem no longo prazo. O pessoal da Etsy construiu o feed de atividades deles com o básico: PHP, MySQL e Memcached. Mesmo que a implementação inicial tenha sido trabalhosa, a solução escalou 20 vezes ao longo dos anos sem dar trabalho. A estabilidade do stack deixou os engenheiros livres pra focar no que era urgente. A lição pra mim é clara: o custo operacional de longo prazo quase sempre é mais importante que a conveniência de usar algo novo agora.

Entender e aplicar essa filosofia das "Tecnologias Tediosas" é o primeiro passo pra gente construir sistemas robustos e escaláveis. Mas eu sei que essa abordagem costuma enfrentar resistência quando a pressão por velocidade e inovação aperta. No próximo artigo, a gente vai ver como equilibrar essa aparente contradição entre ser estável e ser rápido no desenvolvimento de software.