[4 de 97]. Lo Perfecto es enemigo de lo suficiente.

El axioma de hoy dice:

"Perfect" is the Enemy of "Good Enough"

Greg Nyberg. 

Greg Nyberg es actualmente un consultor independiente de JEE con 18 años de experiencia diseñando, construyendo, probando y poniendo en producción aplicaciones transaccionales de grandes volúmenes. Es el autor principal del libro: Mastering WebLogic Server (Wiley).

Siendo estrictos y en honor a la verdad, la frase completa es: "La perfección es enemigo de lo suficientemente bueno" y se le atribuye por igual a Voltaire y a Leonardo Da Vinci.

Aquí un breve resumen (tomado del libro 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.

Pensaba como iniciar los comentarios de este axioma cuando recorde que en el podcast 33 de javaHispano; durante la entrevista con Eduardo Pelegri (encargado de Glassfish), mientras comentaba sobre la  especificación inicial de los JSP's se le preguntó qué opinaba de esa especificación y como habían llegado a ella:

Y aquí una transcripción de sus palabras.

"Una especificación que sea técnicamente perfecta pero que no tenga  soporte en la industria es inútil.
{...}
Hay que conseguir una especificación que sea técnicamente válida {...}
No es cuestión de que todos digan: 'esta es la mejor especificación que yo podía hacer' sino:
Esta es la mejor especificación que todos hemos podido hacer conjuntamente".
Entrevista a Eduardo Pelegri por Abraham Otero (10:12min)

Me imagino a varios gurús reunidos tratando de llegar a un acuerdo sobre como debía ser la especificación (mi mente geek los visualiza como una reunión de Ent's), y, me imagino a todos tratando de lograr que la especificación llevara lo mejor de sus propuestas; me imagino también lo difícil que debió llegar a un acuerdo en donde, muy probablemente más de uno tuvo que doblegar a su ego para permitir que las propuestas de otros tuvieran cabida.

Si cada uno de ellos se hubiera aferrado a sus ideal de perfección muy probablemente, la especificación hubiera tardado más tiempo en salir y quizá la historia seria otra.

Creo que a estas alturas, todos estamos conscientes de lo que el axioma advierte: no es adecuado aferrarnos y enajenarnos en conseguir una aplicación o un fragmento de código perfecto y esa búsqueda de perfección nos lleve a perder el tiempo y/o dejar de ocupar ese tiempo en cosas que pudieran  darle más valor a nuestra aplicación.

Veamos otro ejemplo:
Recordemos  que cuando se comentó el caso LinkedIn en jH, salio al tema el uso de JDBC "a pelo", y mientras algunos criticaban la técnica duramente otros la defendían argumentando que el desempeño, en aplicaciones muy grandes, mejoraba considerablemente, también se comentaban cosas como que ya no existía estrictamente hablando una integridad referencial .... No ORM, no integridad referencial ¡¡¡ blasfemia !!! XD

Imaginemos ahora, que hubiera pasado si el arquitecto en jefe de LinkedIn no hubiera tenido la sensibilidad de reconocer que esa técnica era ya suficientemente buena.

Y antes de perderme con los ejemplos creo útil retomar una pregunta que se plantea en el axioma ( y a manera del addendum que comentaba ibon):
¿Hasta cuanto o hasta cuando es suficiente? ¿Cómo saber que ya tenemos lo suficiente?¿Hasta que punto debemos detener esa búsqueda de perfección?
Creo que el principal indicador, y ya lo mencionábamos anteriormente; es el tiempo invertido en la búsqueda de esa perfección.

Si ese tiempo que invertimos en buscar, refactorizar y "maquillar" nuestro código buscando la perfección supera al tiempo necesario para:

• Agregar una nueva funcionalidad a nuestra aplicación.
• Corregir errores de alto impacto.
• Atender nuevos requerimientos.
• Atender requerimientos aún pendientes.
• Corregir errores graves detectados por herramientas como PMD o FingBugs.
  

Es hora de detenernos y aceptar que le hemos dado una solución suficientemente buena al requerimiento que cubre el código.

Me quedo con la última frase de G. Nyberg:

"Recuerda que el desarrollo de aplicaciones no es un concurso de belleza, por lo que deja de mirar los defectos y perder el tiempo persiguiendo la perfección."

A fin de cuentas, nunca daremos satisfacción a todos.... ¿o sí?  ;)



Saludos!!!
---
RuGI

Isaac Ruiz Guerra.

Posted at 08:12PM jun 07, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[4]