Software Engineering Theory in Practice: The Good, The Bad, & The Ugly

Resumo da palestra Software Engineering Theory in Practice: The Good, The Bad, & The Ugly. Palestrante: Mauricio Aniche, funcionário da Adyen.

Mauricio visou, nessa palestra, em passar uma visão do mercado de trabalho para nós acadêmicos. Ele é uma pessoa que se mudou para a Holanda para ser pesquisador, mas que acabou indo novamente parar na iniciativa privada. Sua carreira foi uma sucessão de ‘cavalos encilhados’ bem aproveitados, sem um grande plano prévio. Por isso, ele adquiriu um aprendizado prático que a Academia não tem como passar, mas que ele pôde passar em parte de volta para a Academia:

As empresas existem pelo negócio, não pelo código

Tudo numa empresa visa fazê-la crescer: todas as decisões de Engenharia de Software em uma empresa que usa essa ciência e que é tech-first são tomadas para fazerem a empresa crescer. Ninguém toma uma decisão de Engenharia de Software por ser uma Best Practice, ou escreve testes por isso ajudar a achar bugs, ou vão migrar para microsserviços por parecem legais e parecem escalar. Sempre tem uma decisão de negócios por trás das decisões de software.

Assim, por mais primorosa que seja a ferramenta que você criou, enquanto pesquisador, para o fim a que se propôs, nenhuma Engineering Board de nenhuma empresa irá adotá-la, ou financiar sua pesquisa, se você não mostrar o que isso vai melhorar pra ela a partir do ponto de vista do negócio. Num exemplo fictício, uma ferramenta que encontra bugs pode não ser útil, pois nem todos os bugs são importantes o bastante para precisarem de solução, e rodar a ferramenta requer uma equipe, o que consome recursos (tempo, dinheiro, mão de obra) que seriam melhor investidos em outra coisa. A princípio, não adotar Best Practices parece um contrassenso, já que elas existem para tornar tudo mais fácil, mas esse exemplo ilustra como Best Practices, por si só, não são relevantes para empresas.

Riscos demasiado grandes não são bem recebidos

Outra questão bastante pragmática é que nenhuma empresa de tecnologia irá fazer mudanças drásticas gigantescas (“big bang changes”), não importa quão melhor o software ficaria da nova forma proposta. Algo assim sequer será levado em consideração. A razão é simples: a probabilidade disso dar errado e quebrar algo no mundo real é muito grande para que alguma empresa seja imprudente e se arriscar a tal ponto. Por exemplo, um líder do Google já disse publicamente que uma ferramenta que crie um merge request que queira tocar 30.000 classes de uma só vez vai ser completamente ignorado pela equipe.

Portanto, quem estiver desenvolvendo uma ferramenta para “tornar o mundo melhor” deve levar em conta o funcionamento do mundo: as mudanças têm que ser feitas de parte em parte, gradualmente, pequeninas, e a ferramenta tem que permitir ser rodada de pouco em pouco nas mãos dos times de software. Nada de “big bang refactoring”.

Tempo é dinheiro, mas a pressa é inimiga da perfeição

Para o negócio, entregar valor para o cliente logo é mais importante que usar boas práticas ou fazer código bonito. Se um desenvolvedor tiver que levar um mês para implementar direito uma funcionalidade, mas tiver uma gambiarra como atalho para implementar ainda hoje, ele escolherá a gambiarra. Cabe à Gerência de Projeto a responsabilidade de achar uma forma pela qual o desenvolvedor entregue valor, mas, ao mesmo tempo, mantenha o sistema testável, livre de bugs, e com qualidade de código.

Um grande desafio do mundo real hoje é justamente equiparar o preço de escrever código certo e o de escrever gambiarra, para que a gambiarra não valha a pena, pois os desenvolvedores não vão parar para arrumar a bagunça a cada funcionalidade que tiver de ser implementada, tendendo então a situação a piorar muito ao longo do tempo. Então seria bem vinda pesquisa sobre meios e ferramentas melhores para aferição de apodrecimento de código, que, por sinal, acontece muito rapidamente.

Um problema relacionado é que, numa base de código infinitamente grande, os desenvolvedores terão um comportamento previsível de que, quando desafiados a implementar uma nova funcionalidade, eles olhem a base de código, vejam o que já foi feito no mesmo sentido, e duplicar pelas razões de que: economiza tempo, e funciona. Não é sensato reinventar a roda todos os dias, mas duplicar ideias ruins é realmente problemático. A cópia de trechos de código não é tão problemática quando a cópia de ideias mal elaboradas de mais alto nível, digamos, por problemas de comunicação entre os times.

Engenharia de Software inclui Gestão de Pessoas

Fala-se muito em escalabilidade, mas, no mundo real, esse problema não existe muita dificuldade de escalabilidade tecnológica fora de problemas bem específicos, como o Google. O problema real é a empresa crescer o time de desenvolvimento de uma dezena para centenas de pessoas e manter os processos funcionando satisfatoriamente, pois os canais de comunicação ficam muito mais complexos e a cultura muda. Há também a questão de Onboarding: como introduzir novos membros na equipe, se deslocar membros produtivos para tutorar os novatos reduz a produtividade dos veteranos?

A título de exemplo, a Adyen tem 800 desenvolvedores espalhados pelo mundo, e já é considerado dobrar esse total. Na Engineering Board desta empresa, quase toda reunião é mais sobre pessoas do que sobre tecnologia. Infelizmente, Engenharia de Software Social é um problema fundamental que tem sido estudado bem pouco, e até mesmo desconsiderado abertamente por pessoas proeminentes da área de Engenharia de Software como tema alheio a esta ciência.

Legado existe e você terá que lidar com ele

Toda empresa, no mundo real, tem código legado, e isso não é um sinal ruim. Não há ferramentas para manter o código limpo sempre, e, se restou código legado, pode ser uma empresa grande que teve um crescimento bastante rápido (um bom sinal), cujos custos para migrar sejam altos demais para valer a pena. Então tudo que um pesquisador faz tem que funcionar com código que saia um pouquinho do padrão, por causa de algum componente legado.

Mais do que isto: pode ser legado em ideias, e não em código. São requisitos então, para trabalhar em parceria com uma empresa: entender de tecnologias um pouco mais antigas, ir com a cabeça aberta, e ter disposição a customizar um pouco a solução para que a ferramenta funcione lá.

Testes automatizados não garantem qualidade

Mauricio adora testes automatizados, mas esse é só um dos mecanismos para garantir qualidade. Na escala de Facebook e Adyen, sequer é o mecanismo principal. Feature flags, deploy parcial e monitoramento são bem mais relevantes na prática, na escala mencionada. Tanto a Adyen quanto o Facebook, por exemplo, marcam atualizações para serem liberadas a apenas um pequeno percentual de usuários, e inicialmente apenas os mais geograficamente próximos às sedes destas empresas, a fim de facilitar que os funcionários possam caminhar até o local para resolver pessoalmente, se preciso for. Quanto ao monitoramento, sempre haverá bugs e sempre será preciso observá-los, pois não não dá para prevê-los todos, e é desejável saber o mais rápido possível o que está acontecendo.

O que faz sucesso na Academia não faz no mundo real

Quem vive na bolha do Twitter da Academia sabe que é preciso ter complexidade no paper para o revisor ver algum valor no que você fez e as convenções te aceitarem. Algo como “mostrar serviço”. No mundo real o contrário é que acontece: é muito difícil vender soluções complexas para Engineering Boards, pois soluções simples porém eficazes são as mais fáceis, menos custosas e menos arriscadas de implementar e de explicar para os desenvolvedores.

Devido a isto, pesquisadores que queiram causar impacto no mundo real, como Mauricio, devem fazer um trabalho interno de aceitação de que não irão ser aclamados em convenções acadêmicas, e que os problemas mais relevantes a serem resolvidos não necessariamente são os problemas da área preferida do pesquisador.

O casamento entre as necessidades das empresas e a pesquisa sendo realizada pode passar por encontrar um nicho certo, achar uma empresa que tenha interesse na sua solução. E, por achar uma empresa, entende-se ter um diálogo honesto, conhecendo empresários em eventos do ramo e ir conversando ao longo do tempo para entender os problemas deles, não só disparar e-mails em massa (spam) anunciando para as empresas o que você criou. O trabalho é ao contrário: primeiro conhece-se o problema, depois cria-se a solução, não como se faz, de primeiro criar a solução e depois procurar uma empresa que tenha aquele problema para ser resolvido. Também não funciona tentar forçar sua solução nos seus 3 parceiros industriais só por eles serem os mais próximos de ti.

Existe uma falha atualmente na Academia que é criar muitas ferramentas voltadas para big techs e ignorar as medium techs. Papers em conferências muitas vezes não são aceitos pois a ferramenta foi testada em “empresinhas” de 15 devs da cidade do pesquisador, e não na maior empresa do mundo. Ocorre que existem muitas empresas de médio porte no mundo todo, então soluções para elas não deveriam ser consideradas sem impacto. Ao mesmo tempo, mesmo que você encontre um problema real em uma grande empresa, digamos, no Google, eles NUNCA irão comprar sua solução, mesmo que de fato lá não esteja tudo da melhor forma possível, pela simples razão de que, estando tudo funcionando do jeito atual, a ferramenta não se mostra necessária na prática.