Monopólio de linguagens: uma perspectiva além de tecnologia

Este artigo apresenta aspectos relacionados à escolha de linguagens e stacks de desenvolvimento em ecossistemas integrados de software. Convidamos os leitores a contribuírem com a discussão nos comentários, deixando seus pontos de vista e links para outras referências sobre o tema.

Comumente somos abordados com perguntas do tipo:

Conteúdo relacionado de patrocinadores

Preciso escolher uma stack para as equipes de desenvolvimento, qual seria a melhor?"

ou então algo como:

As equipes não possuem maturidade para escolher tecnologia, preciso escolher uma linguagem e padronizar.

ou:

A tecnologia X não está madura o suficiente para uso em produção, por isso escolhi padronizar com a tecnologia Y.

Neste artigo apresentamos pontos de vista sobre o pensamento de que padronizar é a única escolha e levantar a discussão sobre capacidade x maturidade em modelos de escolha de tecnologia.

Como tecnologistas defendemos abordagens razoáveis, afinal o que diferencia o remédio do veneno, é a dose utilizada.

No decorrer do artigo vamos discutir porque a escolha de apenas uma tecnologia, pode não ser adequada para o seu cenário. Por outro lado, a escolha de uma dezena de linguagens, também não parece tão razoável e irá impor à empresa uma carga desnecessária.

Monoglot Monopoly - Monopólio de Linguagem

Em muitas empresas as equipes de desenvolvimento utilizam ferramentas de uma lista pré-aprovada, normalmente incluindo apenas tecnologias que a empresa domina de alguma forma. Seja por meio de especialistas na sua força de trabalho ou suporte confiável do fornecedor. É o chamado Technical Reference Model. Um padrão de tecnologias homologado, utilizado em produção e que normalmente é conhecimento comum na empresa por seus profissionais.

Quando transportamos isso para o campo das linguagens de programação e stacks de desenvolvimento, não é incomum encontrar empresas em que apenas uma linguagem é permitida.

Essa noção de escolha de apenas uma linguagem e/ou um conjunto de ferramentas para desenvolvimento tem o nome de Monoglot Monopoly. É importante debatermos a noção da escolha de uma ou múltiplas tecnologias, impactos e benefícios.

Monoglot x Polyglot

Fonte: Imagem de domínio público

Programação poliglota é a noção de escrever software em diferentes linguagens e aproveitar os benefícios que cada tecnologia tem a oferecer.

Muitas linguagens e stacks são famosas por algum motivo, seja fácil aprendizado, alta produtividade ou resolução de um tipo específico de problema. A ideia de ser poliglota, gira em torno de conseguir acionar a ferramenta correta para resolver um dado problema, isso traz junto diferentes maneiras de pensar e metodologias de trabalho.

Esse mix de maneiras de se construir permite que as equipes não fiquem limitadas a ferramentas inferiores para um tipo específico de problema, mas traz junto uma série de preocupações com relação a complexidade dos ambientes, habilidades e conhecimentos necessários e, em alguns casos, até complexidade na gestão de múltiplos fornecedores.

Para um desenvolvedor ou para um gestor pode parecer tentador continuar sendo "monoglota" e perseguir o caminho de ser muito bom (seja lá o que isso queira dizer) em uma linguagem específica. A ideia de ter pessoas dominando a linguagem que usam parece muito mais tentadora, mas o que temos visto na prática nos últimos anos atuando em clientes de diferentes portes não é isso.

A ideia de que se houver apenas uma linguagem, as pessoas vão dominá-la, não se confirma na prática. Muitos profissionais param em um nível "intermediário" de conhecimento da linguagem. Além disso, determinadas tecnologias são opinativas na forma de resolver alguns problemas, isso acaba afetando a maneira como as equipes pensam em uma solução para os problemas de maneira geral.

Ter uma visão poliglota pode reforçar alguns conceitos sobre computação, permitindo abordar os problemas por meio de conceitos e não de tecnologia. Além disso, conhecer outra linguagem vai faz com que a equipe, melhore o entendimento da sua linguagem atual.

Do ponto de vista mais prático, conhecer outras linguagens no mínimo vai ajudar a ler outros exemplos de códigos, no stack overflow por exemplo, e vai facilitar o entendimento com relação aos desafios que enfrentamos em projetos. Não que esse seja um bom motivo para aprender outra linguagem, mas isso já nos salvou em muitos projetos. Johnny Boursiquot é Engenheiro de software e SRE com duas décadas de experiência em várias tecnologias em um de suas publicações no Twitter citou que:

Acredito que o meu verdadeiro valor como engenheiro de software é saber o que NÃO fazer. Na metade do tempo que tenho em um projeto, eu não sei exatamente o que fazer e tenho que experimentar até encontrar a correta abordagem. O que me ajuda sempre é o meu REPERTÓRIO de todas os outros projetos anteriores que já falhei e assim consigo evitá-las.

Autonomia x falta de controle

Ficar preso a uma tecnologia pode limitar as escolhas para resolução de um problema e consequentemente a inovação, por outro lado, deixar a equipe completamente livre para fazer escolhas traz outras complicações no dia a dia.

Esse é um problema complexo de ser resolvido, mas não por conta da tecnologia e sim por conta do posicionamento necessário de executivos e líderes de tecnologia na empresa.

Alguns podem citar a maturidade das equipes como impedimento para autonomia. Se esse for o caso, temos um trabalho a ser feito pelas lideranças. Porque a equipe não pode ter autonomia? Não é trabalho do líder desenvolvê-los? Porque contratar pessoas em que não confia ou que não estão preparadas?

A situação que queremos discutir, parte do pressuposto que a equipe pode receber mais autonomia.

Líderes frequentemente dizem que querem empoderar as equipes e "liberar" o potencial de inovação, mas devem estar sempre atentos a direção que estão tomando. Então, como podemos promover autonomia sem ter uma liberdade excessiva que seja prejudicial à economia de escala, respeitando os recursos da empresa, que não gere overhead na tomada de decisão e continue de acordo com a visão de risco da empresa, por exemplo?

Para resolver esse problema a liderança precisa criar guardrails. Na prática, se trata de começar a falar mais de resultados aderentes e menos de modelos pré-estabelecidos. Mas vamos dar uma passo atrás e discutir outros pontos importantes.

Autonomia e senso de responsabilidade

A autonomia das equipes deve ser guiada com accountability. A tomada de decisão "livre" deve trazer junto a responsabilidade pelo caminho escolhido. Nesse ponto é preciso ter cuidado para que a responsabilização não seja utilizada como mecanismo de pressão para direcionar uma decisão sub-ótima. A responsabilidade, traz o senso de propriedade e pertencimento, que são características que também desejamos nas equipes. A autonomia ainda precisa de mais algumas peças para gerar resultados e isso nos leva ao próximo ponto.

Mais alinhamento e menos controle

Junto com a autonomia da equipe vem a necessidade do alinhamento com os objetivos, para que as decisões tomadas estejam de acordo com visões e estratégias da empresa. Cada equipe pode tomar sua decisão, mas devemos remar todos para o mesmo lado.

Avaliar as decisões por aderência a capacidades necessárias

Obviamente promover autonomia com alinhamento não é uma tarefa simples, mas podemos colocar mecanismos em prática para facilitar isso. Uma das primeiras coisas a se pensar é a mudança do mindset de maturidade necessária para capacidades necessárias.

Transportando isso para prática com relação a escolha de linguagens, significa que devemos deixar de escolher com base em uma lista de tecnologias "aprovadas" previamente e vamos começar a estabelecer uma lista de capacidades que precisam ser providas por qualquer linguagem ou stack que queira ser utilizada pelas equipes.

As tecnologias que hoje estão "aprovadas" em sua empresa, muito provavelmente estão lá porque as equipes têm maturidade com elas. Mas se quisermos dar autonomia às equipes, precisamos saber quais são as capacidades necessárias para habilitarmos qualquer tecnologia.

Alguns exemplos de capacidades podem ser:

1. Promover observabilidade para a tecnologia (ferramental);
2. Integrar com ferramentas de análise de vulnerabilidade existente ou propor nova ferramenta para análise da tecnologia em questão;
3. Conhecer ferramentas de troubleshooting para tecnologia.

Cada empresa terá seu conjunto de desafios particulares nesse quesito para reaproveitamento de capacidades existentes, ponderações econômicas, etc.

O fato é que até as linguagens mais tradicionais estão lançando versões com mais frequência. As empresas terão cada vez mais dificuldades de acompanhar o ritmo se continuarem no modelo atual, por isso o modelo de aderência a capacidades passa a fazer sentido até em um mundo monoglota.

Destravando a produtividade

O argumento comum a respeito de um ecossistema poliglota é o aumento da produtividade. Permitir a escolha da ferramenta certa para um dado problema vai reduzir o tempo de entrega.

Mas, existe outro fator ligado à produtividade que raramente é levado em conta. É a motivação do desenvolvedor. O foco na satisfação do desenvolvedor é um olhar que poucos gestores possuem, mas que quando observado e identificado pode fazer muita diferença.

Tendo uma experiência melhor no dia a dia de trabalho, o desenvolvedor vai ser mais produtivo e porque não dizer, feliz!

Fonte: Csíkszentmihályi Flow - Wikimedia

Nem todo conhecimento é portável

Um alerta que não podemos deixar de lado, é que temos que ter uma certa cautela com as escolhas e o nível de reaproveitamento ou "portabilidade" entre equipes e tecnologia que queremos dos nossos profissionais. Ter experiência com múltiplas tecnologias ajuda na formação de um background mais rico, mas não espere que todos consigam portar o conhecimento entre diferentes tecnologias o tempo todo.

Sobre a escolha de linguagens, a preocupação em especial é com relação a paradigmas diferentes. A experiência nos mostrou que existe uma curva grande de adaptação em alguns casos. Já presenciamos excelentes programadores com muita dificuldade na mudança para novos paradigmas.

Talentos e relacionamento com fornecedores

Dois tópicos que acreditamos serem superestimados, nas análises sobre adoção de um ecossistema poliglota, são: a aquisição e retenção de talentos; e relacionamento com fornecedores.

Com o passar do tempo, percebemos que a aquisição de talentos e construção de conhecimento não estão associados à escolha de uma ou múltiplas linguagens de programação. Diferentemente do que estamos acostumados a ler e o que é comumente divulgado.

Recrutar boas pessoas de tecnologia não tem sido uma tarefa fácil para nenhuma empresa no Brasil nos últimos 2 anos. Isso independe da tecnologia, mas talvez aceitar pessoas com backgrounds diferentes dos tradicionais Java e .Net traga uma diversidade boa nas equipes. Pense nisso.

Algumas empresas citam o relacionamento com fornecedores como um dos fatores para escolha de tecnologia. Quanto menos fornecedores, menor a complexidade de gestão e maior a capacidade de economia em escala. E a experiência também mostra que esta afirmação nem sempre é verdadeira.

Para empresas de pequeno porte, talvez possa fazer sentido, mas para empresas grandes, estar atrelado ao conhecimento tecnológico de uma única empresa pode ocasionar um cenário de lockin com um fornecedor e consequente diminuição do poder de barganha e em alguns casos até da capacidade cognitiva em criar coisas novas ou experimentar o novo.

Um único fornecedor atendendo uma grande empresa, pode inclusive levar a empresa para caminhos não tão seguros ou mesmo fazer com que toda uma estratégia de negócio seja prejudicada. Este é um ponto importante porque o lockin com um único fornecedor pode levar a empresa a uma situação de "sapo escaldado", quando perceber o tempo despendido para entrar e sair do caldeirão será tarde e muito dinheiro terá escorrido pelas mãos.

Conclusão

Este texto, como já relatado, é uma reflexão para que tecnologistas possam fazer uma análise de questões, como as descritas sob o aspecto de pessoas. Esse é o direcionador maior ao pensar em um ecossistema monoglota ou poliglota e consequente escolha de linguagem.

Sugerimos evitar a cilada de tentar responder "Qual a melhor tecnologia?". Ou evitar fazer pesquisas internas na própria empresa para tentar conhecer qual é a linguagem que dá match com os desenvolvedores. Já existem pesquisas suficientes no mercado e com respaldo técnico e científico que podem lhe auxiliar. Recentemente, o Stack Overflow liberou sua pesquisa anual 2019, com números significantes com relação a linguagens de programação, frameworks, bancos de dados e muito mais.

Pessoas > Linguagem e tecnologia

Não esqueça de pensar na motivação da equipe e das pessoas que serão contratadas quando estiver pensando na escolha da linguagem. Diferentes linguagens vão atrair diferentes perfis de profissionais conforme a experiência descrita pela Nubank neste podcast.

Fazer a avaliação no cenário da sua empresa vai depender muito do levantamento de capacidades necessárias que descrevemos neste artigo. Mas segue uma lista de alguns pontos que podem fazer sentido avaliar no processo de tomada de decisão de adoção de uma nova linguagem:

• Ecossistema de ferramentas;
• Aquisição de talentos, use a linguagem a seu favor;
• Formação e equalização de conhecimento;
• Necessidade de rotação de pessoas entre equipes de diferentes linguagens;
• Analisar o problema a ser resolvido para verificar qual linguagem escolher;
• Quão gradual pode ou deve ser a adoção dessas tecnologias.

Muitos livros atualmente falam sobre autonomia para equipes de tecnologia e produtos, mas se o desejo é ter algo relacionado ao que discutimos sobre escolha de linguagens, talvez algumas partes do livro Accelerate, o radar da Thoughtworks e os relatórios do Stack Overflow, em conjunto com a recomendação de Adopt para polyglot programming, sejam algumas fontes para olhar o tema com opinião de algumas pessoas reconhecidas no mercado.

Por um acaso este é um artigo sobre escolha de linguagens, mas o mindset que utilizamos para essa questão é o mesmo que utilizamos para escolhas de tecnologias e gestão de equipes de maneira geral. Toda a questão gira em torno de autonomia e perceber que a motivação das escolhas na maioria das vezes deveriam ser por aspectos que tocam pessoas e não simplesmente pela tecnologia.

O que você acha desse assunto? Já teve alguma experiência profissional similar? Quais foram os pontos positivos e negativos na escolha da linguagem e tecnologia?

Sobre os Autores