Foto de Ernest Descals
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.
14 Comentários
Trackbacks
- Tweets that mention Nome do Jogo » Blog Archive » Qualidade demais pode arruinar seu software -- Topsy.com
- uberVU - social comments
- O melhor da semana 18/10 a 24/10 « QualidadeBR
Oi Carlos, Excelente post
A característica de saber parar vem com a experiência do profissional, assim como a do analisar o custo/benefício de algumas implementações. Acredito que quando o profissional também possui uma visão comercial do projeto e não puramente técnica esse ponto fica mais claro.
Abraços!
@carlosbrando:
nao consigo concordo totalmente com teu ponto de vista nao, embora ache que ele aponta para uma questao muito importante, que eh o fato de que nohs programadores e designers, precisamos nos conscientizar sobre a hora de sair do ideal e abracar o real.
Porem considero que software eh algo como um monstro, sua construcao “fisica” eh apenas uma parte, mas uma vez trazido ao mundo, voce vai ter que cuidar dele… Software eh uma coisa organica, viva (ou morta-viva dependendo do monstro em questao).
O seu ponto de vista corrobora com o conceito de race to running software lah do Getting Real e eh um conceito que eu considero muito bom, porem ele diz respeito apenas a uma determinada fase da criacao do projeto, ou no maximo eh uma parte de cada interacao. Cada feature/estoria de um app eh que pode ser arruinada junto eh claro com a reputacao do time quanto a seu comprometimento com as entregas. Se eu me prendo em querer entregar tudo perfeito de uma vez eu posso nao conseguir entregar, porem uma vez entregue o ato de aparar as arestas eh importante sim e saber a hora de parar tem mais aver com um casamento entre interesses comerciais da equipe e o que ela pretende com aquilo que esta entregando.
O usuario nao quer bug, ele se irrita com isso, nao ha experiencia de usuario que o faca ignorar os bugs, nao interessa o que digamos. O ponto chave para se atingir o equilibrio entre ter um codigo de qualidade mas nao se tornar um paranoico com isso tem muito a ver com o que diabos isso impacta pro seu usuario. Certamente metade das mutacoes que o Heckle vai apontar o usuario jamais vai chegar perto de ver um bug causado por algo daquela natureza.
O ponto todo eh que termos preocupacao com qualidade nao pode implicar em vivermos em uma realidade utopica, fake.
Carlos,
Gostei do post. Você tem alguma dica de como identificar que estamos passando do limite com refatoração, testes excessivos, etc?
Abraços
Inspirado no teu post, resolvi escrever um sobre o que software tem em comum com monstros…
http://www.geek.com.br/posts/11249-aulas-de-agile-com-dr-victor-frankenstein
Acho que tudo corre de acordo com a experiência.
1) O desenvolvedor acha que vai mudar o mundo e não consegue entender como pode existir tantos “sistemas mal feitos” mundo afora;
2) O desenvolvedor fica muito irritado porque não consegue agir como gostaria e percebe que as coisas podres crescem muito mais rapidamente que sua capacidade de remediá-las;
3) O desenvolvedor entende, por fim, que absolutamente tudo está relacionado ao dinheiro, e as pessoas gostam muito mais dele entrando do que saindo.
Neste terceiro ponto é que o desenvolvedor aprende a parar, na pior das hipóteses, na marra, e começa a levar realmente à sério aquela estória da “simplicidade” e do “nem mais, nem menos”.
É o mercado que o força a mudar, assim que ele tiver maturidade. Enquanto ele estiver nos passos um e dois, dificilmente alguém conseguirá convencê-lo de que existe uma hora para parar. Essa, inclusive, é a razão pela qual os desenvolvedores mais novos acham que os veteranos estão “perdendo o jeito”, quando, na verdade, mal sabem eles que chegarão lá um dia.
Um abraço,
Leandro
Everton J. Carpes,
Eu penso que nós programadores por termos um censo mais apurado com respeito a softwares não aceitamos bugs com tanta facilidade. Mas normalmente os usuários não pensam da mesma forma, pegue como exemplo o caso do Microsoft Windows.
Olá Carlos.
Eu li algumas vezes esse post e acho que entendi que o que você quis dizer foi que perfeccionismo exagerado é furada. Eu concordo contigo. Também concordo que software com zero bug é complicado. Mas eu fiquei com dúvida em alguns pontos:
Quando você diz: “Mas que você deve considerar o quão importante é a ausência de falhas ou a qualidade do código para o seu cliente.”, eu não entendi muito bem. Me pareceu que tem horas que se preocupar com qualidade é desnecessário. Foi a minha impressão, poderia explicar melhor?
Outra coisa que fiquei em dúvida foi quando você mencionou o Getting Real. A parte da motivação eu entendi da mesma forma. Mas eu me lembro que quando eu li eles passaram uma idéia que você deveria fazer menos features mas que fossem muito bem feitas. Acho que isso incluia ausência de bugs e uma qualidade impcável. Faz sentido pra você?
Um grande abraço e parabéns por abrir essa discussão!!!
Emerson Macedo,
Na verdade a ideia é que a qualidade deve fazer parte do escopo do projeto, assim como o prazo e outras características do software. Não me leve a mal, eu levo muito a sério TDD, integração contínua e qualquer prática que deixe meu código mais limpo.
Qualidade é algo crucial, mas estou defendendo que não devemos levar o zelo pelo código tão ao extremo ao ponto de ignorar o quão importante é a qualidade para o cliente que estamos desenvolvendo o programa.
Mas de forma alguma estou querendo dizer que temos de jogar tudo para o alto afim de cumprir um prazo, mas que devemos ser equilibrados. Cuidando do nosso código, mas não tanto ao ponto de ignorar as necessidades do cliente.
Opa Carlos,
Acho que houve uma confusão sobre satisfazer a necessidade do cliente com a qualidade interna do projeto.
O satisfazer a necessidade do cliente está mais ligado ao seu backlog e como você gerencia ele. Um dos vácuos deixados pelo ágil, onde caras como o Jeff Patton tentam preencher.
Muitas vezes para atender ao prazo não é necessário baixar ou aumentar a qualidade, mas encontrar uma solução mais barata que atenda à necessidade do cliente. Ou então cortar suas histórias de forma que mesmo não tendo uma funcionalidade toda, você tem pedaços de várias, tornando seu projeto funcional.
Afinal, não adianta tentar remar rápido ou devagar se você estiver indo para o lugar errado ou se seu barco está com carga demais.
O problema de deixar a qualidade (um pouco) de lado, é que mesmo que você não esteja desenvolvendo aplicações de missões críticas, você não tem como escolher deixar bugs apenas nas partes menos importantes, ou nas arestas como você citou. Os problemas podem aparecer em qualquer parte e de forma imprevisível. É um desperdício trabalhar dias em uma funcionalidade e não servir por que você esqueceu de um if que ferrou com tudo. Sem falar na relação de confiança quebrada com o usuário do software.
Tratando apenas do ponto de vista técnico, acho que não faz sentido a relação inversamente proporcional de qualidade x velocidade. A não ser que seu projeto seja tão pequeno, que um código não refatorado não atrapalhará inserir novas funcionalidades.
Algumas leituras boas são:
http://agileproductdesign.com/blog/acurate_estimate_red_herring.html
http://agileproductdesign.com/blog/the_new_backlog.html
Acho que você vai achar interessante a discussão quando o Kent Beck decidiu não escrever testes para seu projeto pessoal (JUnitMax):
http://tech.groups.yahoo.com/group/extremeprogramming/message/150666
Ricardo Mayerhofer,
Mais uma vez eu preciso reforçar que não estou falando em jogar a qualidade fora para cumprir prazos. O problema é com o “excesso” de qualidade.
Como programadores profissionais estamos nos preocupando cada vez mais com testes, refactoring e coisas do gênero. Mas assim como em uma pintura, é importante saber quando parar de melhorar o código afim de não estragá-lo.
Sou um defensor de todas as boas práticas de desenvolvimento de software e como você pode ver no artigo “Seu código está apodrecendo” onde falo de entropia, acredito que sem manutenção o código vai se tornando inútil. Mas a ideia principal deste artigo foi alertar que existe um “limite saudável” para a qualidade e que este limite deve levar em consideração as expectativas do cliente.
Não sei se fui claro o bastante, mas é esta a ideia.
O problema é que as boas praticas pregam a “refatoração” e que a mesma seja a mais cedo possivel.
Porém também devemos evitar mexer se não fomos solicitados, evitando assim demais. É como no caso de melhorar para que o codigo fique mais rapido, entretanto quem mediu e disse que esta lento foi você programador, e não o usuario ou devido à sobrecarga do sistema.
Assim pecamos nos excessos.
E as boas praticas pregam evitar desperdicio, e fazer algo que ninguém precisa o solicitou é desperdicio. O lema é seja “preguiçoso” escreva pouco.
Muito bom Carlos! Essa analogia com a pintura é muito apropriada. Seu post me lembrou a palestra do Obie Fernandez no Rails Summit desse ano. Fazer software é mesmo uma arte (http://manifesto.softwarecraftsmanship.org/).
abracos
Alexandre Gazola,
Realmente… eu também gostei muito da palestra e ela ajudou a terminar o post, embora eu já tivesse começado a escrever antes do evento.
E concordo totalmente com o software ser artesanato.
Acredito que a definicao de quando parar de testar um software deva ser integrada com o restante dass atividades do seu projeto. Sei quee muitas pessoas abominam isso, mas planejar o que testar, como testar, e o quanto testar deve ser planejada com antecedencia e nao ficar somente na maos dos desenvolvedores. Lembrando que testar nao eh somente debugar e envolve outras atividades. Concordo com o artigo do Carlos Brando, pois ninguem consegue testar seu software o tanto quanto gostaria. Entao eh mais interessante definir antes criterios que satisfacam aquele projeto especifico no qual voce esta trabalhando.
abracos