Publicado originalmente no meu blog em 2011 (infelizmente, este conteúdo não está mais disponível). Também publiquei no Linkedin.

A publicação de hoje é uma espécie de provocação. Muitas vezes vejo discussões acaloradas sobre o que são boas práticas. Aqui, apresento minha visão sobre esse tema.

Relação entre boas práticas e eficácia

Para mim, boas práticas são aquelas que garantem a entrega do valor certo para o cliente com o menor custo para a empresa. Chamo essa relação de eficácia.

Logo,

Boas práticas sempre maximizam a eficácia.

Um desdobramento lógico é:

Boas práticas sempre colaboram para a entrega do valor adequado ao cliente e/ou para a redução do custo total de propriedade.

Vamos entender um pouco melhor o que quero dizer.

Valor correto para o cliente

Muitas vezes, quando desenvolvemos software, temos por hábito querer “superar” as expectativas do cliente. Isso gera encantamento. Na medida certa, isso não é errado.

O problema é que, muitas vezes (quase sempre), o cliente não vai estar disposto a pagar mais por esse encantamento. Quando incluímos features que não são percebidas estamos incluindo, na verdade, apenas custo direto de desenvolvimento.

Toda feature não percebida pelo cliente é apenas custo.

O melhor software é aquele que atende o cliente e entrega um pouco mais do que o necessário (suficiente para fidelizar).

Se o software (qualquer produto, na verdade) entregar muito mais do que o esperado, precisará reverter esse incremento também no seu preço. O problema é que nem sempre isso é possível. Seja porque o cliente não valoriza, seja porque ele não tem condições de pagar.

Por favor, perceba que

o valor correto nunca será nada abaixo de um software fazendo aquilo que se dedica, sem erros nem inconsistências.

Menor custo total propriedade

Software deveria ser projetado para reduzir seu custo total de propriedade. No caso de software, podemos assumir que o custo pode ser dividido entre o investimento inicial (custo para desenvolver) e o custo para manter (manutenção).

Não é raro que o custo de manutenção seja bem maior do que o custo de desenvolvimento. O motivo mais comum para isso é a dificuldade para entender o código existente. Depois, temos também que computar os custos da modificação em si, além dos testes necessários para garantir que esta alteração esteja conforme. Por fim, há os custos de atualizar a base instalada.

Vamos, por um momento, entender a composição do custo para manutenção.

Uma abordagem antiga, porém infeliz para reduzir o custo de manutenção é tentar investir mais no custo inicial de desenvolvimento tentando eliminar ou reduzir a necessidade de manutenção. Considere que:

Tentativas de antecipar “necessidades” futuras geralmente aumentam ainda mais a complexidade de implantar modificações que não foram planejadas.

Temos que considerar, além de tudo, que investir em demasia no desenvolvimento inicial contraria um importante princípio econômico: Dinheiro disponível hoje vale mais que o dinheiro disponível amanhã;

Antecipar um investimento implica em desperdício de dinheiro

Por outro lado, em projetos com certeza de manutenção futura, qualquer esforço para reduzir os custos para compreensão, modificação, teste e distribuição representam em um aumento de eficácia.

Questionando as boas práticas

Como desenvolvedores, temos pouca ou nenhuma condição de aumentar o “valor correto para o cliente”. Isso nasce de uma necessidade de negócio dele, não de nossas inspirações! São raros os casos onde conseguimos delinear claramente necessidades que um cliente nem sabia que possui e, além disso, está disposto a pagar para que sejam resolvidas. Esse é um tema de marketing e P&D, não de desenvolvimento.

Para colaborar com a eficácia, nosso foco, enquanto desenvolvedores, deve estar na certeza de que estamos entregando pouco mais que aquilo que o cliente espera.

Além disso, quanto antes entregarmos aquilo que ele mais valoriza, mais cedo poderá computar o ROI. Logo, maior será a eficácia. Assim,

Se possível, devemos entregar o mais importante antes.

Quanto ao custo total de propriedade, temos que considerar o cenário em que estamos desenvolvendo. Considere, por exemplo, que estejamos fazendo um software que não terá manutenção futura. Considere um hot-site, ou um aplicativo para computar dados de uma pesquisa, por exemplo. Nesses casos, qualquer investimento em melhorar a manutenabilidade representam apenas incremento no custo. Logo, não são boas práticas para aquele projeto.

Uma prática só pode ser considerada boa quando analisada no contexto do projeto em que está sendo aplicada.

Por isso que:

Otimização prematura é raiz de todo mal (Donald Knuth)

Concluíndo e respondendo a pergunta do título

Para uma prática ser considerada boa, precisa colaborar com a eficácia. Seja através da maior assertividade nas entregas (entregar aquilo que resolve o problema que o cliente gostaria de resolver). Seja através da redução do custo total da propriedade – reduzindo o custo de manutenção (quando existir) ou reduzindo o custo de desenvolvimento (quando não inviabilizar manutenção futura necessária).

Você, concorda com isso?