[15 de 97] Elige bien tus armas, renuncia a ellas de mala gana
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:

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:
- Lenguajes:
- Frameworks:
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.
Posted at
09:52AM sep 26, 2009
by Isaac Ruiz Guerra in 97things |
¿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 (sigue...)
Enviado por Miguel Zúñiga González (miguel~1.mx) en septiembre 27, 2009 a las 08:04 PM CDT #
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. (sigue...)
Enviado por Miguel Zúñiga González (miguel~1.mx) en septiembre 27, 2009 a las 08:12 PM CDT #
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...
Enviado por Miguel Zúñiga González (miguel~1.mx) en septiembre 27, 2009 a las 08:28 PM CDT #
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 #