Os principais mitos da área de tecnologia — parte 3
Olá!
Esse texto finaliza uma série de artigos. Caso queira conferir os textos anteriores, são os seguintes:
Mito 21: NoSQL é sempre mais rápido que SQL.
Depende.
Quando comecei a escrever essa seção eu achei que fosse falso, para ser sincero. Porém, eu encontrei resultados diversos nas minhas pesquisas, desde o óbvio (como bancos chave-valor terem menos overhead) em cenários básicos, até os mais complexos, comparando múltiplas operações em diversos tipos de bancos:
O que isso prova? nada, na verdade. Pois o SQLite ganha em alguns cenários e o Postgres em outros.
O ponto que importa é o seguinte: ao escolher um banco de dados para sua aplicação, o que de fato importa é escolher o melhor tipo de banco que contempla a estrutura de dados e o padrão de acessos que sua aplicação possui, pois, é isso que vai importar para a saúde da sua aplicação no longo prazo.
Pela minha experiência, como SGBD é um tipo de ferramenta que precisa de suporte constante, o que importa mesmo é se o time que vai dar suporte para a ferramenta sabe mexer nela mais do que qualquer outra coisa. Isso é o que importa na hora de otimizar queries ou acionar o fail-over, por exemplo.
Se você é iniciante, minha recomendação é: comece com bancos relacionais se você não sabe muito bem o que tá fazendo, você irá errar menos. Além do suporte a ACID ser necessário para boa parte das aplicações transacionais que encontramos no dia-a-dia. Para algo voltado para escala ou para casos que não necessitem dados dados estruturados, ai sim podemos pensar em algo diferente, como ScyllaDB, Cassandra, MongoDB ou demais bancos mais arcanos.
Mito 22: Área X é mais fácil que Área Y.
Falso.
Toda área tem sua particularidade e requer perfis específicos para atingirem seu potencial. Apesar de uma pessoa que atua com Quality Assurance não saber todos os detalhes de sistemas distribuídos comparado com uma pessoa desenvolvedora back-end experiente, muitas vezes esse mesmo analista conhece de conceitos avançados de qualidade e automação de testes que expõem o quanto o código desse back-end é frágil, apesar de ser aderente a várias práticas da moda.
O mesmo se aplica a comparar front-end com back-end, SRE com DBA, Agilista com QA e por aí vai. São comparações esdrúxulas e inúteis, pois os objetos de comparação são diferentes.
Portanto, ao invés de julgar o trabalho do amiguinho, sugiro para quem profere isso entender melhor o trabalho alheio antes de julgar.
Mito 23: É só um botão.
Depende.
As vezes é. Mas é mais provável que não seja. Logo, se você profere isso e não é do time técnico, por favor, não tente dar prazo ou preço no trabalho alheio. Se você sabe que é só um botão, vai lá e codifique você ao invés de dar pitaco na expertise alheia.
Vamos a um caso hipotético: você está doente e precisa operar. Você nunca estudou medicina e vai dizer ao seu cirurgião como ele vai te operar? Provavelmente, você vai deixar ele fazer o trabalho dele, dado que ele estudou e é a pessoa mais indicada para isso, certo?
Só porque algúem fez uma macro no Excel ou consegue entender os fluxos sistêmicos em algumas discussões, não a torna obrigatoriamente uma pessoa qualificada para estimar o trabalho de desenvolvimento, portanto, quem profere isso tem que parar de achar que sabe mais do que o time técnico.
Agora, se quem profere isso não confia no time técnico, ai é outro problema multifacetado que não irei abordar agora.
Mito 24: É só botar um if.
Idem ao de cima.
Mito 25: Temos uma API.
Depende.
Geralmente essa frase aparece em contextos de integração, quando um determinado time vai precisar consumir APIs de outras equipes. O que acaba acontecendo é que a API mencionada muitas vezes é um conjunto desordenado de rotas, sem controle de acessos, sem controle de breaking changes de contratos ou até mesmo algo sem um swagger decente (ou pior, algo em SOAP).
Se você não tem um conjunto de APIs feitas de forma profissional, geralmente com uma visão de plataforma, acredito que ler esse texto pode ajudar a entender melhor porque é importante pensar em sistemas como uma plataforma.
Raríssimas vezes a API mencionada estará aderente aos requisitos de performance, segurança ou estabilidade necessários para aquela integração funcionar.
Mito 26: Para acelerar um projeto, basta adicionar mais pessoas desenvolvedoras.
Falso.
Essa é tão errada que existe até a Lei de Brooks já amplamente documentada e discutida na indústria de software desde a década de 70.
Porém, acredito que valha um breve comentário da natureza do trabalho de uma pessoa desenvolvedora para explicar essa lei.
Ao contrário de trabalho operacional e/ou repetitivo, o grande ganho de produtividade em software está na capacidade de síntese e saber qual botão apertar (no sentido de saber mexer e onde mexer nos sistemas) de uma pessoa desenvolvedora. Ao adicionar uma pessoa nova no time, o mais experiente precisa parar por um tempo para ensinar o básico do funcionamento daquele sistema para os novos entrantes. Esse processo leva a uma diminuição significativa na performance de ambos e é algo que não dá para escapar, por melhor que a documentação esteja, por exemplo. Caso a pessoa experiente não pare o que tá fazendo e deixe o novo integrante no modo "se vira", vai demorar muito para que ele/ela consiga aprender sozinho(a) a fazer as coisas acontecerem.
Ou seja, é melhor reduzir o escopo ou abrir mão da qualidade ao invés de adicionar mais pessoas para acelerar a entrega de um projeto.
Mito 27: Agilidade é a solução para todos os times.
Falso.
Apesar de parecer que sim (e para mim, por muito tempo foi), hoje em dia eu não acredito mais nisso.
O argumento principal aqui é: Tipos de problemas diferentes exigem métodos de resolução diferentes. Para discutir tal ponto, sugiro ler esse texto meu sobre o framework Cynefin — que é uma forma de categorizar problemas por tipos, de acordo com suas características, o que faz toda a diferença em como resolvê-los. Ou seja, um problema pode ser uma bucha, uma treta ou um pepino, cada qual com seu tamanho.
Portanto, existem cenários que valha a pena continuar usando waterfall — apesar de raros — por incrível que pareça.
Só não vale citar essa passagem como desculpa para ser aquelas pessoas que atrapalham transformações digitais fazendo scrumfall, ok?
Mas aqui eu deixo um apelo: para produtos digitais, o correto é sim usar agilidade!
Mito 28: É possível obter a mesma produtividade de uma pessoa desenvolvedora experiente com múltiplas inexperientes.
Falso.
Desenvolver software é um trabalho intelectual, não repetitivo e empírico por natureza. Devido a isso, acaba sendo muito dependente das habilidades e experiência de pessoas específicas. Não é possível substituir uma pessoa experiente, com conhecimento de domínio e um bom conhecimento técnico por outras inexperientes sem impacto. Isso não acontece nem em áreas operacionais (como logística), dado que já chegou até mim relatos de líderes dessas áreas que me afirmaram que há sim diferenças brutais de produtividade entre pessoas, mesmo em um trabalho tido como repetitivo e de fácil execução.
O que acaba acontecendo é um golpe muito comum no mercado de tech: algumas consultorias vendem profissionais como sêniores que na verdade são juniores. O resultado possível é o esperado: desastre total na condução daquele projeto. O irônico é que isso é tão fácil de pegar que ainda não acredito que tenha consultoria que faça isso (basta o gestor entrevistar tecnicamente os terceiros e não absorver profissionais abaixo do nível esperado).
Aqui eu tenho dois pontos: se você passou por isso em alguma empresa, saiba que você tem um gestor no mínimo preguiçoso e se nem isso o gestor técnico faz, mereceu ser enganado mesmo.
Mito 29: Existem desenvolvedores que são 10x mais produtivos que outros.
Não conclusivo.
Eu vou resumir aqui os capítulos 5 e 6 do livro Leprechauns of Software Engineering (que basicamente analisa como folclore se torna fatos ao longo do tempo na engenharia de software). Se você quer as referências e ir a fundo, sugiro que leia os capítulos mencionados por si mesmo (no livro há menção aos artigos originais que geraram a confusão). Mas, para os mais apressados, vou resumir.
Basicamente, esse mito surge de uma coisa muita comum na academia: a citação como forma de validar a veracidade de uma afirmação. Algumas das alegações nos artigos originais, inclusive, não possuem nenhuma evidência que sustentem que exista essa diferença de produtividade. Além disso, boa parte dos estudos é bastante antigo (antes de 1975), e tem falhas sérias de metodologia, como comparar estudantes com profissionais e mensurar produtividade em linhas de código ou em técnicas de DEBUG. Vou citar aqui a conclusão do capítulo 6, que até questiona se estamos de fato fazendo as perguntas certas:
The empirical data is in general quite old, most if not all of it predating widespread use of the Internet — which we can safely expect to have wrought major changes in programming practice. None of the studies address the question of construct validity, that is, how meaningful it is to speak of an individual programmer’s productivity, and if it is meaningful, whether the experimental measurements line up adequately with that meaning. […] The 10x claim is “not even wrong”, and the question of “how variable is individual programmer productivity” should be dissolved rather than answered.
Acredito que valha o meu 2 centavos empírico aqui: apesar de eu ter trabalhado com programadores realmente muito bons, que pareciam estar alguns níveis acima da média, eu não encontrei formas objetivas e cientificamente válidas de provar se a minha percepção estava de fato correta. Portanto, minha percepção não vale de nada comparado ao método científico para resolver essa questão.
Se você trabalha na academia e conhece formas cientificamente aceitas de se medir a produtividade de pessoas desenvolvedoras, me mande uma mensagem, eu adoraria saber mais sobre isso.
Mito 30: Primeiro entregamos o MVP, depois evoluímos.
Falso.
O erro aqui está no entendimento do que é um MVP, acredito eu.
MVP não se evolui. O próprio conceito do mesmo é ser algo simples e barato de validar uma ideia de negócio. O intuito é economizar dinheiro de desenvolvimento de software (que geralmente é maior custo no evolução de um produto), com validações simples e preferencialmente, sem código.
Se um protótipo está sendo evoluído, ele é um produto mal-feito que surgiu as pressas e só. MVP e protótipos tem que serem feitos para serem jogados fora! Senão perde todo o sentido em ser "barato".
Porém, é mais fácil para uma empresa falar "evoluímos um MVP", do que a verdade, que se resume em: não sabemos o estamos fazendo, então vai no extreme go-horse e damos um nome bonito aderente as buzzwords depois.
Você pode até argumentar que é suicídio para uma startup early-stage começar o desenvolvimento de um novo produto de software após aquele monólito maroto ter subido e dado dinheiro em 1 mês. Novamente: a ideia tinha que ter sido validada de formas mais simples antes de começar a parte do código. Para melhor entendimento, deixo a recomendação desse podcast aqui.
Espero que esse texto tenha sido útil para você de alguma forma.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
