Anotações sobre lead time x complexidade de código

Por que você, como agilista ou pessoa de produto, deve prestar atenção ao codebase?

Bruno Eugênio
May 19 · 4 min read
Photo by Linh Ha on Unsplash

Cenário hoje cada vez mais comum: em suas análises, o tempo de entrega (seja ele o customer time ou apenas a partir do ponto de compromisso do time com a demanda) está subindo, pouco a pouco, mesmo em ambientes estáveis em termos de fluxo? Então, já se perguntou sobre como anda a sua base de código? E por que você deveria ter uma atenção especial para esse item e quais são os impactos dele no lead time? Eu já me perguntei e faço aqui algumas anotações sobre o assunto.

Pontos chaves: complexidade e evolução. Um software tende a evoluir, com novas features, novos domínios, integrações… e isso precisa ser feito de uma maneira coesa, planejada. Se uma arquitetura for acoplada demais, a tendência é que as evoluções sejam mais e mais complexas. Evoluir software requer tempo e é um trabalho sem fim: sempre existe um jeito mais efetivo, seja uma técnica ou ferramenta que pode ajudar o software a evoluir de maneira que se tenha um baixo acoplamento, tornando o processo de evolução mais fácil. Esse é um dos pontos chaves da agilidade: responder a mudanças.

Primeiro: pessoas de produto hoje tendem a potencializar decisões que tragam valor tangível, e isso geralmente é traduzido em “novas features”. Times que colocam muitas features no ar mas que o fazem a custo de uma arquitetura acoplada estão criando mais complexidade — e isso é um dos ofensores do aumento do tempo de produção de uma feature: mais complexidade = mais tempo de desenvolvimento, deploys, etc. Logo: pessoas de produto devem se preocupar, e muito, em saber como está a saúde do código e o time deve ter um equilíbrio sobre isso. Itens técnicos podem não gerar valor visível para o usuário final, mas são catalizadores para um customer time efetivo.

Segundo: times precisam trabalhar para diminuir a complexidade dos seus sistemas, o tempo inteiro. Sem esse esforço, corremos o risco de tornar o software irrelevante a ponto de pensar em substituições inteiras de sistemas que ficaram complexos demais para evoluir. Aqui vale observar algumas das Leis de Lehman, que começaram a ser descritas em 1974:

1. “Mudança Contínua” : um sistema deve ser continuamente adaptado ou se torna progressivamente menos satisfatório;
2. “Aumento de Complexidade”: conforme um sistema evolui, sua complexidade aumenta, a menos que seja feito um trabalho para mantê-la ou reduzi-la;
3. “Queda de Qualidade”: a qualidade de um sistema parecerá estar em declínio, a menos que seja rigorosamente mantida e adaptada às mudanças do ambiente operacional.

Então, com base nisso podemos dizer que existe um trabalho que deve ser constante para: suportar as mudanças exigidas para manter o produto relevante, com uma qualidade satisfatória e que isso REQUER um trabalho no qual a complexidade seja combatida ou mantida em níveis aceitáveis. Um time sem o domínio total do código e de como proceder com melhorias nele é um ofensor do fluxo de trabalho, perigoso e normalmente negligenciado nos tempos atuais (sim, agile coaches/agilistas/service delivery managers que não sabem na prática desenvolvimento, estou olhando fixamente para vocês).

“Se você pede permissão para fazer um refactoring, existe algo errado no seu time.”

Terceiro: evolução e não revolução. Sim, arquiteturas precisam ser desenhadas para permitir evoluções de maneira coesa. E arquiteturas não podem ser pensadas como grandes peças de blocos de montar nas mãos de uma criança: “o bloco que couber, eu encaixo, não importa a cor”. Permitir evoluções constantes, incrementais e guiadas é o grande foco de um desenho de arquiteturas evolucionárias e vai de encontro com o combate à complexidade que precisa ser constante, segundo Lehman. Sem a evolução, existe uma grande chance de o código se tornar mais complexo com soluções não estruturadas para implementação de novas features. Por isso, devemos não ser revolucionários quando tratamos de base de código, pois o preço que se paga é o software se tornar obsoleto devido à complexidade da codebase.

Então, observando as Leis de Lehman, podemos dizer que é papel de um time de produto não só olhar para o valor “entregue” para o cliente final, mas sim encontrar um equilíbrio no qual um lead time seja cada vez mais adequado às necessidades de negócio por meio de uma base de código que seja relevante do ponto de vista técnico, que o time tenha em mente o controle da complexidade crescente no seu dia a dia e que a qualidade seja algo prioritário nas decisões técnicas deste time.

Aos agilistas (pessoal de agilidade, product managers…) que queiram olhar apenas o número “lead time” e “customer time” sem levar em consideração essa relação entre complexidade de código e tempos de entrega: perguntem aos seus times como a complexidade vem sendo tratada dentro da codebase.

Finalizando:
Sem engenharia robusta, não existe agilidade. Este deveria ser um ponto de partida para qualquer time de produto que mexa com software! Sem a confiança de que práticas como arquiteturas evolutivas, código limpo, documentação enxuta e métricas de engenharia habilitem os times a combater complexidade e a expandir domínios do software a ponto de mantê-lo relevante por mais tempo, é comum o lead time das entregas ser alto devido a N problemas de implementação que a complexidade de código traz, deixando todos com a sensação de que estamos “lentos” para entregar novas funcionalidades… e aí não adianta mexer em fluxos, fazer dinâmicas sem sentido ou retrospectivas.

E você, o que pensa sobre o assunto? Vamos conversar nos comentários! E se você quiser fazer parte de um time que vê agilidade não como um framework, mas como um jeito de pensar, dá uma olhada aqui e se candidate a alguma de nossas vagas. Vamos aprender juntos.

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade e excelentes práticas, para que o mercado brasileiro e latino-americano acompanhe a velocidade do mercado digital mundial.

Bruno Eugênio

Written by

Desenvolvedor de Software, Agilista e Líder de Capítulo @ Concrete

Concrete

Nós desenvolvemos produtos digitais com inovação, agilidade e excelentes práticas, para que o mercado brasileiro e latino-americano acompanhe a velocidade do mercado digital mundial.