Código é commodity

Sempre que ouço amigos programadores defenderem com unhas e dentes a idéia de que entregar um excelente código para seus clientes é o diferencial em suas empresas ou vidas autônomas, fico pensando: afinal… o que o cliente irá ganhar com linhas de programação?

Não sei se em algum momento da história da programação as seguintes estruturas fizeram muita diferença para o cliente:

if ("true".equals(s)) {
return "verdadeiro";
} else {
return "false";
}

ou então:

return ("true".equals(s)) ? "verdadeiro" : "false";

Bem, em qualquer entrevista de emprego o candidato que escreveu o segundo código teria melhores chances que o primeiro. Mas, ignorando possíveis diferenças de performance entre um código e outro, digamos que o código acima foi entregue para o cliente e está em produção. Qual a diferença para o cliente?

Código é commodity. E por favor, código bem feito é regra, não é diferencial.

Para qualquer cliente, diferencial é serviço. Todas outras áreas já sabem disso a tempos, mas aparentemente TI ainda insiste em focar o diferencial em linguagem, estilo e produto.

Se deixarmos de lado todos os importantíssimos serviços de comunicação, marketing, acompanhamento, suporte e tudo o mais que não corresponda exatamente a programação, nós programadores temos uma grande chance de entregar para o cliente um pouco além que código bem feito. Mesmo que você seja um programador autônomo, construindo um sistema para a padaria do seu cunhado, seu diferencial não deve ser o código em si. Existe muito mais valor agregado em um sistema se por exemplo:

Você entregar para seu cliente todos os testes unitários (claro, porquê VOCÊ FEZ testes unitários), e desta forma seu cliente tem a possibilidade de adicionar novas funcionalidades (ou modificar as funcionalidades existentes) e ter o sistema testado com um simples comando. Este é um diferencial.

Você entregar para seu cliente um script de construção (via make, via ant, via maven, via seja lá o que for) e desta forma seu cliente terá total capacidade de, primeiro, não ter que baixar uma IDE ou qualquer outra plataforma que seja para apenas ter o projeto compilado e segundo, a possibilidade de ter o sistema compilado, testado, empacotado e instalado com apenas um comando. Este é um diferencial.

Você entregar para seu cliente a base do controlador de versão do projeto, ou mesmo instalar um controlador de versão (CVS, SubVersion ou seja lá o que for) e a base correspondente ao projeto em seu cliente. Porque? Simplesmente porque está aí toda a história de vida do projeto e qualquer alteração deve ser feita com base no repositório, para que esteja documentada e tenha backup. Este é um diferencial.

Bem, digamos que na padaria do seu cunhado você não tem a menor chance de instalar o CVS e fazer com que seu cunhado entenda o que é um teste unitário – e pra falar a verdade, padarias executando controladores de versão me assustam um pouco. O que importa é que o serviço está sendo agregado ao software e este software agora tem muito mais valor. Um software que possa ser baixado do SubVersion, compilado, testado e instalado em um servidor remoto com apenas um comando, sem dúvida, vale muito mais do que um arquivo compactado contendo código fonte gerado em Visual Age, na máquina do último desenvolvedor a alterar o programa (programador que aliás já não trabalha na empresa há três meses).

Algumas pessoas podem argumentar que para o cliente não faz diferença. Bem, tudo isto faz a mesma diferença para seu cliente que o impacto sobre você quando compra shampoo de empresas que não usam animais como cobais, ou um alimento orgânico. O produto pode não mudar muito, mas seu valor sim!

Venda essa idéia ao seu cliente. Até seu cunhado vai sentir que está comprando um produto muito melhor.