Como tomar boas decisões com relação a qualidade de software.

“Until we find the one true solution that works in all contexts, you’ll need to think” [Simon Brown]

Photo: Ryan McGuire. Creative Commons Zero

É possível que você já tenha tido que trabalhar em uma empresa sem ter a oportunidade de escrever testes do seu código. Isso pode ter acontecido por falta de conhecimento da sua parte, por prazos apertados ou mesmo falta de interesse de outras pessoas da sua organização, que viam essa (e outras) práticas apenas como preciosismo da sua parte.

Eu mesmo já tive a oportunidade de trabalhar sob essas condições por muitas vezes, do lado de quem defende e do lado de quem não se importa. E realmente é uma oportunidade pois ensina o outro lado da moeda. Aquele lado escuro, onde o futuro é incerto e o medo é constante.

Qualidade de software não é uma ciência exata e depende de percepção mais do que de regras. Um software pode sim ser de qualidade com baixa cobertura de testes e vice versa. É uma questão de trade-offs. Se você cobrir cada caminho com testes e o projeto ultrapassar o deadline estabelecido por uma restrição do mercado, ele pode não atender ao seu propósito e ter sido apenas um grande desperdício.

Alem dos testes, diversos pontos exigem decisões difíceis, e o principal responsável por essas decisões não é o CTO da sua organização. Se você veste o chapéu de negócios uma de suas responsabilidades é traduzir seu entendimento do mercado e das relações entre as diferentes áreas da empresa em restrições de projeto. Já com o chapéu técnico, você é responsável por entender muito bem essas restrições (e dependendo do caso questioná-las) e tomar suas decisões baseadas nelas.

Saia dos limites das restrições clássicas qualidade, tempo ou custo. Todas as restrições provavelmente serão reduzidas a essas em algum momento, mas você deve ser um pouco mais qualitativo nas suas descrições. Se você escolher que seu projeto tem fortes restrições de tempo e custo quer dizer que não preciso entregar qualidade nenhuma? Provavelmente isso não é verdade.

É importante observar que restrições são naturais a todos os projetos e não precisam ser vistas de forma negativa. Um projeto sem qualquer restrição raramente oferece qualquer tipo de desafio, por exemplo, e como grande parte das oportunidades fáceis da vida, dificilmente trará uma grande recompensa. Restrições são a base das decisões. Se você decide por um caminho, naturalmente criou uma restrição de não decidir pelo outro.

Além de profissional, somos todos seres humanos e portanto sujeito as emoções mais diversas e é muito importante levar isso em consideração. Como desenvolvedor eu tenho uma pré disposição a criar coisas mais complexas do que necessário, pois normalmente são mais interessantes. Tenho também o interesse em aprender coisas novas e isso pode influenciar nas minhas escolhas com relação as tecnologias que irei trabalhar.

Como as emoções não são a ferramenta mais confiável para se tomar decisões, é importante possuir um modelo para tomada de decisões. Em muitas empresas, com o intuito de reduzir falhas humanas, processos são instaurados. Uma ferramenta bastante simples pode aumentar drasticamente a qualidade de serviço de uma empresa. Veja uma parte do checklist que um piloto deve seguir antes de levantar vôo por exemplo.

Qualquer item esquecido pode levar a uma catástrofe.

No desenvolvimento de software, com excessão de alguns erros críticos, poucas decisões são irreversíveis, mas a soma de muitas decisões erradas podem sim levar uma aplicação ao colapso. Principalmente se tratando de decisões de arquitetura e qualidade. Se você não limpar o lixo com frequência e se manter sempre em evolução, o caos irá imperar.

Algumas perguntas que você pode fazer antes de tomar qualquer decisão no seu projeto podem ser as seguintes:

• Esse ajuste facilita o entendimento do código do projeto?
• Aumenta a performance da sua aplicação?
• Diminui o custo de infraestrutura?
• Reduz a quantidade de defeitos?
• Facilita o onboarding de novos membros na sua equipe? (pode ser relacionado ao primeiro item)
• Reduz o overhead de comunicação com a sua equipe? (melhoria nos nomes de classes ou métodos por exemplo).
• Aumenta a velocidade da equipe?
• Facilita o monitoramento da sua aplicação?
• E principalmente, qual são os efeitos colaterais que essa mudança gera?

Em contra partida, esses são alguns dos pensamentos que podem resultar em uma mudança, mas jamais devem ser importantes na decisão por uma

• Te deixa feliz.
• É uma tecnologia nova no mercado e você quer ver como funciona.
• Você leu no Medium ou em outro lugar que é muito importante fazer.
• Você sonhou com essa arquitetura.
• Não te deixaram fazer na sua empresa anterior.
• Você quer provar um ponto para alguém.

Não aceite uma proposta de mudança quando acompanhada do argumento “alguém disse que isso é importante”. Se você não conseguir explicar de forma racional qual é o objetivo da mudança, tente buscar uma linha prática. Eu mesmo tenho dificuldades diversas vezes em expressar em palavras o que eu quero fazer. Em casos como esses é importante uma cultura de experimentação, onde uma nova idéia pode ser tentada, e caso bem sucedida, pode fornecer os argumentos que faltam para levar essa idéia para o mundo real. Afinal muitas decisões são complexas demais para serem tomadas apenas conversando na frente do quadro branco e rabiscando diagramas.

Normalmente esse simples exercício mostra falhas na sua linha de pensamento. Se esse for o caso, a mesma cultura que abre espaço para a experimentação deve abrir espaço para compartilhar as falhas encontradas pelo caminho. Seu objetivo precisa estar alinhado com o da sua equipe e ser principalmente o de gerar valor ao seu cliente. Se for esse o caso, é provavel que outro membro da sua equipe ajude a preencher essas lacunas e criar uma solução ainda melhor do que a original. O segredo para alcançar excelência reside na sua capacidade diária em valorizar o interesse coletivo tanto ou mais do que você valoriza o seu próprio (e o mesmo vale fora do contexto profissional, inclusive).