miércoles, 2 de noviembre de 2011

[12 de 97] Evita las buenas ideas.


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 (tomado del libro 97 things Every Software Architech Should Know) dice:
"Evita las buenas ideas"

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

Aquí parte importante del axioma:

Idea

---

Good ideas kill projects. Sometimes it's a quick death, but often it's a slow, lingering death caused by missed milestones and a spiraling bug count.

You know the kinds of good ideas I'm talking about: Tempting, no-brainer, innocent-looking, couldn't-possibly-hurt-to-try sorts of ideas. They usually occur to someone on the team about halfway through a project when everything seems to be going fine. Stories and tasks are getting knocked off at a good pace, initial testing is going well, and the rollout date looks solid. Life is good.

Someone has a "good idea," you acquiesce, and suddenly you are re-fitting a new version of Hibernate into your project to take advantage of the latest features, or implementing AJAX in some of your web pages because the developer showed the user how cool it is, or even re-visiting the database design to utilize XML features of the RDBMS. You tell the project manager you need a few weeks to implement this "good idea," but it ends up impacting more code than originally anticipated, and your schedule starts to slip. Plus, by letting in the first "good idea," you've allowed the proverbial camel's nose in the tent, and soon the good ideas are coming out of the woodwork and it becomes harder to say no (and the camel is soon sleeping in your bed).

The really insidious thing about "good ideas" is that they are "good." Everyone can recognize and reject "bad" ideas out of hand - It's the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn't necessary to meet the business need.

---


Debo confesar que este axioma me parece de entrada pesimista, pero, revisando la lista de axiomas del autor, veo que deben ser tomados como axiomas de "cautela y advertencia" (probablemente le ha tocado participar en proyectos muuuy exigentes o críticos)

Su otro axioma ya lo habíamos platicado:
  • [4 de 97] Lo Perfecto es enemigo de lo suficiente.
Y, retomando el comentario, creo que son axiomas de cautela ya que, si no los tomamos con las debidas reservas, pueden ser hasta contraproducentes.

Iniciemos la reflexión.

Hace algunas semanas atrás en una presentación(disponible en slideshare) de Sergio Acosta titulada: "Por que Scrum no funciona". Justo en la diapositiva 100, Sergio comentaba algunos puntos interesantes sobre cómo se desarrolla el software en la NASA y, cómo sus procesos limitan la creatividad de los programadores.

Diapositiva 100



Creo que Nyberg se refiere, en su axioma, a (este tipo de ) las buenas ideas que generan la creatividad necesaria para generar niveles de incertidumbre que un proyecto no puede tener dado su nivel de importancia.

A todos nos queda claro que el más mínimo detalle que se salga de control en una aplicación espacial puede tener consecuencias muy costosas.

El axioma de Nyberg incluye una breve lista con ejemplos:
  • "Wouldn't it be cool if …" Really, any sentence with the word "cool" in it is a danger signal.
  • "Hey, they just released version XXX of the YYY framework. We ought to upgrade!"
  • "You know, we really should re-factor XXX as long as we are working on ZZZ …"
  • "That XXX technology is really powerful! Maybe we could use it on …"
Y me permito compartir un par de anécdotas que me han ocurrido en los últimos años.

Struts 1.0.x a Struts 1.1
Supongo que le pasó a más de uno, cuando Struts era el rey, muchos tratábamos de mantenernos en la más reciente versión; recuerdo que una vez alguien actualizó la versión (sin avisar) y nos llevo casi media mañana darnos cuenta que los Action no hacían forward ya que, un método perform dejó de existir y ahora requeríamos invocar a execute.

int a byte
Debo confesar que esta es mía XD, era el 2002 apenas tenia un par de años programando con java (ocupaba en su momento a el otro rey de la época: JBuilder) y me tocó darle mantenimiento a una aplicación que tenia algunos problemas de validación, mi labor era construir nuevas piezas y no corregir dichos problemas.

En una ocasión, vi un fragmento de código que podía lanzar una excepción por recibir un valor superior soportado por  la base de datos; me pareció buena idea ajustar dicho valor en el respectivo Bean a byte (era int); justo en ese momento me piden hacer commit de mis cambios y yo sin problema accedí a hacerlo (total es solo un campo, pensé, además evito un error en la capa de datos y hago que la aplicación se ahorre unos 3 valiosísimos bytes)..... sólo pasaron unos segundos para que la oficina pareciera fiesta de celebración de independencia (recordaran que JBuilder emitía un sonido parecido al de una leve explosión cuando, al compilar, encontraba errores), los errores de compilación que se generaron por las "quejas" de los métodos que recibían el int( por omisión, un literal entero es de tipo int y debe recibir un casting para poder "verlo" como byte; al igual que un literal decimal es double y  no float)  no se detuvieron hasta después de un par de minutos..... resultó que ese diminuto Bean era el parte del core de la aplicación y, no habían hecho el cambio de int a byte precisamente porque afectaba demasiadas clases y, nadie había querido cargar con la responsabilidad de modificarlas.

Seguramente ustedes tendrán también anécdotas para compartir ;)

Entonces ¿Definitivamente no tomamos en cuenta las buenas ideas? Por supuesto que debemos tomarlas en cuenta. Ahora mismo me encuentro en un proyecto del cual no estaríamos tan cerca de terminarlo con cero bajas, sino fuera por las buenas ideas y los aportes de cada uno de los integrantes del equipo.

Siendo sinceros este axioma puede parecer alarmista, pero, como bien dice la semiótica, en el ultimo de los casos, el contexto da el significado.

A manera de defensa del axioma, pienso que debemos tomar en cuenta el contexto de una aplicación para poder aplicarlo o no.

Así que; salvo sus experimentadas opiniones, según lo que yo sé y a riesgo de equivocarme, la frase:

Evita una buena idea

Debería quedar así:

       Evita (implementar) una buena idea ((en proyectos críticos|siempre) (sin antes hacer exhaustivas pruebas de [integración|impacto|regresión]))

Y miren que de integración ya hemos hablado ;)

En fin, como hemos venido comentando, el secreto de hacer mejor las cosas es adquirir la experiencia suficiente para poder saber: hasta cuando y hasta dónde.

¿No creen?

Dejemos que Dilbert nos incite a iniciar bien la semana.


IDEA_DILBERT

Saludos a todos!!!

RuGI
Isaac Ruiz Guerra.

Comentarios:


Nosotros eso lo llamamos desarrollo "Jackie" (de Jackie y Nuca) por que suena como en catalán el inicio de la frase "ya que estamos..." Y Nuca también aparece con el "esto Nuca hará falta o Nuca es así". Si tienes ambos rasgos en un proyecto (desarrollo tipo bosque de Tallac) entonces lo tienes crudo :).

Volviendo al tema, lo único que no me convence mucho es la traducción, por que una buena idea es buena, y los proyectos estan llenos de ellas. Son las ideas "guays" o los "porsiacas" que hay que evitar. Parafraseando al dicho: "Señor, dame fuerza para implementar las buenas ideas, valor para rechazar las que sólo son guays, y sabiduría para distinguir a unas de otras" ;).

Yo en caso de duda pongo el "modo borde ON" y pregunto (aunque sea a mi mismo) ¿por qué vamos a hacer/usar esto? Y las respuestas estilo "es más moderno, es más guay, todo el mundo lo usa, quedará una arquitectura más redonda (verídico que me han respondido esto)..." quedan descartadas. Para tomar una decisión técnica, razones técnicas.

S!

Enviado por GreenEyed en agosto 10, 2009 a las 04:03 AM CDT #
---
¡Cuántos recuerdos...! Si de buenas ideas se trata, el mayor y mejor ejemplo, en mi opinión, fue el desarrollo de Starcraft 2. Hasta la fecha seguimos esperando... precisamente porque se les fueron ocurriendo muy buenas ideas conforme los videojuegos siguieron evolucionando. Y la manía por tener la última versión de tal o cual aplicación... eso es clá-si-co... la ventaja es que Vista les quitó a muchos esa costumbre... primero evaluar como tú has dicho. Esas prácticas me han llevado a separar los entornos "de entrenamiento y exploración" de los entornos "de desarrollo". En ese "contexto", es la pragmática quien estudia cómo el contexto influye en el significado. La teoría general de los signos tiene una perspectiva holística, y no se limita al contexto.

Enviado por Miguel Zúñiga González (miguel~1.mx) en agosto 10, 2009 a las 04:04 AM CDT #
---
@GreenEyed tienes razón con tu comentario, mea culpa... en el libro el axioma aparece, at litera: [Avoid "Good Ideas"], ese entrecomillado, creo enfatiza lo que comentas; y a mí se me ha pasado completamente.

Sirva esto pues de "fe de errata" ;)

Hombre @Miguel, pufff, cómo poder comentarte!; mi cuasi-fijación por el valor/significado/trascendencia de los signos/símbolos hace que a todo le vea rasgos semióticos XD.

Por cierto, durante la presentación de Sergio surgieron unos conceptos que seguramente estaremos discutiendo en próximas reuniones.
  
Enviado por RuGI en agosto 10, 2009 a las 10:51 AM CDT #
---
Estimado RuGI espero puedas continuar con esta saga, muy interesante.

Saludos

Enviado por Richard C. en agosto 20, 2009 a las 01:37 PM CDT #
---
Richard!
Servido! ;)

Enviado por RuGI en agosto 23, 2009 a las 04:29 PM CDT #

---------------------------------------
Créditos:
La foto es de: svgorange
http://www.flickr.com/photos/svgorange/4626574448/
La 2a imagen es parte de la presentación de Sergio Acosta:
Hablando de Scrum.
Dilbert es una marca registrada de Scott Adams.
-------------------------------------

No hay comentarios:

Publicar un comentario