Transpire Qualidade

Na biografia do Steve Jobs escrita pelo Walter Isaacson, tem um trecho em que o biografado fala sobre a influência que o pai dele deixou para ele na criação de produtos.

Ele conta que o pai gostava de fazer alguns trabalhos de marcenaria por passatempo e que um dia ele estava corrigindo um pequeno defeito na parte interna de um guarda-roupa que ele havia terminado de construir.

O Jobs vê o pai investindo um esforço enorme naquele conserto, pergunta:

— Pai, esse defeito está do lado de dentro… ninguém vai ver ou se importar com isso.

No que o pai dele responde algo como:

— Eu vi e por isso me importo.

O mito e as histórias criadas sobre o Steve Jobs mostram que ele sempre foi obsessivo pelos detalhes dos produtos que ele ajudou a criar até os mínimos detalhes internos das placas de circuito impresso.

Ele fazia isso porque ele entendia que o cuidado com as todos os aspectos do produto “transpiravam” para a qualidade geral dele. Ele também fazia isso porque era um tremendo babaca, mas isso a gente pode discutir em outro momento.

Seu código transpira

Várias vezes ao longo da minha carreira esbarrei com empresários, gestores, profissionais da área de produto e até mesmo desenvolvedores que diziam que a qualidade do código não era tão importante quanto o fato do produto estar “funcionando” e “entregando valor para o cliente”.

Será mesmo? Será que teu cliente sabe que aquele software porcaria que ele está usando poderia ser muito melhor, mais eficiente, mais estável, etc.?

Vamos ser honestos… vocês não estão de saco cheio de usar software lento e cheio de problemas? Vocês já tentaram comprar passagem aérea recentemente? Fazer um PIX no aplicativo do seu banco? Já tentaram resolver um problema com seu pedido em um site de e-commerce?

Sabe porque a nossa vida é miserável assim? Porque toda a engenharia de software está mais comprometida em desenvolver software do que refatorar software.

Afinal de contas, todos os “stakeholders” estão interessados em vender mais, faturar mais, aumentar o “market share” e se, por exemplo, aquele sisteminha de rastreamento de encomenda está mal-feito ou com uns bugs que afetam só 1% dos usuários pode deixar lá.

O custo de refatorar esse sistema para ele funcionar melhor seria muito alto e esses recursos seriam melhor empregados implementando um sistema de venda de publicidade para aumentar as vendas no site, não é mesmo? E aqueles 1% dos usuários afetados pelo problema já compraram, não é mesmo?

Para os “stakeholders” é melhor investir em uma funcionalidade que aumenta o faturamento em 5% imediato do que arrumar um sistema que afeta somente 1% do que já foi faturado.

Aquele pequeno “TODO”

E se você está pensando que estou falando apenas dos grandes sistemas e serviços, você está enganado. Estou falando daqueles “TODO” e “FIXME” espalhados pelo seu código.

Estou falando daquele backlog de consertos e refatorações que nunca é priorizado pelo time. Daquele código “vizinho” ao seu que está cheio de problemas e que não será melhorado porque está fora do escopo da sua tarefa.

Quando eu trabalhava diretamente com software livre e open-source era muito comum você encontrar melhorias para fazer no código conforme você ia desenvolvendo seu próprio código. Se você mandasse seu código sem melhorar o outro código vizinho provavelmente rejeitariam sua contribuição até que você fizesse tudo direito.

Fazer isso em uma empresa tem se mostrado quase impossível.