Quando o excesso de entregas de features é algo ruim?
Olá!
Hoje eu gostaria de abordar um assunto relacionado a entrega dos times de tecnologia e fornecer argumentos para um problema que em um primeiro momento, parece ser algo contra-intuitivo: porque entregar muito sem critério é uma armadilha.
Para tal, vamos de fato discutir o que é produtividade e nos aprofundar nas dinâmicas de evolução de software (também conhecida como Leis de Lehman).
Vamos começar com a definição de produtividade:
A produtividade é basicamente definida como a relação entre a produção e os factores de produção utilizados. A produção é definida como os bens produzidos(quantidade de produtos produzidos). Os fatores de produção são definidos como sejam pessoas, máquinas, materiais e outros. Quanto maior for a relação entre a quantidade produzida por fatores utilizados maior é a produtividade.
Pegando carona nesse conceito advindo da economia, podemos deduzir em software que a fórmula da produtividade pode ser definida como:
Produtividade = Desempenho / Empenho.
Com isso dito, a primeira lição que fica daqui é: quanto menor o esforço (em tempo) para se fazer algo, melhor. Se você pensou em um paralelo com o conceito de eficiência, permita-me esclarecer: produtividade está relacionada ao tempo que leva para que algo seja concluído. Eficiência, por sua vez, diz respeito aos recursos que aquilo consumiu para ser entregue. Se você vai considerar tempo como um recurso na conta, fica a seu critério, porém, o intuito desse texto é ser menos criterioso com isso e simplesmente traçar um ponto comum de entendimento.
Vamos falar de software agora.
Eu costumo dizer que boa parte dos problemas dos times de tecnologia já foram resolvidos na década de 70, 80 e 90, porém, os profissionais da área tem uma relação não saudável com o futuro que gera essa obsessão pela "próxima grande coisa" que vai resolver todos os problemas. Com isso, esquecemos de olhar para trás e aprender com pessoas que vieram antes de nós e deram a resposta para muitos problemas que temos, mas — talvez devido a como a mente humana funciona — tendemos a enxergar algum problema nosso como algo único e que somente nós passamos por isso, ao invés de olhar para fora do nosso mundo e pedir ajuda (seja de pessoas experientes ou da literatura científica).
Isso vale um estudo científico, inclusive: porque a tecnologia é uma área que se recusa a aprender com o passado e repete sempre os mesmos erros de forma cíclica, esperando por uma nova grande tecnologia que vai resolver todos os problemas?
Fica aí a reflexão e a dica de TCC para quem estiver disposto.
Mas, voltando ao texto.
Entre as décadas de 70 e 90, dois cientistas da computação, chamados Meir Lehman e László Bélády formularam algumas máximas sobre engenharia de software que ficaram conhecidas como as Leis de Lehman. São 8 afirmações que explicam quase tudo que passamos de problemas em engenharia de software, e que — olha só que inusitado — nossa indústria parece ter esquecido que essas leis existem.
As leis são resumidas na seguinte imagem:
Vamos passar por algumas dessas leis e entender o que isso impacta na produtividade dos times.
Lei n˚1 — Mudança contínua. Pode ser resumida em algo como: sistemas que não evoluem tendem a se tornar inúteis ao longo do tempo.
Lei n˚2 — Complexidade crescente: aqui está a raiz de muitos problemas. Conforme o software cresce, a complexidade interna (sentida muitas vezes somente na camada de código) tende a aumentar. Com base nisso, é necessário alocação consciente de pessoas e esforço para que essa complexidade seja administrada (eliminá-la é impossível).
As seguintes (evolução do programa, estabilidade organizacional e conservação da familiaridade, respectivamente), deixam claro que o software tende a ter um comportamento relativamente previsível e que, não importa a quantidade de pessoas empregadas no desenvolvimento do mesmo, não há muita diferença no resultado gerado. Em outros termos, essa lei conversa MUITO com a lei de Brooks, que diz que: "adicionar mais pessoas a um projeto atrasado o atrasa mais ainda". Detalhe: essa observação também é da década de 1970, pois o livro em que ela aparece originalmente (The Mythical Man-Month), é de 1975. Além dessa observação sagaz de Fred Brooks, essas observações de Lehman conversam bastante com a lei dos rendimentos decrescentes da Economia.
Lei n˚6 — Crescimento contínuo: Se um software não continuar aumentando suas funcionalidades, tende a perder a relevância para o usuário final ao longo do tempo.
Lei n˚7 — Qualidade em declínio: O caos típico da gestão das dependências. Invariavelmente o sistema operacional, software de orquestração de containers, biblioteca ou a versão de algum framework necessitará ser atualizada para que o sistema continue funcionando. Quem nunca teve que resolver um problema de um sistema porque alguém atualizou algo aparentemente não relacionado?
Lei n˚8 — Sistema de feedback: Essa foi a que mais me surpreendeu. Pois eu achava que as abordagens de fail-fast, agilidade e coleta de feedbacks de forma data-informed era algo novo, mas, no final, o embrião dessas práticas já estava documentada aqui. Apesar de um pouco mais nova que as anteriores (as leis 7 e 8 são de 1996), é algo que pode ser considerado velho na perspectiva atual.
Contextualização efetuada, agora vamos ao argumento principal desse texto, que acaba até sendo contra-intuitivo, na minha opinião.
Dado que o software tende a mudar o tempo todo (conforme diz a primeira lei) e a complexidade aumenta sem parar conforme isso acontece (segunda lei), a conclusão possível é que: não importa o quanto uma equipe produza, caso não ocorra um esforço consciente no tratamento de dívidas técnicas e eventuais melhorias de código, a tendência natural de um software é caminhar para uma entropia significativa que torna o software inutilizável (ou de manutenção inviável) de forma praticamente inevitável:
Ou seja, quanto mais produtiva uma equipe é, mais rápido ela torna o software improdutivo caso algo não seja feito para mitigar as consequências do aumento da complexidade.
Nos termos da fórmula da produtividade mencionado no começo: baixa qualidade de software faz subir o empenho necessário para se atingir determinado resultado, até que o custo de qualquer alteração se torna proibitivo e o software se torna, em ultima instância, inútil (pois sua evolução é inviável).
Portanto, se você é uma pessoa desenvolvedora que só entrega qualquer coisa e não pensa em nenhuma tipo de melhoria de manutenção, você é parte do problema. Se você é de produto e cobra produtividade do seu time a qualquer custo e não quer saber de "perder tempo” ouvindo a "ladainha” de escrever testes ou os apelos por tempo na sprint para melhoria no código, você está contribuindo para um desperdício de dinheiro que pode levar a quebra da empresa no longo prazo, pois o principal software da empresa pode estar tão podre por dentro que em algum momento pode gerar a seguinte reação dos stakeholders:
Assim como na vida, a mentalidade imediatista dificilmente tem um retorno positivo, em software — quem diria — também não.
Para finalizar, fica o apelo: como software é intangível, a baixa qualidade de código não pode ser vista de forma tão explicita quanto uma casa com rachaduras ou um produto físico com a embalagem danificada, portanto, se o time de tecnologia está dizendo que está ruim e pedindo tempo para melhorias, é porque estamos tentando evitar que o código exploda e a empresa imploda, só isso.
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
