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.
Top comments (0)