Forem: Rodrigo de Avila

A Liberdade da Contenção Deliberada

Rodrigo de Avila — Sat, 18 Oct 2025 12:57:09 +0000

A verdadeira liberdade e agilidade em engenharia não vêm da busca incessante por novas ferramentas, mas sim do domínio profundo de um conjunto tecnológico estável e deliberadamente limitado. A estratégia de "escolher tecnologia tediosa" não freia o progresso; pelo contrário, atua como um método sofisticado para acelerá-lo. Ao adotar soluções que minimizam a carga cognitiva e os atritos operacionais, as organizações permitem que suas equipes atinjam ciclos de iteração rápidos e sustentáveis, em total conformidade com a Lei de Boyd.

O modelo do GitLab é uma prova concreta e irrefutável de que essa abordagem é não apenas teórica, mas uma estratégia comprovada para desenvolver e escalar um produto de software complexo com notável rapidez. A disciplina do GitLab em otimizar o que já existe e em resistir à complexidade desnecessária é o pilar de sua agilidade.

Com o avanço da Inteligência Artificial, a relevância desses princípios apenas se intensificou. A capacidade da IA de gerar código aparentemente funcional, mas fundamentalmente falho, para tecnologias desconhecidas, transformou a falta de experiência de um risco em uma verdadeira responsabilidade. Nesse novo cenário, o conhecimento aprofundado de um stack "tedioso" adquire um valor sem precedentes, tornando-se um pré-requisito para utilizar a IA de forma segura e eficaz, potencializando suas capacidades.

Em sua essência, a Estratégia da Estabilidade é profundamente humanocêntrica. Ela reconhece que o recurso mais valioso e finito de uma empresa não é o código ou a infraestrutura, mas a energia criativa, o foco e o bem-estar da equipe de engenharia. O fundamento psicológico da "Ignorância Produtiva" permite que os engenheiros aceitem as restrições tecnológicas, liberando seu potencial humano para resolver os desafios que realmente importam para o negócio e seus clientes.

As empresas mais inovadoras frequentemente são as mais "tediosas" em sua base, pois construíram uma plataforma estável que lhes permite avançar com segurança e rapidez para o futuro.

Obrigado por chegar até aqui! Esta é a minha primeira série de artigos, onde tento "despejar" um pouco dos meus pensamentos e de como os artigos que leio por aí ajudaram a moldar minhas crenças. Espero que tenha sido útil pra você.

Estrutura estratégica para decisões tecnológicas

Rodrigo de Avila — Sat, 18 Oct 2025 12:56:13 +0000

Para os líderes de tecnologia, a síntese entre as filosofias de tecnologia tediosa, iteração rápida e as realidades da era da IA exige mais do que uma compreensão superficial; é preciso uma estrutura prática. Esta seção tem como objetivo traduzir essa filosofia em políticas concretas, oferecendo um modelo para fomentar uma cultura de engenharia eficaz, gerenciar a adoção de novas
tecnologias e tomar decisões estratégicas de forma sistemática.

Cultura de Engenharia Eficaz

A cultura é o alicerce de qualquer estratégia tecnológica bem-sucedida. A liderança deve promover ativamente a estabilidade e a velocidade, redefinindo a métrica do sucesso. Em vez de focar apenas na adoção de novas tecnologias, os líderes devem valorizar as equipes que entregam valor de negócio de forma consistente e confiável. Isso inclui reconhecer e recompensar a manutenção de sistemas estáveis, a refatoração que simplifica a complexidade e a escolha pragmática de soluções "tediosas" que aceleram a entrega.

A comunicação é vital. Os líderes precisam explicar o "porquê" dessas decisões, conectando diretamente a tecnologia menos glamorosa à redução do estresse operacional (menos chamadas de madrugada), ao aumento da velocidade da equipe (ciclos OODA mais rápidos) e à capacidade de priorizar a inovação do produto.

Base Psicológica: Ignorância Produtiva

Para que uma estratégia seja eficaz, é fundamental que ela se baseie em um sólido alicerce psicológico na cultura da equipe, um conceito que Kent Beck denomina "Ignorância Produtiva". Isso implica cultivar um ambiente onde os engenheiros se sintam seguros para admitir suas lacunas de conhecimento e onde a aprendizagem direcionada seja mais valorizada do que a busca incessante por novidades tecnológicas.

A promoção da ignorância produtiva se manifesta através de:

Celebração da Maestria: Reconhecer publicamente a expertise de especialistas em tecnologias já estabelecidas e o valor inestimável que eles agregam.
Normalização da Incerteza: Incentivar questionamentos e a transparência da liderança ao admitir quando não possui todas as respostas sobre novas tecnologias.
Foco no Aprendizado Direcionado: Alocar tempo e recursos para que as equipes aprofundem seus conhecimentos em ferramentas estrategicamente importantes, em vez de permitir uma exploração tecnológica sem rumo.

Essa mentalidade é o pilar humano que sustenta o funcionamento da estrutura de governança. Sem ela, qualquer processo formal seria percebido como uma barreira burocrática, em vez de uma ferramenta estratégica essencial para o sucesso.

Um Processo de Governança para Novas Tecnologias

Para evitar um crescimento desordenado de tecnologias, as organizações devem implementar um processo formal para a avaliação e adoção de novas soluções. Este processo, inspirado nas recomendações de McKinley, deve funcionar como um filtro cuidadoso, e não como uma barreira burocrática. Os passos incluem:

Definição Clara do Problema: Antes de propor uma nova tecnologia, a equipe deve justificar por escrito por que a pilha tecnológica existente é inviável ou muito custosa para resolver o problema. Se o "problema" for apenas o desejo de usar uma tecnologia nova, a proposta deve ser rejeitada.
Implementação de Baixo Risco: Se a nova tecnologia for aprovada na etapa inicial, ela deve ser testada em uma área de negócio não crítica e de baixo risco. Isso permite que a equipe adquira experiência prática em produção e comprove o valor da tecnologia antes de uma adoção mais ampla.
Compromisso de Substituição: Caso a nova tecnologia seja redundante em relação a uma ferramenta já existente, sua adoção deve ser acompanhada de um plano e cronograma claros para migrar a funcionalidade da ferramenta antiga e, posteriormente, desativá-la. Isso evita a proliferação de soluções ótimas localmente que aumentam a complexidade geral.

Diretrizes para a Era da IA

O processo de governança para a era da IA precisa ser aprimorado com diretrizes específicas, conforme proposto por Brethorst. Estas regras servem como um importante controle de qualidade:

Capacidade de Revisão: Antes de adotar uma nova tecnologia, questione: "Nossa equipe conseguiria revisar adequadamente o código de implementação gerado por IA para esta tecnologia?" Se a resposta for negativa, evite utilizá-la em projetos de missão crítica.
Compreensão Aprofundada: Se a equipe optar por usar um "token de inovação" para aprender uma nova tecnologia, ela deve se comprometer a investir tempo real para compreendê-la profundamente. Isso é essencial para verificar a exatidão das sugestões da IA, pois a simples ação de copiar e colar é inaceitável.
Evitar Adoção Simultânea: Não utilize as ferramentas de IA como justificativa para adotar múltiplas tecnologias novas (como uma nova linguagem, framework e infraestrutura) ao mesmo tempo. Isso compromete a capacidade de verificação adequada e multiplica os riscos.

Matriz de Decisão de Adoção de Tecnologia

Para colocar esses conceitos em prática, os líderes podem empregar uma ferramenta visual que auxilia na formulação e comunicação das decisões tecnológicas. A Matriz de Decisão de Adoção de Tecnologia posiciona as escolhas tecnológicas com base em duas dimensões cruciais: a relevância estratégica para o negócio e o nível de maturidade da tecnologia.

	Tecnologia Nova	Tecnologia "Tediosa"
Importância Estratégica Alta	Aposta Estratégica: O Token de Inovação Este é o momento de investir estrategicamente um "token de inovação", direcionado a tecnologias com potencial de gerar uma vantagem competitiva crucial. Tal abordagem exige pesquisa aprofundada, prototipagem cuidadosa e uma gestão eficaz dos riscos envolvidos.	O Core Tecnológico Este é o seu stack tecnológico fundamental, bem dominado, para o desenvolvimento de funcionalidades essenciais. Ele deve ser otimizado para o seu domínio específico, garantindo agilidade e confiabilidade. Nesse contexto, a inteligência artificial serve como um potente multiplicador de força.
Importância Estratégica Baixa	A Zona de Perigo de McKinley: Alto Risco, Baixa Recompensa Esta é a área a ser evitada a todo custo. Engenheiros que adicionam novas tecnologias "por diversão" acabam criando uma dívida operacional massiva, transformando um alto risco em uma baixa recompensa.	O Cinto de Utilidades: A Escolha Inteligente para Soluções Não Críticas Esta é a opção ideal para funções de suporte que não são críticas. Priorize ferramentas já existentes e testadas, garantindo eficiência com o mínimo de complexidade. É a solução perfeita para tarefas rápidas e diretas.

Essa matriz orienta os líderes a fazer as perguntas essenciais antes de aprovar uma nova tecnologia: "Isso é um diferencial fundamental para o nosso negócio?" e "Qual é o perfil de risco dessa tecnologia?". Dessa forma, uma filosofia abstrata se transforma em um processo repetível e defensável, alinhando as decisões tecnológicas aos objetivos estratégicos da empresa.

Esta estrutura estratégica estabelece as bases para uma abordagem deliberada e sistemática às decisões tecnológicas. No último artigo desta série, exploraremos como todos esses conceitos se unem no princípio da Contenção Deliberada, oferecendo um modelo prático para equilibrar inovação e estabilidade no desenvolvimento de software moderno.

"Tecnologia Tediosa" Revisitada na Era da Inteligência Artificial

Rodrigo de Avila — Sat, 18 Oct 2025 12:55:07 +0000

A filosofia da tecnologia tediosa, criada antes da era da IA, ganha uma nova e ainda mais crucial relevância com o surgimento dos assistentes de codificação baseados em Inteligência Artificial. Aaron Brethorst, em "Choose Boring Technology, Revisited", argumenta que, embora os princípios fundamentais de McKinley continuem válidos, ferramentas como Copilot e Claude adicionam uma dimensão nova e perigosa à equação. A IA não anula a necessidade da tecnologia tediosa; pelo contrário, acentua os riscos de ignorá-la.

Assistentes de Codificação de IA: O Novo Obstáculo

A mudança mais significativa na indústria, desde o ensaio original de McKinley, é a proliferação de assistentes de codificação baseados em Modelos de Linguagem Grandes (LLMs). Embora essas ferramentas sejam extraordinariamente proficientes em gerar código plausível e profissional para uma vasta gama de tecnologias, incluindo implementações complexas como microsserviços com Kubernetes ou federação GraphQL, essa capacidade introduz um novo perigo: gerar código para uma tecnologia com a qual não está familiarizado.

O problema reside no fato de que os LLMs podem "alucinar" detalhes técnicos, produzindo código que, à primeira vista, parece correto, mas é fundamentalmente defeituoso de maneiras sutis. Brethorst relata ter observado engenheiros aceitando código gerado por IA que continha APIs obsoletas, antipadrões de segurança ou problemas de desempenho que só se manifestariam sob carga de produção. A natureza enganosa desse código é que ele "parecia certo" — seguia as convenções de nomenclatura, incluía tratamento de erros adequado e parecia profissional. Apenas alguém com um conhecimento profundo da tecnologia subjacente seria capaz de detectar as falhas.

"Efeito Multiplicador de Desconhecidos"

A combinação de uma tecnologia desconhecida com código gerado por IA cria um cenário de incerteza exponencial. O engenheiro se vê em uma situação precária onde:

Não consegue determinar se a framework escolhida é adequada para o problema.
Não tem certeza se a implementação da IA segue as melhores práticas.
Não consegue distinguir entre o código boilerplate e a lógica de negócio essencial gerada pela IA.
Desconhece quais modos de falha precisa antecipar.

Brethorst compara essa situação a um "cargo-culting vezes 2.356", destacando o risco significativamente amplificado. O engenheiro deposita confiança cega em dois sistemas que não compreende: a nova tecnologia e o LLM. A confiança enganosa que o código de IA, com sua aparência profissional, proporciona, mascara uma profunda falta de entendimento, transformando a depuração futura em um verdadeiro pesadelo.

IA: "Multiplicador de Força"

A utilização de um assistente de IA em conjunto com uma tecnologia que o engenheiro domina — uma parte "tediosa" e familiar do seu stack — transforma a IA de um risco em um "multiplicador de força" potente. É aqui que a "Ignorância Produtiva" se manifesta com maior eficácia: o engenheiro aceita a IA para gerar a sintaxe exata de código repetitivo, confiando no seu conhecimento aprofundado para auditar o resultado.

Brethorst exemplifica esta ideia: ele confia no Claude para gerar código Rails devido à sua familiaridade com a framework, o que lhe permite identificar rapidamente sugestões problemáticas. Da mesma forma, usa o Copilot para JavaScript, pois compreende as nuances da linguagem e pode verificar a exatidão do que é gerado. Neste cenário, a IA assume o trabalho pesado do código
boilerplate, libertando o engenheiro para se concentrar na arquitetura e na lógica de negócio. A experiência do engenheiro serve como uma salvaguarda essencial, permitindo-lhe usufruir da produtividade da IA enquanto minimiza os riscos.

Esta dualidade revela uma nova realidade na era da IA: aumentou a importância da experiência profunda em um stack tecnológico. A IA alterou a natureza do risco no desenvolvimento. Antes da IA, um engenheiro a trabalhar com uma framework desconhecida provavelmente produziria código visivelmente confuso ou não funcional. Agora, as ferramentas de IA podem gerar código sintaticamente correto e bem formatado que, no entanto, esconde falhas sutis.

Assim, a competência crucial desloca-se da simples escrita de código para a capacidade de auditoria, exigindo um conhecimento profundo do domínio. A aptidão de analisar um bloco de código gerado por IA e identificar "Isto parece correto, mas está errado devido a X, Y e Z" tornou-se a nova habilidade de alto valor. Esta capacidade de auditoria só pode ser desenvolvida através de experiência prática e profunda com um stack tecnológico — a essência de dominar uma tecnologia "tediosa".

As decisões tecnológicas em uma era dominada pela IA requerem ainda mais cautela e deliberação. No próximo artigo, exploraremos como avaliar e selecionar tecnologias de forma sistemática, considerando não apenas suas capacidades técnicas, mas também seu impacto a longo prazo na manutenibilidade e segurança do sistema.

A Filosofia na Prática: O Modelo GitLab de Iteração Acelerada

Rodrigo de Avila — Sat, 18 Oct 2025 12:54:01 +0000

A teoria que associa a estabilidade da tecnologia tediosa à rapidez da iteração é persuasiva. No entanto, o seu verdadeiro valor reside na aplicação prática, e o GitLab é um exemplo concreto de como essa filosofia pode ser implementada em larga escala para gerar resultados notáveis. A empresa atribui explicitamente a sua capacidade de realizar 106 lançamentos em 106 meses consecutivos ao seu compromisso com "soluções tediosas".

A Complexidade limita a Velocidade

A filosofia do GitLab baseia-se num princípio fundamental: a velocidade da inovação é diretamente limitada pela complexidade total que se acumula. Cada nova tecnologia, abstração ou dependência adiciona uma sobrecarga incremental que, com o tempo, retarda toda a organização. Ao resistir ativamente a essa acumulação de complexidade e ao optar consistentemente pela solução mais simples e "tediosa", o GitLab conseguiu manter uma alta velocidade de iteração ao longo de uma década de crescimento.

Essa abordagem reflete-se em uma série de decisões pragmáticas, muitas vezes contraintuitivas, que priorizam a velocidade de entrega em detrimento da elegância técnica.

Exemplos práticos de "tedioso"

A cultura do GitLab de escolher soluções "tediosas" é melhor compreendida através de exemplos que demonstram uma preferência consistente por alavancar o que já existe, em vez de construir algo novo:

Aproveitar Funcionalidades Existentes: Para implementar quadros de issues (uma funcionalidade complexa) inicialmente, a equipe optou por usar a funcionalidade de etiquetas de issues já existente para alimentar as listas. Essa "solução tediosa" permitiu a entrega rápida de uma nova funcionalidade, reutilizando componentes já compreendidos e mantidos.
Evitar Interfaces de Usuário (UI) Desnecessárias: Diante da necessidade de autenticar com o Vault, em vez de desenvolver uma nova UI ou CLI, a equipe escolheu usar um JSON Web Token e documentar o uso de curl com os endpoints da API. Essa solução "sem código" resolveu o problema do usuário com zero sobrecarga de desenvolvimento e manutenção.
A Ferramenta Mais Simples Possível: Um exemplo marcante do compromisso do GitLab com a simplicidade foi a migração massiva e crítica do Microsoft Azure para o Google Cloud Platform (GCP). Para gerenciar esse projeto complexo, eles utilizaram a solução mais "tediosa" de todas: uma checklist em uma issue do GitLab. Embora essa checklist tenha sofrido 140 alterações, o processo simples e transparente permitiu que a migração fosse executada sem problemas sérios. Eles resistiram à tentação de usar software de gerenciamento de projetos sofisticado, confiando em uma ferramenta simples, visível e familiar para todos.
Incrementalismo Disciplinado: Ao melhorar a experiência do usuário para tornar o título de uma issue visível ao rolar a página, a proposta inicial era fixar apenas o título. No entanto, uma validação rápida mostrou que o MVP (Produto Mínimo Viável) deveria incluir também o estado da issue. Crucialmente, a equipe resistiu à tentação de expandir o escopo para incluir outros elementos fixos, como a navegação por abas, ou aplicar a lógica a outros objetos, como Merge Requests. Eles entregaram a menor alteração possível que agregava valor, demonstrando uma abordagem disciplinada à iteração.

"Tedioso" não é Dogma, é Estratégia

A abordagem do GitLab demonstra que a escolha de soluções "tediosas" não é permanente, mas estratégica e contextual. Inicialmente, ferramentas como o Gitolite foram adotadas por serem eficazes e permitirem foco na entrega de valor, sendo substituídas à medida que a empresa cresceu.

Isso ressalta que "tedioso" não é um julgamento de valor, mas uma escolha para a ferramenta mais simples e com menor sobrecarga, otimizada para a velocidade de iteração e com a flexibilidade de revisão futura.

Essa filosofia de soluções simples e iteração rápida é uma estratégia de engenharia humanizada. Ela valoriza a atenção, o foco e a energia criativa dos engenheiros, minimizando a fadiga cognitiva causada por stacks complexos. A metáfora da fadiga do piloto do MiG-15 ilustra o esgotamento mental ao lidar com tecnologias imprevisíveis, destacando a importância de um ambiente estável.

Um stack tecnológico "tedioso" e estável promove domínio e confiança, permitindo que os engenheiros entrem em estado de fluxo. Ao reduzir a carga cognitiva e a fadiga de decisão, os engenheiros podem direcionar sua criatividade para resolver problemas de clientes e gerar valor de negócio, focando no "o quê" em vez de se preocuparem constantemente com o "como" da infraestrutura.

Agora que entendemos como a escolha por soluções tediosas pode acelerar a iteração e a entrega de valor, vamos explorar um fenômeno que parece estar movendo a indústria na direção oposta: a IA. Como essas novas tecnologias se encaixam em uma filosofia que prioriza estabilidade e simplicidade?

O Imperativo da Velocidade: A Lei de Boyd e o Ciclo OODA no Software

Rodrigo de Avila — Sat, 18 Oct 2025 12:53:05 +0000

A base para a estabilidade no desenvolvimento de software reside na filosofia da "tecnologia tediosa". Contudo, o imperativo da velocidade é impulsionado pela "Lei da Iteração de Boyd". Originalmente aplicada à análise de combate aéreo militar, esta lei revela que a velocidade do ciclo de aprendizagem é mais crucial do que a qualidade de uma decisão individual. Ao combinar a estabilidade proporcionada pela tecnologia tediosa com a agilidade da Lei de Boyd, cria-se uma sinergia poderosa, resultando em um desenvolvimento de software sustentável e de alta velocidade.

O Ciclo OODA: Vantagem do Ritmo

A lei formulada pelo Coronel da Força Aérea dos EUA, John Boyd, surgiu após a análise dos combates aéreos na Guerra da Coreia. Boyd notou um paradoxo: embora o caça a jato americano F-86 fosse tecnicamente inferior ao MiG-15 soviético em quase todos os indicadores de desempenho, como taxa de subida e raio de viragem, os pilotos de F-86 venciam seus adversários em uma proporção de nove para um.

A conclusão de Boyd foi que o fator determinante para a vitória não era a superioridade em observar, orientar, decidir ou agir, mas sim a capacidade de executar este ciclo — denominado ciclo OODA (Observar, Orientar, Decidir, Agir) — mais rapidamente que o oponente. O piloto que conseguisse completar seu ciclo OODA de forma mais ágil conseguia interferir no processo de tomada de decisão do adversário, gerando confusão e desorientação, e assim, obtendo a vantagem.

A razão pela qual o F-86 conseguia iterar mais rapidamente era surpreendentemente simples: seus controles de voo eram totalmente hidráulicos,enquanto os do MiG-15 eram manuais e demandavam maior força física para operar. A cada manobra, o piloto do MiG-15 ficava um pouco mais fatigado, retardando marginalmente seu ciclo OODA. Ao longo de um combate aéreo, essa pequena desvantagem de atrito acumulava-se, permitindo ao piloto do F-86, menos fatigado, ditar o ritmo do confronto. Essa analogia é profundamente relevante para o desenvolvimento de software: o atrito, seja ele cognitivo ou processual, é um obstáculo à velocidade.

A Lei de Boyd no Desenvolvimento de Software

No desenvolvimento de software, a rapidez na iteração é mais crucial do que a qualidade individual de cada iteração. A capacidade de testar hipóteses, obter feedback, aprender e adaptar-se rapidamente é mais valiosa do que buscar a solução perfeita desde o início. Conforme demonstrado por Jeff Atwood, o ciclo OODA (Observar, Orientar, Decidir, Agir) é aplicado a práticas de desenvolvimento modernas, todas focadas em acelerar o ciclo de feedback:

Testes Unitários Rápidos: Testes devem ser concisos e executados em segundos. Testes demorados levam os desenvolvedores a executá-los com menor frequência, atrasando o feedback sobre a qualidade do código.
Testes de Usabilidade Ágeis: A realização de pequenas alterações e testes regulares com usuários permite que as equipes identifiquem rapidamente o que não funciona, evitando o investimento prolongado em direções equivocadas.
Metodologias Ágeis: A maioria das abordagens ágeis sugere iterações (sprints) de no máximo quatro semanas. Isso garante a entrega contínua de valor e a reorientação com base no feedback recebido.
Falhar Cedo, Falhar Frequentemente: O propósito dos testes de software não é comprovar sua funcionalidade, mas sim identificar falhas o mais cedo possível no ciclo de desenvolvimento, quando são mais baratas de corrigir.

Em todos esses cenários, o princípio subjacente é o mesmo: encurtar o ciclo OODA. O objetivo é aumentar o número de iterações em um determinado período, acelerando assim a aprendizagem e a adaptação organizacional.

Estabilidade e Velocidade: Uma Relação Simbiótica

A filosofia de "escolher tecnologia tediosa" e a "lei da iteração" de Boyd, embora distintas, são interdependentes e se fortalecem mutuamente. A estabilidade e previsibilidade de tecnologias "tediosas" são cruciais para acelerar o ciclo OODA de uma equipe de desenvolvimento, minimizando atritos.

A analogia do F-86 ilustra isso: sua vantagem não veio de uma tecnologia revolucionária, mas de uma que reduzia a fadiga do piloto, ou seja, o atrito. No desenvolvimento de software, tecnologias novas e não comprovadas geram atrito e fadiga cognitiva. Engenheiros gastam tempo e energia desnecessários ao lidar com stacks desconhecidos. A "Ignorância Produtiva" — admitir não conhecer uma nova ferramenta e preferir uma já dominada — reduz esse atrito, permitindo que a equipe itere mais rapidamente na resolução de problemas reais.

Em um stack desconhecido, o ciclo OODA (Observar, Orientar, Decidir, Agir) é impactado negativamente:

Observar: Dificuldade em identificar a causa de um bug ou quais métricas monitorar.
Orientar: Desafios para entender o contexto de um sistema complexo e desconhecido, dificultando o raciocínio sobre causas e efeitos.
Decidir: Planejar uma correção torna-se arriscado devido à incerteza das implicações, levando à paralisia da análise ou soluções excessivamente cautelosas.
Agir: A implementação da correção é lenta e propensa a erros, com ciclos de depuração prolongados devido a falhas inesperadas.

Por outro lado, um stack tecnológico "tedioso" e bem compreendido minimiza o atrito em todas as etapas do ciclo OODA. A equipe sabe onde procurar bugs (Observar), entende o sistema e suas interdependências (Orientar), pode prever com confiança o impacto de mudanças (Decidir) e implementar correções de forma rápida e segura (Agir).

Ao reduzir a sobrecarga operacional e cognitiva, a tecnologia tediosa atua como os controles de voo hidráulicos do F-86. Ela libera a energia da equipe para que se concentrem na execução eficiente do trabalho, em vez de lutarem contra suas próprias ferramentas. A estabilidade não se opõe à velocidade; ela é o fundamento sobre o qual a velocidade sustentável é construída.

No próximo artigo, vamos explorar como implementar ciclos OODA mais rápidos através de práticas específicas de desenvolvimento, demonstrando como acelerar iterações sem comprometer a estabilidade do sistema.

A Sabedoria Tediosa: Desconstruindo "Choose Boring Technology"

Rodrigo de Avila — Sat, 18 Oct 2025 12:51:51 +0000

A filosofia "Choose Boring Technology" de Dan McKinley é frequentemente vista como um repúdio ao avanço ou um apelo ao Ludismo, mas essa é uma interpretação equivocada. Na verdade, ela representa uma abordagem refinada para gerenciar riscos, otimizar a alocação de recursos e impulsionar o desempenho organizacional a longo prazo. Seu verdadeiro valor não está em rejeitar o novo, mas em escolher conscientemente o que é previsível e estável.

Definindo "Tedioso": Previsibilidade e Ignorância Produtiva

Para entender essa filosofia, o primeiro passo é redefinir "tedioso". No vocabulário de McKinley, "tedioso" não significa "ruim", "desinteressante" ou "ultrapassado"; significa "bem compreendido". Uma tecnologia tediosa é aquela cujas capacidades e, mais importante, seus modos de falha, são conhecidos pela equipe e pela indústria. Tecnologias como PostgreSQL, Python, PHP e cron são "tediosas" não por falta de poder, mas porque seu comportamento sob estresse, suas limitações e suas peculiaridades operacionais foram documentados, discutidos e resolvidos ao longo de anos ou décadas de uso em produção.

Isso se alinha diretamente com o princípio psicológico que Kent Beck denomina "Ignorância Produtiva". Num cenário de constante mudança, é ineficaz fingir que se sabe tudo. A ignorância produtiva é a atitude de aceitar a incerteza e priorizar o aprendizado focado. A seleção de tecnologias "tediosas" é uma aplicação estratégica dessa perspectiva. A equipe reconhece sua falta de conhecimento sobre as inovações tecnológicas mais recentes e decide operar em um campo onde sua expertise é sólida, direcionando assim sua energia de aprendizado para o problema de negócio em questão.

A previsibilidade é crucial para minimizar surpresas na engenharia de software, uma disciplina já complexa. Novas tecnologias aumentam essa complexidade exponencialmente, introduzindo "desconhecidos desconhecidos" – problemas totalmente imprevistos, ao contrário dos "desconhecidos conhecidos" que podem ser antecipados e planejados, como uma partição de rede.

Tecnologias inovadoras são repletas de "desconhecidos desconhecidos": não se sabe como se comportarão em escala, que tipo de interrupções inesperadas de garbage collection podem causar, ou quais vulnerabilidades de segurança sutis podem abrigar. Em contraste, uma tecnologia considerada "tediosa" já transformou a maioria de seus "desconhecidos desconhecidos" em "desconhecidos conhecidos" através do uso generalizado. A comunidade já encontrou as falhas, e as soluções são facilmente acessíveis, muitas vezes com uma simples pesquisa no Stack Overflow.

Essa previsibilidade reduz drasticamente a carga cognitiva sobre a equipe de engenharia, permitindo que se concentrem na resolução de problemas de negócio, em vez de gastar tempo depurando a infraestrutura.

A Economia do "Token de Inovação"

Para contextualizar a adoção de novas tecnologias, McKinley introduz o conceito de "tokens de inovação". Ele sugere que cada empresa possui uma quantidade limitada desses tokens – talvez três – que representam sua capacidade de realizar trabalhos criativos, arriscados ou desafiadores. Esses tokens são um recurso estratégico escasso e devem ser "orçados" com a mesma atenção dedicada ao capital financeiro.

Essa metáfora transforma a escolha tecnológica de uma decisão meramente técnica para uma decisão de alocação estratégica de portfólio. Utilizar um token de inovação em algo fundamental, como um banco de dados (por exemplo, optar por MongoDB quando a equipe já domina MySQL) ou um novo paradigma de programação (adotar NodeJS em uma empresa que usa Ruby), é um investimento de alto risco em uma área que não diferencia o negócio. Uma empresa não obtém vantagem competitiva por ter um banco de dados "moderno"; sua vantagem deriva do produto construído sobre ele. Ao gastar um token de inovação na infraestrutura, a organização esgota sua capacidade de inovar onde realmente importa: nas funcionalidades do produto principal, que os clientes percebem e valorizam.

Assim, a gestão do portfólio de tecnologia, sob essa ótica, torna-se um exercício de gestão de risco. A função de um líder de tecnologia é alocar o orçamento de risco da empresa de forma eficaz. Escolher tecnologia "tediosa" para sistemas fundamentais e não diferenciadores é análogo a selecionar ativos estáveis e de baixo risco para a base de uma carteira de investimentos. Essa abordagem estabiliza o portfólio geral e preserva o "capital de risco" (os tokens de inovação) para ser investido em apostas de alto risco e alta recompensa que impactam diretamente a posição de mercado da empresa.

Custo real da tecnologia: Sobrecarga cognitiva e operacional

A escolha de soluções tecnológicas, embora muitas vezes impulsionada pela busca da "melhor ferramenta", pode levar a uma otimização míope com custos sistêmicos significativos. McKinley ressalta que o verdadeiro custo de uma tecnologia vai além do desenvolvimento inicial, englobando o custo total de propriedade, que inclui a sobrecarga operacional e cognitiva.

Essa sobrecarga se manifesta na necessidade de criar novas estratégias de monitoramento, desenvolver testes unitários, configurar scripts de inicialização, treinar novos engenheiros e, crucialmente, na carga cognitiva de gerenciar mais um sistema. Cada nova adição ao stack tecnológico fragmenta o conhecimento e a atenção da equipe. O caso da empresa Etsy, mencionada por McKinley em seu ensaio, ilustra essa armadilha: a contratação de programadores Python resultou em uma "camada intermediária inútil" que levou anos para ser eliminada. Essa otimização local (aproveitar as habilidades dos programadores) gerou uma ineficiência global massiva e atrasou o sucesso da empresa.

Em contrapartida, a contenção deliberada pode gerar benefícios a longo prazo. Os feeds de atividade da Etsy, por exemplo, foram construídos sobre um stack "tedioso" (PHP, MySQL, Memcached, Gearman). Embora a implementação inicial tenha sido mais complexa do que seria com uma ferramenta moderna como o Redis, essa escolha permitiu que a funcionalidade escalasse 20 vezes ao longo de vários anos sem exigir atenção constante. A estabilidade e a familiaridade do stack subjacente garantiram seu funcionamento confiável em segundo plano, liberando os engenheiros para focar em problemas mais urgentes. A lição é clara: os custos operacionais de longo prazo de uma tecnologia geralmente superam a conveniência de desenvolvimento de curto prazo.

Compreender e aplicar a filosofia de "Tecnologias Tediosas" é um primeiro passo crucial para construir sistemas robustos e escaláveis. No entanto, essa abordagem frequentemente enfrenta resistência quando confrontada com a pressão por velocidade e inovação. No próximo artigo, exploraremos como equilibrar essa aparente contradição entre estabilidade e rapidez no desenvolvimento de software.

Soluções Tediosas: Estratégia para uma Engenharia Sustentável

Rodrigo de Avila — Sat, 18 Oct 2025 12:51:08 +0000

Na engenharia de software atual, há um conflito central: a atração por novas tecnologias versus a solidez de sistemas já estabelecidos. Desenvolvedores frequentemente se veem divididos, seduzidos pelas últimas ferramentas que prometem soluções mágicas, enquanto a experiência adverte sobre os custos ocultos da novidade. Nesta série de artigos vamos ver que a contenção tecnológica estratégica não barra a inovação; pelo contrário, ela a impulsiona.

A verdadeira agilidade e liberdade na engenharia vêm do domínio profundo de um conjunto de ferramentas estável e intencionalmente limitado, e não da busca incessante pelo que é novo. Por trás dessa abordagem, há um fundamento psicológico vital: uma mentalidade de engenharia que valoriza o aprendizado aprofundado em detrimento da exploração constante.

Para desenvolver essa ideia, vamos nos apoiar em quatro pilares filosóficos que, juntos, criam uma base sólida para a liderança tecnológica.

Primeiro, será explorada a filosofia de Dan McKinley, "Choose Boring Technology" (Escolha Tecnologia Tediosa), vista como uma estratégia inteligente de gerenciamento de risco e alocação de recursos.
Em segundo lugar, será analisada a "Lei da Iteração" do Coronel John Boyd, um princípio militar que mostra como a velocidade de iteração é uma vantagem competitiva crucial no desenvolvimento de software.
Em terceiro lugar, vamos examinar como esses conceitos abstratos são aplicados na prática, usando o GitLab como estudo de caso. A empresa atribui sua impressionante cadência de lançamentos à sua preferência por "soluções tediosas".
Por fim, a filosofia será atualizada para o cenário contemporâneo com a reavaliação de Aaron Brethorst, que argumenta que a chegada dos assistentes de codificação com Inteligência Artificial (IA) torna os princípios da tecnologia tediosa ainda mais importantes.

Depois de desmembrar esses pilares, examinaremos como aplicar esses conceitos na tomada de decisões tecnológicas, estabelecendo critérios objetivos para avaliar novas ferramentas e manter a consistência arquitetural ao longo do tempo.

Ao desmembrar e depois interligar esses pilares, você terá um guia prático para líderes de tecnologia que buscam construir organizações de engenharia sustentáveis, produtivas e verdadeiramente inovadoras.

DoH: como funciona a consulta DNS no Clear Address?

Rodrigo de Avila — Fri, 08 Aug 2025 16:30:00 +0000

Olá, pessoal!

Recentemente, o valterpatrick sugeriu que mostrasse como as consultas DNS são realizadas no site clear-address.rda.run. Agradeço muito pela pergunta, pois ela abre espaço para discutirmos um tema que considero fascinante e muito útil: DNS over HTTPS (DoH).

Em vez de usar o protocolo DNS tradicional, que geralmente opera de forma não criptografada na porta 53, o site utiliza as APIs públicas de resolvedores DNS que suportam HTTPS. Na prática, isso significa que uma consulta DNS se transforma em uma simples chamada HTTP. Isso traz uma camada extra de privacidade e segurança, pois a consulta se camufla como tráfego HTTPS comum.

A Mágica por Trás da Cortina: As APIs

O backend do Clear Address faz chamadas para resolvedores DoH, como os oferecidos pela Cloudflare e pelo Google. A escolha entre eles pode variar, mas o princípio é exatamente o mesmo.

A ideia é enviar uma requisição GET para um endpoint específico, passando o domínio e o tipo de registro desejado como parâmetros na URL. O servidor responde com um JSON contendo os resultados da consulta.

DoH via Cloudflare

A Cloudflare é uma das provedoras mais conhecidas de serviços DoH. A documentação completa pode ser encontrada aqui.

Para consultar o registro AAAA (endereço IPv6) do próprio clear-address.rda.run, a URL da API fica assim:

https://cloudflare-dns.com/dns-query?name=clear-address.rda.run&type=AAAA

Usando cURL

Você pode testar isso diretamente no seu terminal com o cURL. O header Accept é importante para garantir que a Cloudflare nos devolva uma resposta em JSON.

curl -H 'Accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=clear-address.rda.run&type=AAAA'

Usando Go

No backend, o processo é similar. Aqui está um exemplo simples em Go de como fazer essa chamada e processar a resposta.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
)

// Estrutura para receber a resposta da API da Cloudflare
type DNSResponse struct {
    Status   int  `json:"Status"`
    TC       bool `json:"TC"`
    RD       bool `json:"RD"`
    RA       bool `json:"RA"`
    AD       bool `json:"AD"`
    CD       bool `json:"CD"`
    Question []struct {
        Name string `json:"name"`
        Type int    `json:"type"`
    } `json:"Question"`
    Answer []struct {
        Name string `json:"name"`
        Type int    `json:"type"`
        TTL  int    `json:"TTL"`
        Data string `json:"data"`
    } `json:"Answer"`
}

func main() {
    // URL da API da Cloudflare para a consulta desejada
    url := "https://cloudflare-dns.com/dns-query?name=clear-address.rda.run&type=AAAA"

    // Cria uma nova requisição
    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        panic(err)
    }

    // Adiciona o header 'Accept' para especificar o formato da resposta
    req.Header.Add("Accept", "application/dns-json")

    // Executa a requisição
    client := &http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()

    // Lê o corpo da resposta
    body, err := io.ReadAll(resp.Body)
    if err != nil {
        panic(err)
    }

    // Decodifica o JSON na nossa struct
    var dnsResp DNSResponse
    if err := json.Unmarshal(body, &dnsResp); err != nil {
        panic(err)
    }

    // Imprime os resultados
    fmt.Println("Resultados da consulta DNS:")
    if len(dnsResp.Answer) > 0 {
        for _, answer := range dnsResp.Answer {
            fmt.Printf(" - Domínio: %s\n", answer.Name)
            fmt.Printf("   Tipo: AAAA\n")
            fmt.Printf("   TTL: %d\n", answer.TTL)
            fmt.Printf("   Endereço IPv6: %s\n", answer.Data)
        }
    } else {
        fmt.Println("Nenhum registro AAAA encontrado.")
    }
}

DoH via Google

O Google oferece um serviço similar, documentado aqui. A lógica é a mesma, mudando apenas a URL.

https://dns.google/resolve?name=clear-address.rda.run&type=AAAA

A implementação, seja com cURL ou Go, seguiria o mesmo padrão, adaptando-se apenas à estrutura do JSON de resposta do Google, que pode ter pequenas diferenças.

Backend vs. Frontend

Uma observação importante: no Clear Address, essas chamadas são sempre feitas pelo backend. Nunca tentei fazê-las diretamente pelo frontend (via JavaScript no navegador), então não sei dizer se haveria problemas com CORS (Cross-Origin Resource Sharing) ou a necessidade de algum header específico para que a requisição fosse aceita. Fazer pelo backend simplifica o processo e mantém a lógica de negócio no servidor.

Conclusão

E é isso! Sem grande complexidade, o Clear Address apenas utiliza as APIs públicas e bem documentadas de grandes players para resolver nomes de domínio de forma segura e privada.

Espero que este artigo tenha saciado a curiosidade e mostrado como é simples implementar algo parecido.

O que vocês acham dessa abordagem? Já usaram DoH em algum projeto? Deixem suas experiências e dúvidas nos comentários.

Um abraço.

Por que sua validação de e-mail com Regex provavelmente está errada.

Rodrigo de Avila — Fri, 08 Aug 2025 13:45:55 +0000

Olá, pessoal!

Hoje quero discutir um tópico que parece simples, mas que esconde uma complexidade enorme: a validação de endereços de e-mail.

Se você trabalha com desenvolvimento, provavelmente já precisou validar um campo de e-mail. E qual é a primeira solução que vem à mente? Uma bela expressão regular (Regex), certo? A gente busca no Stack Overflow, copia, cola e pronto. Mas e se eu te disser que essa abordagem, na maioria das vezes, está errada?

Em 2021, um artigo chamado "Your E-Mail Validation Logic is Wrong" de Jan Schaumann, do blog Netmeister, me deixou surpreso. Ele demonstrou, com base nas RFCs (os documentos que padronizam a internet), uma série de casos extremos e sintaxes válidas de e-mail que 99% das expressões regulares rejeitariam. O artigo é um grande alerta sobre como a nossa intuição sobre o que é um e-mail válido pode estar completamente desalinhada com os padrões oficiais.

Então, qual é a única forma 100% garantida de validar um e-mail? Enviando uma mensagem para ele.

É o que fazemos em fluxos de cadastro: o usuário informa o e-mail e nós enviamos um link de confirmação. Simples e eficaz.

O problema das listas de e-mail existentes

A situação muda quando uma organização possui uma base de dados antiga, com milhares de e-mails coletados ao longo dos anos, sem o devido cuidado na validação. Enviar uma campanha para essa lista "suja" é um convite para altas taxas de bounce (devolução), reclamações de spam e, consequentemente, um dano terrível à reputação do seu domínio.

Mesmo que um endereço seja tecnicamente válido, fatores como caixa de entrada cheia, filtros de spam agressivos ou problemas temporários no servidor do destinatário podem impedir a entrega. E, claro, nem vou entrar no mérito da compra de listas de e-mail. Isso é uma prática péssima e deve ser evitada a todo custo.

Se a validação com Regex não é confiável e enviar um e-mail para cada contato não é uma opção viável, como podemos limpar essa base de contatos? A resposta está em analisar as duas partes que compõem um endereço: a parte local (antes do @) e o domínio (depois do @).

Validando o Domínio com DNS

A primeira e mais importante verificação é no domínio. Uma simples consulta DNS nos diz muito sobre a capacidade dele de receber e-mails.

Registro NS (Name Server): A primeira coisa a fazer é verificar se o domínio realmente existe e está registrado em algum lugar. Uma consulta pelo registro NS nos dá essa resposta. Se não houver registro NS, o domínio é inválido.
Registro MX (Mail Exchange): Este é o registro crucial. Ele lista quais servidores de e-mail são responsáveis por receber mensagens para aquele domínio. Se um domínio não possui registros MX, seus e-mails não chegarão a lugar nenhum. Para ser ainda mais assertivo, você pode fazer uma consulta DNS dos registros A/AAAA de cada servidor listado no MX para garantir que eles também existam.

No meu artigo anterior, "DoH: como funciona a consulta DNS no Clear Address?", eu mostro como é possível fazer essas consultas usando uma API pública, o que facilita a automação desse processo.

Cuidado com os domínios temporários ou descartáveis

Além de verificar a existência dos registros DNS, precisamos ter cuidado com um tipo especial de serviço: os E-mails Descartáveis. Serviços como Temp Mail ou 10 Minute Mail oferecem endereços temporários. Usuários os utilizam para se cadastrar em serviços sem revelar seu e-mail principal, evitando spam. Para as empresas, enviar campanhas para esses endereços é jogar dinheiro fora. O e-mail deixará de existir em minutos ou horas, poluindo sua lista, piorando seu engajamento e prejudicando sua reputação. Existem dezenas de repositórios no GitHub com listas atualizadas desses domínios, que precisam ser constantemente monitoradas, pois novos serviços surgem a todo momento.

Existem dezenas de repositórios no Github com listas de domínios atualizadas constantemente, contendo os domínios desses serviços. As listas precisam mesmo ser atualizadas com frequência, pois esses serviços mudam de nome, ou de domínio, com frequência. Comparar o domínio com essas listas pode ajudar a eliminar muitos endereços que, apesar de serem corretos, não servem para nada.

Quando mais de uma pessoa cuida de uma conta

Outra coisa a cuidar são os Endereços Funcionais (Role-Based). Endereços como vendas@, contato@ ou suporte@ são genéricos e pertencem a uma função, não a um indivíduo. O envio de marketing para esses e-mails é problemático. A pessoa que se cadastrou pode não fazer mais parte da equipe, e o novo responsável, ao receber uma comunicação que nunca solicitou, tem uma grande chance de marcar sua mensagem como spam.

Conclusão

A abordagem que apresentei aqui não garante que a caixa de e-mail existe, que a parte local (usuario) está correta ou que a conta pode receber novas mensagens.

No entanto, ela aumenta drasticamente a probabilidade de um endereço estar bem estruturado e apontando para um domínio legítimo e capaz de receber e-mails. Essa validação é extremamente útil para a higiene de listas, pois permite:

Reduzir taxas de devolução causadas por erros de digitação ou domínios inexistentes.
Identificar e remover endereços descartáveis que apenas geram custo.
Segmentar ou remover endereços funcionais que podem gerar reclamações de spam.

Shameless plug

Para facilitar esse processo, desenvolvi uma ferramenta gratuita chamada Clear Address. Falei dela em um Pitch essa semana. Com uma única chamada de API, você pode realizar todas essas verificações.

Por exemplo, uma simples requisição GET para a API https://clear-address.rda.run/v1/contato@temp-mail.org irá te informar que o domínio pertence a um serviço descartável e que a parte local é um endereço funcional.

Fica o convite para testarem a ferramenta.

E você? Como valida seus e-mails?

Como você lida com a validação e limpeza de e-mails nas suas empresa?

AlmaLinux: habilitar NTP Sync

Rodrigo de Avila — Tue, 25 Jul 2023 02:13:29 +0000

$ sudo timedatectl set-ntp true

Quer ver se está habilitado? Veja se o comando abaixo retorna System clock synchronized: yes

$ sudo timedatectl
               Local time: Thu 2023-07-13 09:24:39 -03
           Universal time: Thu 2023-07-13 12:24:39 UTC
                 RTC time: Thu 2023-07-13 12:24:39
                Time zone: America/Sao_Paulo (-03, -0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

LVM: como adicionar novo disco a um volume group

Rodrigo de Avila — Tue, 25 Jul 2023 02:09:24 +0000

Qual disco será usado, e qual grupo será extendido?

$ lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0   16G  0 disk
|-sda1            8:1    0    1G  0 part /boot
`-sda2            8:2    0   15G  0 part
  |-centos-root 253:0    0 29.4G  0 lvm  /
  `-centos-swap 253:1    0  1.6G  0 lvm
sdb               8:16   0   16G  0 disk
sr0              11:0    1 1024M  0 rom

Aqui eu quero adicionar sdb ao / (grupo centos-root). Execute sempre como usuário root:

pvcreate /dev/sdb
lvmdiskscan -l
vgextend centos /dev/sdb
lvm lvextend -l +100%FREE /dev/mapper/centos-root
xfs_growfs /dev/mapper/centos-root

Como fazer redirecionamento de portas no Windows 10

Rodrigo de Avila — Fri, 13 Mar 2020 17:01:59 +0000

Já precisou fazer um redirecionamento de portas no Windows? Por acaso você já usou Docker Toolbox, e queria saber como evitar o uso do 192.168.99.100? Hoje eu aprendi que dá pra usar o comando netsh pra isso.

Acesse o Powershell como administrador, e digite

netsh interface portproxy add v4tov4 listenport=80 listenaddress=127.0.0.1 connectport=80 connectaddress=192.168.99.100

Para saber se a regra foi aplicada, execute

netsh interface portproxy show all