Encontrei um link para Choose Boring Technology de Dan McKinley por meio de um dos canais Slack da minha comunidade. Isso me fez pensar sobre a interconexão de: complexidade e dívida tecnológica, produtividade e velocidade do desenvolvedor, cultura de engenharia e tomada de decisões. Por fim, cheguei à conclusão de que a cultura de tomada de decisão — como as decisões são tomadas — tem uma enorme influência na produtividade de longo prazo da organização de engenharia.

Primeiro, alguns destaques da Boring Technology. Os três itens principais que ressoam comigo:

1. O custo de manutenção de longo prazo de uma tecnologia domina o custo total e supera em muito o benefício de velocidade de curto prazo.

Tendemos a nos concentrar nos benefícios de uma nova tecnologia sem sempre reconhecer totalmente os custos de manutenção contínuos - que geralmente dominam a longo prazo.

A maneira como nos comportamos realmente depende do que você acredita sobre qual termo domina essa equação no mundo real.

Se a tecnologia é realmente cara para operar, os custos dominam. Se a tecnologia realmente faz uma grande diferença na facilidade do seu trabalho, os benefícios dominam.

#48

2. As pessoas (frequentemente) ficam muito opinativas sobre a escolha do banco de dados…

Estou incluído nessa lista de pessoas que são muito opinativas, mas mais por razões relacionadas ao fato de entender intimamente quanto tempo e esforço são necessários para construir o conhecimento especializado necessário para realmente entender um determinado RDBMS ou tecnologia de armazenamento de dados.

Na minha experiência, é aqui que as rodas saem. As pessoas perdem a cabeça e começam a bater seus tambores de programadores poliglotas. Há algo sobre a ideia de adicionar um novo banco de dados que tem pessoas invadindo a Bastilha, dizendo “você não pode nos impedir de usar a melhor ferramenta para o trabalho, cara”.

E quando as pessoas sucumbem a esse instinto, dizem a si mesmas que estão dando liberdade aos desenvolvedores. E claro, é liberdade, mas é uma definição muito restrita do que é liberdade. #36

O ponto aqui é que a opinião e a noção de liberdade e/ou satisfação podem dominar a narrativa da escolha da tecnologia se não houver um processo sólido para a tomada de decisões.

3. Em última análise, nosso objetivo na criação e manutenção de produtos (sistemas) é oferecer suporte a um resultado de negócios bem-sucedido. Não para construir tecnologia sofisticada.

Voltando à minha primeira experiência de start-up SaaS - construímos Eloqua em tecnologia chata - Visual Basic (sem brincadeira, era o ano de 2000), SQL Server, IIS.

Naqueles primeiros anos, desenvolvi algumas ferramentas chatas (você adivinhou — também em Visual Basic) para automatizar implantações e realizar monitoramento básico de endpoint. (Era pré-nuvem pública, gente!). Meu principal objetivo era economizar tempo e reduzir erros nas implantações — tínhamos uma equipe muito enxuta e essas ferramentas melhoraram significativamente nossa eficiência.

Em 2008, oito anos após o início do ciclo de vida da empresa, minha equipe de “Operações de Produção” de nove pessoas dava suporte ao data center, todo o hardware e infraestrutura, rede e experiência em banco de dados. Diariamente, vimos algumas dezenas de milhões de transações. No quarto trimestre de 2008, mantivemos 99,998% de tempo de atividade, e fizemos isso enquanto reduzíamos os custos, nessa pilha de tecnologia realmente chata.

Obviamente, esta pilha chata na Eloqua teria parecido muito diferente se a tivéssemos construído com as tecnologias disponíveis nos últimos cinco a dez anos. E haveria benefícios significativos que poderíamos ter visto com algumas tecnologias específicas. Mas com as tecnologias atuais disponíveis, a facilidade de criar um novo serviço gerenciado deve ser ponderada em relação ao custo total de propriedade de longo prazo.

Portanto:

Você deve ter um processo para adicionar tecnologia à sua pilha que envolva conversar com outras pessoas. #86

Como você toma essas decisões na escala de mais de 20 equipes?

Na FreshBooks, passamos muito tempo trabalhando nessas questões e, finalmente, trabalhamos para trazer clareza e substância ao processo de tomada de decisão usando:

• Documentação de engenharia para documentar claramente as informações e processos importantes e que mudam lentamente e que são importantes para a organização
• Uma estrutura de tomada de decisão para ajudar as equipes a entender quais decisões podem ser tomadas em nível de equipe versus nível organizacional e onde obter documentação
• Um Tech Radar interno que descreve as ferramentas, tecnologias que devem e não devem ser adotadas
• Um processo de solicitação de comentários (RFC) para uma estrutura de avaliação e recomendação de novas abordagens ou tecnologias
• Registros de decisão de arquitetura (ADRs) para documentar decisões

Recentemente, decidi sair do FreshBooks, mas tenho esperança de que essas abordagens coletivas levem a decisões duráveis, complexidade reduzida e maior produtividade. ( Pessoal do FreshBooks - mantenha-me honesto e deixe-me saber como isso acontece... )

De volta a Eloqua. Fizemos nossas escolhas tediosas de tecnologia por necessidade durante a maior parte da história da empresa. Criamos uma nova categoria – Automação de Marketing – mas tínhamos uma cultura que era percebida como (e provavelmente era) baixa em inovação técnica. Não tínhamos um forte processo de tomada de decisão, mas nossas decisões eram fortemente influenciadas pela necessidade de oferecer suporte a um fluxo de receita B2B empresarial.

Por fim, vendemos a Eloqua e sua pilha de tecnologias chatas para a Oracle por cerca de US$ 900 milhões. Tenho certeza de que a receita recorrente e a taxa de crescimento da receita foram os principais interesses deles neste negócio... e nossas escolhas de tecnologia chatas simplesmente passaram na devida diligência.