miércoles, 2 de noviembre de 2011

[15 de 97] Elige bien tus armas, renuncia a ellas de mala gana.


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:
"Elige bien tus armas, renuncia a ellas de mala gana."
Richard Monson-Haefel. 

Richard Monson-Haefel. es el autor de los libros: "Enterprise JavaBeans (Ediciones 1-5)", JMS y es considerado un experto en el ambiente empresarial con java.

Fue arquitecto líder en el proyecto OpenEJB y en el contenedor EJB utilizado en Apache Geronimo; por si fuera poco, es miembro del JCP.

Su sitio web: http://www.monson-haefel.com

[NT. El título original del axioma es: Choose your weapons carefully, relinquish them reluctantly]

Aquí parte importante del axioma:

Dad's tool box

---

As a seasoned veteran of software design and implementation, every architect is armed with an array of weapons they’ve used with repeated success. For one reason or another, these technologies have found favor and bubbled to the top of our list of preferred solutions. Most likely they’ve earned their rightful place in your arsenal by defeating fierce competition. Despite this, a barrage of new technologies constantly threatens their position. [...]


To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It’s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.


One last thing to consider is future relevance. [...]. Great technologies don’t always win. Trying to predict the winners early is a gamble that doesn’t yield a large payoff. Wait for the hype to die down and see if the technology settles into a space of usefulness. You’ll find many just go away. Don’t jeopardize your project for a technology that doesn’t have a future.

---


Apenas leía el axioma, irremediablemente recordé las discusiones que se daban en los inicios de este siglo sobre qué distribución Linux era más efectiva o eficiente; irremediablemente me transporte a las discusiones acaloradas (en aquellos ayeres llamadas flames) que surgían en los foros o incluso en los canales IRC.

Iban, como decía, desde distribuciones linux:
  • "Debian es para hombres",
  • "la gente educada usa Suse",
  • "Suse es para niñas, Debian para antisociales, nada como Slackware"
  • "Los hackers de verdad usan RedHat"
  • etc
  • etc
Hasta:
  • Sistemas operativos:
    • Linux vs Windows
  • Lenguajes:
    • Java vs .Net
  • Frameworks:
    • Struts vs JSPs a pelo
Debido a los mecanismos de la memoria que permiten recordar relacionando, pensar en linux me hizo recordar el  CONSOL 2002, dónde participo Ismael Olea; su platica fue sobre el proyecto LuCAS, durante la plática mencionó como los desarrolladores que utilizaban herramientas más raras eran vistos como los más poderosos o relevantes, decía ( palabras más, palabras menos): "mientras más rara es la herramienta, pareciera que es más útil y de mayor eficiencia o al menos más impactante".

Y (nuevamente escudándome en las formas de trabajar de la memoria) eso de herramientas raras me llevo a imaginarme que a veces nos gustaría tener una caja de herramientas con cosas tan excéntricas como las que encontramos en nuestro juego de rol favorito (en mi caso Diablo II: Lord of destruction)




Cerremos los ojos he imaginemos que nos han enviado a una misión especial y nos toca terminar una aplicación por demás compleja; cual nigromante, nos gustaría hablar con los cuasi zombies sistemas legacy's y darles vida para hacerlos interactuar con nuestro código.

Pero, para bien o para mal, ahora, con tantas y tan distintas tecnologías debemos olvidarnos de tener herramientas esotéricas y mejor seguir la técnica del paladín.
El objetivo ahora es tener herramientas:
  • buenas,
  • bonitas,
  • efectivas en combate.
  • Y que puedan ser fáciles de intercambiar.
¿No creen?

Regresando al axioma (y después de este curioso ejercicio de vinculación de recuerdos), yo me quedo con estos fragmentos:
  • Antes de decidir adoptar una nueva tecnología preguntate cómo se beneficiará el negocio con esa decisión, si en el mejor de los casos nadie(de nivel gerencial) se percatará del cambio, reconsidera tu decisión
  • Es importante reconocer los costos asociados a las deficiencias (que pueda tener) la nueva tecnología (seleccionada)
  • Las grandes tecnologías no siempre ganan. Tratar de predecir prematuramente en una apuesta tecnológica es algo que no produce grandes ganancias.
  • No pongas en riesgo tu proyecto con tecnologías que no tienen futuro.
Hace un tiempo (previendo este post) abrí un debate en debug_mode=ON con el título:
Selección de armas para un proyecto,  y preguntaba: ¿Cómo seleccionamos nuestras armas para nuestros proyectos?.

Aquí un resumen  de los comentarios:
  • Venkman:
    • Elegir un lenguaje o plataforma depende de lo que se vaya a hacer, como punto de partida[...]valoro que haya estabilidad, buena documentación disponible, una comunidad activa [...] y que la gente hable bien y hable mal de la "herramienta/arma"
  • gimenete:
    • Creo que lo que más valoro últimamente es la agilidad.Para elegir el lenguaje de programación también suele pesar mucho la agilidad. Un lenguaje que conozca me da más agilidad. A veces me creo herramientas propias cuando creo que las que hay no solucionan mis necesidades[..]
  • danilat
    • Para mi tiene bastante peso el dominio de un arma, por que te hace sentirte más seguro[...]También creo que en muchos casos de creación de estas herramientas(herramientas propias) se peca de NIH.
  • amuino
    • Lo principal es la familiaridad con la tecnología[...]A la hora de elegir entre varias opciones, no te comento nada nuevo... el criterio para Open Source sería el de actividad  y velocidad de respuesta a dudas/errores.
  • GreenEyed
    • Depende un poco del proyecto a realizar y sus circunstancias. Si el proyecto es importante y el tiempo no sobra, los experimentos con gaseosa y en casa.Si el proyecto no corre tanta prisa o no es tan crítico, entonces si que me gusta introducir cosas nuevas[]
Para ver el hilo completo da click aquí.

Con todo esto reafirmamos que, nada esta escrito sobre piedra, no existe fórmula única en este tema, nuevamente apelamos a la experiencia generada y compartida a lo largo de nuestros años de desarrollo.
<autopromoción>En el podcast no 55 de javaHispano, al final de  la emisión, hacemos una pequeña reflexión sobre el tema</autopromoción>

Me gustaría revivir este debate, y antes de que dilbert nos conmine a iniciar con una sonrisa la semana, me gustaría volver a preguntarles:
¿Cómo eligen sus armas?


Saludos!!

RuGI
Isaac Ruiz Guerra.

Comentarios:

¿Cómo elijo mis herramientas? Decía un mecánico amigo mío que hay una herramienta para cada trabajo, pero también dice el dicho "a los veinte la voluntad es reina, a los treinta el ingenio y a los cuarenta el juicio". Hay herramientas más versátiles que otras, y hay las consentidas, empero, "a los sesenta son pocos los hombres que conservan su herramienta, y es por regla general que desde los cincuenta anda mal". Debemos estar conscientes del paso de la tecnología, y, con todo el dolor del corazón, hay que dejar ir en pos de lo siguiente.

De igual manera, es fácil culpar las herramientas, pero dice el dicho: "al mal torero, hasta los cuernos le molestan" (en inglés, a bad workman always blames his tools). Pienso que uno debe darse tiempo para ver qué hay en el mercado.

Es cierto, en este campo es muy difícil "ir al día", pero hay que darse la oportunidad. Cada herramienta da ventajas, y el buen juicio nos hará discernir entre una u otra. Cierto, hay muchas "ofertas en TV" pero enseguida, y sin necesidad de tanta experiencia, podemos ver si ese "abs toner" servirá o no para nuestros propósitos, y al final del día también sabemos que si nos comemos un kilo de tortillas, poco podremos hacer si queremos bajar de peso... o bajarle la grasa a nuestra aplicación.

Para mí es el buen juicio y el balance. Si me sirve ese desarmador para este trabajo, ¿para qué traer el eléctrico? y por otro lado, saber que si está la herramienta, hay que usarla. No precisamos héroes. Precisamos objetivos.

Aprendí a usar compus con GNU/Linux, luego me enteré que el resto del mundo usaba otro SO. En un principio llegaba diciendo que mi SO era mejor, sencillamente porque yo había aprendido en él. Por un momento dejaba de lado "la dulzura de la consola" y sí que me puse "al brinco" con varios (sobre todo los pro-MacOS). Al final sabemos que Win, MacOS y Linux tienen sus fortalezas y debilidades. Cuando lo entiendes es cuando puedes hacer realmente una recomendación: si puedes entrarle a la consola, GNU/Linux sí lo sabe hacer, si quieres pagar, están las opciones. Cuando conoces las fortalezas y debilidades de tus herramientas, puedes elegir. Pero eso necesita horas de vuelo y buen juicio. Mi recomendación, conozcan las herramientas, dénse el tiempo de verlas, incluso las nuevas y "no tan prometedoras": groovy al principio no era prometedora...

Al final del día, hay que usar buena herramienta, pero tener en cuenta que "no hay atajo sin trabajo" y que hasta "la tortuga corre si usted la deja". Con palabras de Engels, son los tres elementos: palabra (pensamiento), herramienta y trabajo. Entre los tres. ¡Excelente post, Isaac!

Enviado por Miguel Zúñiga González (miguel~1.mx) en septiembre 27, 2009 a las 08:48 PM CDT #
---
El unico "apunte" que le haría en este caso a la explicación del axioma es la parte de...

...Antes de decidir adoptar una nueva tecnología preguntate cómo se beneficiará el negocio con esa decisión, si en el mejor de los casos nadie(de nivel gerencial) se percatará del cambio, reconsidera tu decisión...

Simplemente para matizar que hay que tomarlo con amplitud de miras. Es decir, si el gerente no se entera pero a tí ta facilita muuuucho más el trabajo y futuro mantenimiento, entonces puede ser una decisión válida. El gerente "debería" enterarse, ya que tu lo harás mejor, pero ya sabemos como van estas cosas :).

Enviado por GreenEyed en septiembre 28, 2009 a las 04:44 AM CDT #
---
Si siguiera al pie de la letra este axioma, aún estaría usando JDBC a pelo y servlets ;-)

En principio, su enfoque me parece erróneo: tecnologías winners y losers, cuando lo que debería preguntarse es "¿que me ayuda a hacer mejor mi trabajo?", al margen de si es una "gran" tecnología o no.
Desde luego no hay que perder la perspectiva de que debemos tener en mente que trabajamos en una empresa, no en un laboratorio de pruebas...y tal vez ese sea el fondo de la cuestión.
Pero como axioma, deja mucho que desear ;-)

Enviado por Ibon Urrutia en septiembre 28, 2009 a las 01:37 PM CDT #
---
Yo creo que no lo has entendido del todo, por que precisamente lo que dice es eso, que te preguntes si realmente te ayuda a hacer mejor tu trabajo y se va a notar o si realmente la nueva herramienta que querrías es usar es simplemente una novedad y como tal cambiar a ella no te traera beneficios tangibles, aparte de estar a la última y parecer cool.

Yo lo interpreto más como "no abandones las herramientas que conoces a la primera de cambio para perseguir lucecitas brillantes, y cuando cambies una de ellas asegurate de que es para bien".

Pero si es mejor y te da beneficios, no hay nada malo en cambiar, así que no creo que sea tan radical como tu has entendido.

S!

Enviado por GreenEyed en septiembre 29, 2009 a las 05:20 AM CDT #
---
Bravo....:D muy buen post!

Enviado por Israel en septiembre 29, 2009 a las 01:15 PM CDT #
---
"To justify the risk involved with selecting new technology its benefits should be a quantum leap forward"

El radical es él ;-) Algo no tiene porqué ser revolucionario para que justifique el riesgo de cambio. De hecho la actitud de esperar lucecitas me parece la del que espera que "algo" sea revolucionario para cambiar.

Tendría que hablar con Richard Monson para aclararlo ;-), pero por ejemplo, mi cambio de jdbc a pelo a Hibernate sería muy pero que muy difícil de vender (ni fuí más rápido programando, en un principio laaargo, ni desde fuera de las tripas de la aplicación se apreciaba la diferencia) a los responsables de negocio. En mi forma de trabajo sí que fue un cambio importante, no sé si revolucionario la verdad, porque sus efectos no son apreciables más que por el que lee mi código.

Salu2

Enviado por Ibon Urrutia en septiembre 29, 2009 a las 01:25 PM CDT #


------------------------------------------------
Créditos:
La foto es de: Knotgood
http://www.flickr.com/photos/frankieclarke/3184140616/
Dilbert es una marca registada de Scott Adams.
------------------------------------------------

No hay comentarios:

Publicar un comentario