nós desenvolvedores, ou engenheiros de software, temos uma qualidade que pode ser perigosa e se tornar nossa inimiga em algumas situações: nós gostamos de “inventar. talvez por causa do nosso ego, ou pela busca de desafios, nós gostamos sempre de trazer uma “nova solução” para um determinado “problema” que já existe a muito tempo, ou talvez nem “exista” de verdade.

deixa eu tentar exemplificar: o cliente nunca reclamou da performance de uma funcionalidade, mas descobrimos uma parte do código que pode rodar “mais rápido” se for alterado. até aí tudo bem. esta mudança parece ser para o benefício do produto, da funcionalidade e do cliente. mas, infelizmente, na maioria das vezes não fazemos a conta do esforço que será necessário, e como consequencia $$$, versus o benefício que a mudança trará. pode ser que precisemos de uma semana para melhorar o código e testá-lo para ter um ganho de um segundo em uma funcionalidade que não é de missão crítica e que o cliente está satisfeito com a performance.

isto ainda sem considerar o “code churn”. mudamos um código que funcionava e gostando ou não estamos aumento a probabilidade deste começar a falhar. mesmo que esta funcionalidade tenha uma boa cobertura de testes, estamos criando um risco, que no exemplo acima poderia ser “desnecessário”.

além disto, embora como técnicos não gostamos de admitir, precisamos identificar e quantificar o ROI, ou retorno do investimento. será que o retorno desta alteração trará verdadeiros ganhos? não precisa ser necessariamente financeiro, mas normalmente envolve $$. afinal tempo é dinheiro. :)

este final de semana estava lendo os meus blogs costumeiros e me deparei com um post do ayende que apontava para este post. basicamente a pessoa sugeria que para o banco de dados que eles estavam usando seria melhor usar nome de campos de 2 ou 3 caracteres, ao invés, de usar um nome que seja facilmente identificável como  “timeAdded”. a justificativa para o uso de nomes de campos menores era a economia de espaço em disco. o ayende fez algumas contas simples, que tenho que concordar “bem simplificadas”, mas que mostram que talvez a economia não tenha valido a pena considerando o custo do desenvolver “apenas”. neste outro post o autor original tentou justificar o “ROI” de sua sugestão dizendo que o seu problema e preocupação era sim espaço em disco. o ayende ainda respondeu tentado mostrar que mesmo assim a conta não fecha.

não quero dizer quem está certo nas contas neste caso específico. mas o que fica claro é que se não tomarmos cuidado nossa busca por desafios ou “invenções” no código pode resultar em perda de tempo e dinheiro em relação ao verdadeiro ganho que a alteração pode trazer.

[]s