domingo, 6 de septiembre de 2015

[4 de 97]. A perfeição é inimiga do bom o suficiente.

“‘Perfect’ is the Enemy of ‘Good Enough’”


A rigor e com toda a honestidade, a frase completa é: "A ‘perfeição’ é inimiga do ‘bom o suficiente’", e ela é creditada igualmente a Voltaire e a Leonardo Da Vinci.


mandala.png


Aqui um extrato do que ele escreve no livro 97 things Every Software Architech Should Know:
---


Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem. Like judges at a beauty contest, we look at a design or implementation and immediately see minor flaws or warts that could be eliminated with just a few more changes or re-factoring iterations.  Domain models simply beg for one more pass to see if there are any common attributes or functions that can be moved into base classes. Services duplicated in multiple implementations cry out their need to become web services. Queries complain about "buffer gets" and non-unique indexes and demand attention.

My advice: Don't give in to the temptation to make your design, or your implementation, perfect! Aim for "good enough" and stop when you've achieved it.

Remember that application development is not a beauty contest, so stop looking for flaws and wasting time chasing perfection.


---


Eu pensei em iniciar dessa forma a revisão dessa regra, quando me lembrei que no podcast de JavaHispano #36; durante a entrevista com Eduardo Pelegri (responsável pelo Glassfish), enquanto comentava sobre a especificação inicial das JSP’s  lhe perguntaram o que ele achava dessa especificação e como tinham chegado a ela.


Eis aqui uma transcrição de suas palavras.


“Uma especificação que é tecnicamente perfeita, mas não tem apoio na indústria, é inútil….
Você tem que ter uma especificação que é tecnicamente válida…
Não é só questão de dizer:
‘Esta é a melhor especificação que eu poderia fazer’
senão:
'Esta é a melhor especificação que todos poderíamos fazer juntos”
Entrevista com Eduardo Pelegri por Abraham Otero (10:12min)


Eu imagino vários gurus reunidos tentando chegar a um acordo sobre como deveria ser a especificação (minha mente geek vê-los como uma reunião de Ent’s), eu imagino todos  tentando obter uma especificação que considerasse a melhor de suas propostas. Eu também imagino como seria difícil chegar a um acordo em que provavelmente mais de um deles tivesse que subjugar seu ego para permitir que outras propostas fossem aceitas.


Se cada um tivesse agarrado com unhas e dentes o seu ideal de perfeição provavelmente a especificação teria levado mais tempo para sair e talvez a história seria outra.


Neste ponto você está ciente de tudo o que a regra adverte:
não é apropriado aferrar-se ou alienar-se para obter um aplicativo ou um fragmento de código perfeito, e melhor ajudar a preencher esse tempo com coisas que poderiam dar mais valor ao nosso aplicativo.


  • Quanto? Ou quanto tempo isso é o bastante?
  • Como saber que já temos o suficiente?
  • Em que medida devemos parar de busca a perfeição?


Eu acho que o principal indicador é o tempo gasto procurando por essa perfeição.


Se esse tempo que investimos em pesquisar, refatorar e maquiar nosso código à procura de perfeição mais do que o tempo necessário para:
  • Adicionar novas funcionalidades para o nosso aplicativo.
  • Corrigir erros de alto impacto.
  • Enfrentar novos requisitos.


...É hora de parar e aceitar que já temos dado uma boa ou suficiente solução para o que solicitaram.


Eu fico com a última frase de G. Nyberg que diz:
“Lembre-se que o desenvolvimento de aplicativos não é um concurso de beleza, assim que pare de procurar defeitos e pare de perder tempo perseguindo a perfeição.”


Afinal de contas, é difícil agradar a todos.... não é? ;)


clean_code.jpg
---


---------------------
Créditos:
A imagem é de: J Eberl
A imagem da porta aparece no livro:
---------------------