Você não é o Google (You Are Not Google)
(blog.bradfieldcs.com)Muitos engenheiros de software não são racionais na escolha de tecnologias. Ao adotar uma nova tecnologia, muitas vezes seguem simplesmente o fato de ela ser usada por grandes empresas de tecnologia como Google ou Amazon, sem uma necessidade real ou uma definição clara do problema. Por exemplo, MapReduce e Hadoop surgiram para processamento de dados em larga escala, mas quando empresas que não têm esse volume de dados os adotam, acabam sofrendo com custos de I/O desnecessários e perda de funcionalidades. Isso é apenas um fenômeno de "culto à tecnologia" (cargo cult).
O texto propõe uma checklist chamada UNPHAT para evitar esse tipo de imitação acrítica:
Understand – entenda bem o problema.
eNumerate – liste diferentes alternativas.
Paper – leia o artigo ou white paper em que a tecnologia se baseia.
Historical context – examine o contexto histórico em que foi desenvolvida.
Advantages – compare prós e contras de forma equilibrada.
Think – pense por conta própria se essa tecnologia realmente se encaixa no problema.
O texto apresenta exemplos de tecnologias como Cassandra, Kafka e SOA (Service-Oriented Architecture) que foram adotadas de forma acrítica em situações que não correspondiam aos seus casos reais de uso. Por exemplo, Kafka foi criado para o LinkedIn, que processa milhões de mensagens por segundo, mas às vezes é usado por pequenas empresas que têm apenas algumas dezenas de transações por dia.
O autor também enfatiza que até o próprio Google deixou de usar MapReduce quando concluiu que ele já não era mais adequado. No fim das contas, o importante não é a tecnologia em si, mas entender com precisão qual problema você está tentando resolver e escolher a tecnologia apropriada para isso.
Por fim, o autor menciona que Pólya, Hamming, Rich Hickey e outros vêm repetindo a mesma mensagem há muito tempo, e a ideia central é simples:
“Pense. E entenda o problema real.”
15 comentários
Acabei chegando aqui por acaso por uma recomendação do Google, mas este artigo foi escrito demais sob a ótica geek. Do ponto de vista de negócios, não faz o menor sentido. Por quê?
Ferramentas grandes usadas por big techs facilitam encontrar especialistas.
Muita gente aprende essas ferramentas para entrar em big techs, e muita gente estuda algo simplesmente porque foi escolhido por uma big tech. Naturalmente, é fácil encontrar pessoas que conheçam isso, e também é mais simples contratar gente experiente ou especialistas. Mas e se for uma ferramenta que ninguém conhece? Não é que não existam pessoas que tenham se aprofundado nela, mas encontrar esse tipo de profissional será muito mais difícil do que encontrar especialistas nas ferramentas das big techs.
Ferramentas grandes usadas por big techs têm abundância de referências e materiais
Ferramentas grandes, usadas por muita gente, têm fartura de materiais para resolver problemas e de resultados no Google. Na maioria dos casos, os problemas já foram enfrentados por outras pessoas, e com uma busca simples dá para identificar facilmente a questão. Já com uma ferramenta desconhecida, é difícil encontrar referências, e se surgir um problema, há grande chance de gastar muito tempo para descobrir a causa. E tempo também é dinheiro. Esse problema vem da pequena ferramenta recém-adotada? Ou será que estão entendendo errado um problema que vem de outro lado?
Na verdade, são as big techs que conseguem fazer esse tipo de mudança com mais facilidade. Como lidam com volumes absurdos de processamento de dados, um pequeno ganho de I/O pode representar um grande benefício para essas empresas. E também há muita gente disposta a estudar algo só porque as big techs adotaram. Já em empresas de pequeno e médio porte, por causa do volume relativamente menor de dados, um pequeno ganho de I/O não traz um benefício tão grande assim, enquanto os problemas acima são muito sérios. Além disso, também são poucas as pessoas dispostas a aprender a solução adotada por empresas menores. Por isso, para empresários de pequeno e médio porte, muitas vezes a conclusão econômica acaba sendo que, em vez de ficar discutindo esse tipo de coisa como um geek, é melhor simplesmente seguir as ferramentas das big techs.
Lendo o texto original, vi que ele foi escrito em 2017.
Já se passaram 8 anos desde então, e é surpreendente que isso ainda continue valendo.
Concordo bastante com o que foi dito acima!
Mas também acho que, quando acontece overengineering em empresas menores, isso às vezes é porque pessoas que têm como objetivo trabalhar em grandes empresas querem acumular experiência com essas ferramentas em empresas pequenas.
Claro que o CEO provavelmente não gosta muito disso haha
Será que 80% do motivo pelo qual ferramentas feitas sob medida para as necessidades de grandes empresas acabam sendo usadas do mesmo jeito em empresas pequenas não é exatamente isso? Quem deveria controlar isso seria o CTO, mas às vezes o próprio CTO já está pensando em mudar de emprego para uma grande empresa.
Se não há muito o que fazer, a gente acaba fazendo coisas desnecessárias, haha.
Também dá para complicar até problema fácil só para parecer que fez alguma coisa. E tem muita gente que, se você faz de um jeito simples, acha que é fácil mesmo... hahahaha
Por medo de fazer algo pequeno e depois ter que corrigir em grande escala mais tarde, às vezes acabamos construindo algo grande desde o início...
Acho que este texto também se aplica a K8s. Lembrei do livro "Como Programar de um Jeito Difícil de Manter". rsrs
No fim, é preciso entender o problema que as tecnologias estão tentando resolver e o contexto em que elas surgiram. Alguns exemplos citados no texto são os seguintes.
Acho que é importante analisar bem se o problema que elas tentam resolver está alinhado com o problema que eu estou tentando resolver.
Ah, concordo muito. Isso me fez lembrar que eu costumava aconselhar universitários/júniores, durante mentorias, a tentarem entender a história da tecnologia.
Parece que muita gente às vezes esquece que tecnologia é uma ferramenta, não um objetivo.
No momento em que coisas como “foi validado pelas big techs” ou “está sendo muito usado hoje em dia” passam a ser critérios principais na escolha de tecnologia, o aumento de custos desnecessários acaba vindo naturalmente.
Na Coreia, o cargo cult de Spring é forte.
Como é fácil contratar gente na primavera...
Na Coreia, o Spring é menos uma questão de adoração...
mais uma mistura híbrida da incompetência do governo com a preguiça dos desenvolvedores...
Concordo muito. No fim, o Spring também deve ser apenas uma ferramenta para resolver problemas.
Mapa mental de brainstorming, estudo de deep learning, o tempo de trabalho está diminuindo, julho, lembrete meu, com efeito no longo prazo.