Escolha tecnologias entediantes (2015)

• Adotar novas tecnologias com moderação e priorizar tecnologias comprovadas (boring technology) favorece o sucesso de longo prazo da empresa
• Toda empresa tem cerca de 3 tokens de inovação (innovation tokens), e cada escolha como NodeJS, MongoDB ou ferramentas recém-lançadas consome um deles
• Tecnologias comprovadas têm capacidades e modos de falha (failure modes) bem conhecidos, então o risco dos desconhecidos desconhecidos (unknown unknowns) típicos de tecnologias novas é menor
• A escolha de tecnologia afeta toda a equipe e a organização, e por causa da carga operacional e da sobrecarga cognitiva, uma ferramenta razoável para vários problemas costuma ser melhor do que a melhor ferramenta para um trabalho específico
• Escolhas tecnológicas cuidadosas dão aos engenheiros liberdade para focar em problemas maiores, e tecnologia pela tecnologia não tem valor

---

Aceite o tédio (Embrace Boredom)

• Toda empresa tem cerca de 3 tokens de inovação (innovation tokens) e essa oferta fica estável por um bom tempo — parte dela pode aumentar ao conquistar estabilidade e maturidade, mas há uma tendência a superestimar quantos tokens se tem
• Escrever um site em NodeJS, usar MongoDB e adotar uma tecnologia de service discovery com menos de um ano de lançamento consomem 1 token de inovação cada; escrever o próprio banco de dados é um grande problema
  • Essas escolhas podem fazer sentido para uma consultoria de JavaScript ou uma empresa de banco de dados, mas a maioria está perseguindo grandes missões como redefinir o comércio global ou reinventar pagamentos na web — gastar a atenção limitada da empresa inovando em áreas como ssh é um atalho para o fracasso ou para atrasar o sucesso
• "Entediante (boring)" não é o mesmo que "ruim (bad)", e também existem tecnologias entediantes e ruins — exemplos de tecnologias entediantes e boas o suficiente: MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• A vantagem das tecnologias entediantes não está só nas capacidades (capabilities), mas também no fato de que seus modos de falha (failure modes) são bem compreendidos
• Na escolha de tecnologia coexistem known unknowns (por exemplo, não saber como o banco de dados se comporta quando a CPU chega a 100%) e unknown unknowns (por exemplo, não imaginar que o registro de estatísticas causaria pausas de GC); quanto mais nova a tecnologia, maior tende a ser a escala dos unknown unknowns

Otimize globalmente (Optimize Globally)

• Preferir tecnologias entediantes é um bom viés, mas não o único fator; a escolha de tecnologia tem escopo (scope) e afeta a equipe, a organização e o sistema como um todo
• Adicionar uma tecnologia tem custo — se você já usa Ruby, acrescentar Python pode fazer a complexidade superar o benefício marginal, mas em debates como Python vs Scala ou MySQL vs Redis é comum abandonar essas restrições e gritar "a melhor ferramenta para o trabalho (best tool for the job)"
• A essência do trabalho é mapear problemas de negócio para o espaço de soluções oferecido pelas escolhas de software; se escolher não tivesse custo, seria possível selecionar a ferramenta localmente ótima para cada problema, mas no mundo real esse custo existe
  • Esse custo está em operações (operations) e, em menor grau, na sobrecarga cognitiva (cognitive overhead) — monitoramento, testes unitários, conhecimento necessário para corrigir problemas e scripts de init se acumulam rapidamente
• O problema do raciocínio da "melhor ferramenta para o trabalho" é enxergar "melhor" e "trabalho" de forma míope — o verdadeiro trabalho é manter a empresa viva, e a ferramenta "melhor" é aquela que ocupa a posição de menos pior (least worst) no maior número possível de problemas
• O custo de longo prazo de manter um sistema estável supera em muito o desconforto sentido durante a construção, e desenvolvedores maduros e produtivos entendem isso

Às vezes, escolha novas tecnologias (Choose New Technology, Sometimes)

• Levar essa lógica ao extremo faria você implementar sites só com Java, o que é irrealista — é preciso ter algum meio de adicionar novas ferramentas à caixa
• Como uma nova tecnologia acaba tendo impacto em toda a empresa, sua adoção é uma decisão que exige visibilidade em toda a empresa (company-wide visibility) — é preciso criar a expectativa cultural de que "isso é algo que todos nós discutimos juntos"
• A prática mais recomendável é se perguntar como resolver o problema atual sem adicionar uma nova tecnologia — isso ajuda a perceber quando o "problema" é apenas alguém querendo usar aquela tecnologia, e nesse caso a iniciativa deve parar imediatamente
  • Dá para ir longe com um número pequeno de escolhas tecnológicas, e a resposta real raramente é "não dá"; normalmente é "dá, mas é difícil demais" — se parece impossível atingir o objetivo com os recursos atuais, talvez você ainda não tenha pensado de forma criativa o suficiente
• Ajuda registrar claramente por que resolver aquele problema na stack atual é caro e difícil demais
• A adoção de uma nova tecnologia pode ser puramente aditiva (por exemplo, adicionar memcached porque não há cache) ou pode se sobrepor ao que já existe ou substituí-lo — se for uma substituição, é preciso definir expectativas claras sobre a migração das funcionalidades existentes; em geral, a política assume a forma de "prometer a migração" junto com um cronograma proposto
  • A intenção é manter os destroços em um nível administrável e evitar a proliferação de soluções localmente ótimas
• Esse processo não é pesado: algumas perguntas para preencher como tarefa e uma reunião para discuti-las — se uma nova tecnologia ou um novo serviço passar por esse filtro sem problemas, então a adoção é apropriada

Simplesmente entregue (Just Ship)

• Programação poliglota (polyglot programming) é vendida com a promessa de que dar aos desenvolvedores liberdade total para escolher ferramentas torna a resolução de problemas mais eficaz, mas isso, na melhor das hipóteses, é uma definição ingênua do problema e, na pior, raciocínio sincronizado — o toil das operações do dia a dia esmaga os desenvolvedores
• São as escolhas tecnológicas cuidadosas que dão aos engenheiros liberdade para refletir sobre questões maiores; tecnologia pela tecnologia é charlatanismo

Caso da Etsy (nota de rodapé)

• A Etsy sofreu muito com esse problema no início — depois de contratar muitos programadores de Python, passou a procurar algo para eles fazerem e acabou criando uma camada intermediária sem sentido; levou anos para removê-la / ao mesmo tempo, a latência de busca no percentil 90 era de cerca de 2 minutos — a Etsy não fracassou, mas passou anos sem lançar nada, o que atrasou seu sucesso
• A interseção entre tecnologias entediantes e ruins costuma ser chamada de "enterprise software", mas isso pode não ser preciso
• O caso dos activity feeds da Etsy — foi implementado numa época em que quase tudo era consolidado em PHP, MySQL, Memcached e Gearman / a implementação foi muito mais complexa do que seria com uma ferramenta como Redis, mas ainda assim era totalmente possível construí-la com essa stack
  • Nos anos seguintes, enquanto a atenção se voltava para outras áreas, o uso de activity feeds cresceu 20 vezes, mas graças à plataforma compartilhada continuou funcionando normalmente sem mudanças dedicadas — um benefício de longo prazo da moderação nas escolhas tecnológicas
  • Isso não é absolutismo — activity feeds com memcached foi considerado prático, mas implementar busca textual completa com busca facetada em puro PHP não seria, então a Etsy usou Solr