Carlos Brando

Nome do Jogo

Qualidade demais pode arruinar seu software

Não entendo muito de pintura, mas os amigos que apreciam este tipo de trabalho sempre dizem que uma das coisas mais difíceis sobre pintar é saber quando parar. Entender que o trabalho terminou. Uma pincelada a mais pode arruinar um lindo quadro.

Acredito que o mesmo acontece com software. Programadores profissionais sempre defenderam refatoração, testes, integração contínua e outras práticas que visam deixar nosso código mais limpo e livre de falhas. Mas existe um limite para a aplicação dessas práticas? É possível que a preocupação exagerada com a qualidade do software acabe prejudicando o projeto?

Ferramentas como Flog, Flay e Heckle foram criadas para que pudéssemos estressar nosso código ao limite. Ter um código limpo, sem repetições e com testes bem feitos é essencial para o sucesso de um projeto, sem dúvida nenhuma. Mas o fato é que vivemos em um mundo imperfeito e o sonho de um software livre de bugs é um objetivo impossível de ser alcançado. O tempo, as pessoas e até a nossa amada tecnologia, tudo conspira contra nós. Então quando é a hora de parar e declarar o trabalho como finalizado?

A primeira coisa que precisamos ter em mente é que um projeto de software bem-sucedido não é necessariamente livre de bugs, mas sim um software que atende aos requisitos exigidos pelo seu cliente ou usuário. Isto não quer dizer que você deve jogar tudo para o alto e deixar seu código apodrecer. Mas que você deve considerar o quão importante é a ausência de falhas ou a qualidade do código para o seu cliente.

Se você estiver desenvolvendo um software que controlará algum equipamento médico ou uma aeronave ou estiver trabalhando em uma biblioteca open source que será amplamente utilizada, então você não tem escolha e suas opções serão mais limitadas. Porém, este tipo de projeto é uma exceção. Na maior parte do tempo estaremos trabalhando em produtos comerciais mais simples onde seu cliente terá um cronograma de entrega baseado em promessas feitas a seus superiores e sua empresa certamente terá um fluxo de caixa apertado.

Da mesma forma como seria pouco profissional aceitar prazos impossíveis e deixar testes de lado para terminar um projeto dentro do prazo, também não seria nada profissional ignorar as necessidades do seu cliente/usuário simplesmente para adicionar uma nova funcionalidade ou refatorar o código mais uma vez.

Depois de mais de dez anos trabalhando com software, posso dizer empiricamente que muitos usuários preferem usar um software com algumas arestas soltas do que esperar um ano por uma versão livre de falhas. Muitas vezes é melhor um software ótimo agora do que um software perfeito amanhã.

Ainda há uma outra vantagem nessa abordagem. De acordo com o livro Getting Real: “A coisa mais importante em desenvolvimento de software é motivação. Motivação é localizada—se você não está motivado pelo que está trabalhando neste instante, as chances de que isso não saia tão bom são grandes . Na verdade, isso provavelmente vai ficar ruim”. Ciclos de entregas longos e demorados são assassinos de motivação.

Se você dá algo para seus usuários brincarem no início, as suas reações muitas vezes levarão a uma solução melhor.

Programar é como pintar. Tudo começa com um quadro branco, seguido por um esboço, uma pintura maior e então com o preenchimento dos detalhes. Se seu olhar for critico demais, você não saberá quando parar até que tenha estragado a sua pintura.

Comments