[12 de 97] Evita las buenas ideas.

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:



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.



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.


Saludos a todos!!!
---
RuGI
Isaac Ruiz Guerra.

Posted at 11:58PM ago 09, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[6]