miércoles, 2 de noviembre de 2011

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


Post publicado originalmente entre Mayo del 2009 y Enero del 2011 en mi anterior blog.
Pertenece a una serie sobre arquitectura de software, replicaré los comentarios ya que, a mi parecer, son lo más importante de la serie.

Puedes encontrar el listado de esta primera entrega en este enlace.

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 ):

White Tara Mandala - Day 6 - Sarasota, Florida

---

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í?  ;)

s3

Saludos a todos...
RuGI
Isaac Ruiz Guerra.


Comentarios:


En contra de JDBC "a pelo" el argumento no es que no tenga "integridad referencial", ya que ese concepto es a nivel de BDD.
El problema es no tener los queries en un sólo sitio, no tenerlos "verficados contra el esquema de BDD" y tener que escribirlos todos a mano, incluyendo los queries más simples y repetitivos.

Por lo demás, es algo que ciertamente mucha gente debería aprender, aunque bien es cierto que hay gente que con la excusa de "ya es suficiente" se queda en la primera chapuzilla que le funciona :).

Enviado por GreenEyed en junio 08, 2009 a las 01:27 AM CDT #
---
Estoy de acuerdo con la cuestión de fondo de "la perfección es enemigo de lo suficientemente bueno" pero no estoy de acuerdo con los detalles cuando dices:

"¡Si ese tiempo que invertimos en buscar, …”

Una necesaria refactorización suele ser vital para poder agregar una nueva funcionalidad, suele acabar con errores de alto impacto y es la condición para poder atender nuevos requerimientos para los cuales nuestro código no está preparado.

La no refactorización suele ser la causa de que algunos programas se vayan degradando con sucesivas versiones, porque las nuevas características se añaden con calzador.

Siempre citaré el caso de la vieja historia del Netscape Navigator 4 vs Internet Explorer 4, el Navigator 3 era estupendo pero no estaba preparado para introducir DHTML, la introducción de DHTML en la v4 se hizo deprisa y corriendo y el resultado fue un navegador pésimo, el resto es historia.

Enviado por jmarranz en junio 08, 2009 a las 02:57 AM CDT #
---
Mis dos céntimos:
Unja muy buena herramienta para saber cuando parar es
 Sonar 
sobre todo sus informes "Cloud" (ejemplo: http://nemo.sonar.codehaus.org/views/project/org.microemu:microemu/org.sonar.plugins.core.clouds.GwtClouds) 
"HotSpots" (http://nemo.sonar.codehaus.org/views/project/org.microemu:microemu/org.sonar.plugins.core.hotspots.GwtHotspots), 
son muy buenos para indicarnos donde deberíamos empezar nuestras refactorizaciones... y cuando parar ;-)

Salu2

Enviado por ibon en junio 08, 2009 a las 02:58 AM CDT #
---
@GreenEyed sí coincido contigo al buscar evitar quedarnos con "la primera", o con el clásico "si funciona ya no le muevas". 
La intención de mencionar el caso de linkedIn fue para recordar un poco que a veces hay soluciones que pudieran no parecernos totalmente "buenas", pero que, dado el contexto de la aplicación misma resultan útiles :)

@jmarranz déjame justificar un poco el porqué puse esos ejemplos como "indicadores"; en algunos proyectos en los que he participado a veces se adopta la conducta(me incluyo) de "sobrevaluar" la refactorización, evitando atender cosas un tanto más "prioritarias". Para nada estoy en contra de la refactorización, sólo intenté prender los focos de "advertencia" para que evitemos caer en ese "patrón conductual"; pero estoy seguro que 
recomendaciones de herramientas, como la que @ibon menciona, podrán ayudar a evitar que este tipo de indicadores sea menos subjetivo.

@ibon!!, Mil gracias por la recomendación!!!

Saludos a todos!!!

Enviado por RuGI en junio 08, 2009 a las 08:09 PM CDT #

-------------------------------
Créditos:
La foto es de: J Eberl
http://www.flickr.com/photos/jeberl/4546882001/
La imagen de la puerta aparece en el libro:
Clean Code.
-------------------------------



No hay comentarios:

Publicar un comentario