quanto vale a sua alteração no código?
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
Comments
- Anonymous
October 29, 2010
Amigo, vc matou a charada, tô passando por isto agora, temos uma aplicação que hoje conta com mais de 2000 usuarios em mais de 400 clientes. É uma aplicacao Comercial para atender o pequeno comercio. Minha ideia era modifica-la num todo para que ela alem de atender o pequeno atendesse o pequena e media empresa. Depois de muitos brain storms fimos que o melhor seria dar continuidade neste projeto que hoje já é rentavel e nao precisamos mudar o rumo num todo. E sim, desenvolver uma nova aplicacao com novas diretrizes para as pequenas e medias empresas. As microempresas que hoje atendemos automaticamente tendo seu crescimento e passando para Pequenas e medias, podem aproveitar o bem mais precioso que seriam os dados e com a vantagem de usufruir de novas tecnologias. AFinal , no caso do meu software pra que reinventar a roda? O Sistema já roda a mais de 8 anos, Teve suas alteracoes para atender a legislacao e atende bem. Tem muita coisa que foi feita com ideias antigas que as vezes realmente é mais lento. Mas para o microempresario com a base pequena e com a evolucao dos PC´s isto é imperceptivel para ele. Concordo com vc em genero, numero e Grau. Parabens pelo post!