Quanto custa um bug de código?
Relação entre gestão e bugs de código e qual o impacto que esses causam na gestão como um todo
Coloque-se na posição de um gestor de tecnologia ou líder de equipe, podendo ser de qualquer área que envolva código (ciência de dados ou desenvolvimento de software são alguns exemplos) em qualquer linguagem. Eu quero quebrar um tabu com este artigo, caso você ocupe a posição mencionada!
Todos nós sabemos que qualquer área envolve prazos e entregas. Isso é um fato! Quando falamos de códigos e softwares há um componente importante, mas pouco falado, que tem um impacto tremendo na gestão: débito técnico.
Antes de definir débito técnico, quero detalhar a diferença entre código e software. Um código é um agrupamento de comandos que fazem algo e resolvem algum problema específico; simples assim. Já um software é um conjunto de códigos que seguem determinados padrões com o objetivo de escalá-los. Neste ponto mora o perigo!
Quando você quer escalar um código (solução) e, colocando-se na posição de um gerente, deseja que sua equipe escale essa solução para outras áreas, setores, marcas, produtos, unidades, ou o que quer que seja, obrigatoriamente você precisa transformar código em software! E quando eu falo em escalar, envolvo até a inserção de novos colaboradores no mesmo projeto! Caso contrário, você e toda sua equipe cairá em débito técnico profundo.
Mas o que é débito técnico, afinal de contas? Segundo uma tradução livre do Wikipedia:
Débito técnico (também conhecido como débito de design ou débito de código, mas também pode estar relacionado a outros esforços técnicos) é um conceito no desenvolvimento de software que reflete o custo implícito de retrabalho adicional causado pela escolha de uma solução fácil (limitada) em vez de usar uma abordagem melhor que levaria mais tempo.
Em palavras mais simples, é quando você gasta mais tempo para resolver um problema (bug) ou fazer modificações no código por conta de uma estrutura inicial mal pensada. E tempo de desenvolvimento é custo. E quando mexe no bolso, já sabe, certo?
Quebra de tabu!
Vamos quebrar um tabu, caro leitor que se posiciona como um gestor. Para isso, responda a seguinte pergunta:
Qual destes dois códigos abaixo você escolheria que sua equipe desenvolvesse?
1. Um código que funciona, no qual é impossível fazer quaisquer modificações;
2. Um código que não funciona, porém é rápido e fácil de se fazer qualquer modificação para que ele funcione.
Bom, você, como a maioria das pessoas, deve ter respondido a opção 1. Quem vai querer um código que não funciona? Que pergunta imbecil!
Pois bem! Você só se esqueceu de algo: flexibilidade do negócio. As regras de negócio mudam a todo momento, certo? E, para opção 1, sendo impossível fazer qualquer alteração, o código torna-se inútil mediante qualquer alteração de regras ou novas solicitações da área de negócio! Concorda?
A opção 2, embora não funcione, se adapta bem à flexibilidade do negócio, sendo possível realizar quaisquer alterações e correções de forma rápida para atender as demandas da área. Ou seja, o código, mesmo sem funcionar, ainda é útil.
Assim, aquela história de “só colocar para rodar” é muito mais perigosa do você pensa!
Impactos que vão além do que você imagina…
Bom, além do alto custo para manter o software após ele ter sido entregue, conforme escrito acima, temos outros impactos implícitos quando falamos de códigos mal estruturados. Alguns deles são:
- Rotatividade de colaboradores: trabalhar com código mal estruturado é extremamente ingrato, e garanto que nenhum colaborador que tenha o conhecimento de que é possível fazer melhor ficará no projeto ou na empresa.
- Impossibilidade de planejamento de atividades: quando trabalha-se com códigos mal estruturados é praticamente impossível prever qualquer prazo de correção ou melhoria, sem contar o impacto desta indefinição de prazo nas outras atividades ou projetos.
- Elevação do nível de stress: sem ter como planejar as atividades de forma coerente, os desenvolvedores que atuam com estes códigos tem que trabalhar em excesso para “apagar fogo”, sem necessariamente estar produzindo algo útil para empresa e para si próprio (aprendizado, carreira etc.).
- Quebra de expectativa: o negócio, que não conhece do código e nem do débito técnico, cria uma expectativa perante a entrega da solicitação e, quando os prazos não são atendidos pela impossibilidade de planejamento, frustações são geradas em todos os níveis.
Quando eu falo de códigos ruins, não tem absolutamente nada relacionado com a capacidade técnica de quem está lidando com eles. Pelo contrário, existe um ponto a ser melhorado ao se desenvolver as pessoas que escreveram aquele código. Não adianta contratar um batalhão de desenvolvedores sêniores para trabalhar em códigos ruins. Isso aumenta mais ainda o custo do débito técnico!
Convencido? Ainda não? Vamos a mais argumentos…
No livro Como ser um programador melhor (Pete Goodliffe), página 102, o autor faz o seguinte comentário:
Uma preocupação econômica
Quanto tempo você acha que é gasto em debugging? […]
Impressionantes 312 bilhões de dólares por ano são gastos com custos de programadores depurando seus softwares. Para pôr em perspectiva, isso corresponde ao dobro da ajuda financeira feita em toda zona do euro desde 2008 [publicação do livro em 2015]! Esse valor altíssimo, porém realista, é proveniente de pesquisas feitas pela Judge Business School da Universidade de Cambridge.
E agora? Acho que lhe convenci, não? Trata-se de uma preocupação econômica global, segundo o autor!
Possíveis soluções
Visto todos impactos em nível gerencial deste tipo de código, vamos às possíveis soluções.
Antes de iniciar o desenvolvimento de qualquer solução, pense na possibilidade de ela ser escalável (para outras marcas, unidades etc.). Se a resposta for sim, então contrate ou envolva, desde o início, pessoas que conheçam de desenvolvimento e arquitetura de software. As boas práticas destes profissionais serão indispensáveis para reduzir drasticamente o nível de débito técnico ao final.
E caso você não saiba da possibilidade de escalonamento, melhor já envolver arquitetura no começo, pelo custo benefício de uma decisão posterior. O único momento em que você opta por não desenvolver com arquitetura é na certeza de não escalar o produto (lembre-se de que escalar vale também para inserção de outros colaboradores no mesmo projeto!).
Caso não seja possível contratar desenvolvedores ou arquitetos de softwares, que tal treinar os seus colaboradores? Imagine só você, caso leitor/gestor, ter na sua equipe um(a) cientista de dados com conhecimento em desenvolvimento e arquitetura de software?
Conclusão
Bom, espero ter ilustrado neste post o porquê de a gerência se preocupar com a qualidade do código produzido por suas equipes, trazendo os impactos nas empresas de uma má estrutura de código e algumas opiniões/sugestões de como resolvê-la. Implementar arquitetura de software não é algo simples, mas faz-se necessário em alguns momentos cruciais.
Referências e inspirações
Meus contatos
- LinkedIn: https://www.linkedin.com/in/henriqueajnb/