Bueno pensaba que mi primer post iba a ser técnico, pero no, me han entrado ganas de soltar una «filosofada».
Desde hace ya un tiempo me he dado cuenta que mucho de los profesionales que nos dedicamos al desarrollo de aplicaciones web hemos caído en la tentación de tomar decisiones técnicas basadas en la moda. Yo suelo tener que vigilarme a mi mismo para no caer en esta trampa.
¿Quién no se ha encontrado pensando que para su nuevo proyecto va a usar las últimas tecnologías que están más de moda? Quizás es que nos aburrimos de usar siempre las mismas tecnologías o simplemente no queremos quedarnos «deprecated» y evolucionar.
Sin embargo esta forma de tomar decisiones nos puede llevar al desastre en un proyecto, si elegimos la tecnología equivocada, el proyecto puede fracasar. No nos servirá de nada decir que es lo último, lo más moderno, que era el proyecto de código abierto más popular o que el google trends decía que se iba a imponer. Al fin y al cabo somos ingenieros y debemos tomar decisiones basadas en razonamientos sólidos, evaluar coste/beneficio y ver que herramientas son las más adecuadas para nuestra misión. No deberíamos dejarnos guiar por nuestros deseos o dejarnos engañar por campañas de marketing viral.
Lo peor ocurre cuando te encuentras con algún arquitecto o programador o incluso cliente que ya ha transcendido su etapa de víctima de la moda y se ha transformado en un fanático. Algunas citas textuales de fanáticos que me he encontrado: «pues el framework X es el mejor» o «eso que haces es una mierda, es mucho mejor la tecnología Z» o la última que escuché, «es que el framework XYZ es el que hace todas las cosas chulas». Siempre termino preguntándoles ¿Por qué? y ellos responden «¿No lo sabes? Todo el mundo lo usa…»
Usemos las herramientas adecuadas para cada tipo de problema.
No seamos víctimas de la moda, sino profesionales.
«Al fin y al cabo somos ingenieros y debemos tomar decisiones basadas en razonamientos sólidos, evaluar coste/beneficio y ver que herramientas son las más adecuadas para nuestra misión» …. Ese es un razonamiento que no es comercialmente aceptable. La realidad es que se proponen cosas que suenen muy cool y den a tu propuesta un halo de modernidad y estandarización para ser más atractivas para el que compra. La gente que toma decisiones no gusta mucho de ser creativa.
La reflexión que yo me hago muchas veces es: si yo fuera el propietario de la empresa, y tuviera que desarrollar los sistemas, ¿qué tecnología usaría? Probablemente pocas de las que estamos vendiendo/implantando hoy en día.
En realidad probablemente me daría igual la tecnología e iría a un modelo SaaS: yo quiero que mi aplicación me proporcione las funcionalidades XYZ, con mi look&feel corporativo y de acuerdo a estos SLA’s. ¿Por qué de de preocuparme de si es Java, PHP o .Net?
No puedo estar mas deacuerdo, y con vuestro permiso, creo haber encontrado un patrón que se viene repitiendo, al que llamaré «LA SECTA»:
Han aparecido a lo largo de estos años unos cuantos «gurus del software» (Craig McClanahan, Gavin King, Rod Jhonson, Martin Fowler, etc…). Se trata de ingenieros del software que se han enfrentado a un problema, lo han solucionado y comparten su trabajo con la comunidad de forma mas o menos altruista, en forma de articulos, libros, frameworks,etc… lo que les da prestigio, fama y dinero de forma casi siempre merecida.
Ellos no son el problema. (al reves, creo que debemos agradecer su ayuda)
El problema es «la secta» que brota alrededor suyo, y de la que se convierten de forma involuntaria (o no), en lideres supremos. Sus seguidores dogmatizan y convierten en axioma, cada palabra suya (cuando no la malinterpretan totalmente), y esgrimen el nombre de su maestro como un arma arrojadiza capaz de fulminar a cualquiera que les lleve la contraria…
«Las Sectas in Action»:
– «Los Fowleretes»: puedes oir en una reunión «es que yo me he leido a Martin Fowler» a un tipo que defiende que empaquetar las aplicaciones como módulos funcionales no puede funcionar en un entorno de IC. ¿Que tendrá que ver? Pues con esta frase se consigue el respaldo de esos asistentes que sin saber mucho de IC si reconocen el nombre del guru.
– «JPA Taliban»: ¿que ha pasado para que una especificación como JPA (y sus implementaciones), que lleva en sus siglas la palabra «PERSISTENCE» se convierta en el corán de las aplicaciones web actuales? ¿Me he vuelto loco o no es bueno encontrarse un POJO que atraviesa todas las capas desde la BBDD hasta la vista? ¿Que lleva a un arquitecto a diseñar un modelo de datos JPA y usarlo para hacer un volcado masivo de datos entre dos BBDD? Ya se, como basta con anotar las clases y se genera todo solo…..
Quien más quien menos todos tenemos nuestras propias experiencias religiosas con estas «sectas softwarianas», os invito a compartirlas para ir completando el patron….
Y para temimar elevemos aqui una oracion por las modas difuntas:
– el añorado Visual-Age… recordemos su pintor de GUIs swing y su generación de codigo arcano, todavia quedan «arqueros» por el mundo que afirman que saben programar.
– el amado Struts…. todos el mundo empeñado en hacer de el un Standard. Y cuando por fin aparecen las releases que funcionan llega la web 2.0 y se lo merienda….
– los incomprendidos EJBs… unos adelantados a su tiempo, que mal uso hicimos de ellos…
– etc, etc, etc…
Juergas sencillamente tu comentario me ha parecido sublime. Deberías desarrollarlo un poco mas
Muy bueno el post y los comentarios, impresinante lo de los «Fowleretes». Mis dos céntimos de euro: teneis razón en todo, las modas, las sectas, los gurús, pero yo introduciría otro factor, la inmadurez de las tecnologías en sí.
En realidad no hay una tecnología perfecta ni de lejos, todas tienen sus peros (y sus bugs), ninguna resuelve el 100% de problemas ni necesidades, ni son tan ampliables como nos gustaría, ni la documentación, ni el soporte, etc, etc..
Por muchas ganas de cambio y de moda que tengamos, si estuviéramos totalmente cómodos con la tecnología nos aguantaríamos con lo que tenemos, pero si no lo estamos y viene algo nuevo, más cool, más bonito ,mejor el cuerpo te pide cambiarla, que sí, que en el fondo es una huida hacia delante y en muchos casos acaba en fracaso… pero en algunos otros casos es entendible la búsqueda de algo mejor.
Estoy con JuanFri.
¿Que sería de nosotros si hubiéramos pasado por completo de la moda más arrasadora de la última década?, es decir: ¡JAVA!. ¿Seguiríamos dandole al C++?, ¿al Cobol?, ¿Clipper quizás? (VisualB@s#~ ni lo nombro, que se me indigesta el post).
Todo esto evoluciona muy deprisa, así que no nos queda más remedio que ser unos «Fashion Victims».
Jacor, si sale una nueva tecnología yo voy a trastear con ella, si no no podré aprenderla y ver donde viene bien y donde no aplica.
Ahora usarla sin conocerla, de golpe en un proyecto, no. Tengo que tomar decisiones racionales y para eso hay que aprender y experimentar, pero como decía mi abuela, experimentos con gaseosa.
Por otro lado la forma en que trabajamos no nos permite tener tiempo para experimentar. Todo arquitecto debería poder disponer de un 10% de su tiempo a investigar, a lo mejor asi no hay tanta tentación de experimentar en un proyecto.
Por supesto, hay que conocer primero la tecnología antes de intentar adoptarla a lo grande.
Yo me refería a que es imprescindible que nos dejemos tentar por las modas tecnológicas. Nunca rechazarlas sin mas por el hecho de ser la moda del momento (me consta que hay gente que se escuda en esa actitud «rebelde» contra todo lo «cool» para justificar su desidia en esto de la evolución). Como poco hay que probárselas, mirarse al espejo y ver que tal sientan.
Y ya que hablas de la disponibilidad de tiempo para I+D, creo que un 10% es ridículo para un perfil de arquitecto. Esa cifra debería ser imprescindible para cualquiera que se dedique a esto de las TI. Un arquitecto debería dedicar una parte mucho más importante de su tiempo a esos menesteres. Venga, ¡me tiro al barro!: creo que lo ideal sería dedicar una tercera parte del tiempo. ¡Dios!, ¡sería maravilloso!.
Ya que estamos, aprovecho: ¡Reducción de jornada para arquitectos ya!. 😀
¿Y qué es lo que se entiende por ARQUITECTO?
Llevo años oyendo esta palabra y con cada persona que me encuentro piensa una cosa diferente.
Sin embargo es curioso, pero en las capas gerenciales sí que se tiene una visión única de lo que es:
Arquitecto = desarrollador x 4
Cuando hay un problema en un proyecto (generalmente retrasos en las fechas) el JP de turno (o sus responsables) siempre se le ocurre la maravillosa idea de ‘pues enviemos a Futano que es arquitecto y nos soluciona esto en dos patás’
¡Mal! Como ex-arquitecto (lo confieso) me niego a que se piense de ellos como un ‘bombero-superprogramador-arreglalotodo’.
En fin, creo que esto merece su propio apartado.
Demetrio,
Cierto, esa ecuación de arquitecto = desarrollador x 4 es muy común
En uno de los próximos post pienso hablar de ésto, lo que yo llamo la metodología del bombero-torero.
En cualquier caso pienso que un arquitecto se hace, a través de la experiencia, y debe saber programar. Tened cuidado de no encontraros con el temido «arquitecto pintor» y sus «cajitas».
Tras la parrafada anterior, en la que no era políticamanente correcto con las «fantasmadas tecnológicas» pasadas, actuales y venideras, pensaba que me ibais a excomulgar por hereje; para mi sorpresa no ha sido asi; algunos, los más «malos», me animais a que recaiga…. pues ea!:
Mi intención era dar la alerta sobre una situación que tiene tanto que ver con las personas como con la tecnología. Sobre las personas no voy a descubrir nada, somos simplemente incorregibles. No tiene uno bastante con contenerse a sí mismo para no meter la pata, sino que tenemos que no dejarnos arrastrar por los demás…. puff puff.
Pero hablando de las tecnologías software y al hilo de la respuesta de Juanfri sobre la inmadurez de las mismas, empezaré con una frase genial de un amigo argento:
«No ha existido, no existe, ni existirá jamás, software a prueba de boludos»
Él se refería a los usuarios, pero yo creo que también nos aplica a los desarrolladores. Mi opinión es que la tecnología puede estar todo lo madura que se quiera, que si algún catacrack hace mal uso de ella y lo cuelga en un post, a partir de ese momento se puede establecer uno de los muchos y muy dudosos «standard de facto».
A continuación, como terapia personal y para seguir mojandome con ejemplos vividos en mis propias carnes, os dejo una perla sobre una tecnología por definición buena pero en muchos casos totalmente pervertida:
«Las Taglibs Superhormonadas»
Las taglibs surgen para poder ampliar el lenguaje de etiquetas de JSP, simplificándolas en lo posible al evitar los snippets, y en su primeras versiones solo se pueden implementar con clases java que hereden de TagSupport.
Como eran clases, algunos se emocionaron, se les olvidó que son componentes de la vista, y les otorgaron superpoderes de acceso a las capas de control y/o de negocio:
«… y así en tiempo de ejecucion de la JSP tus taglibs invocan de forma independiente servicios de negocio para montar su modelo… ooooh!!! que potencia!!!….»
Ignorante de mí, en otra de mis «muy productivas» reuniones, me atreví a afirmar que las taglibs solo están ahí para recoger datos ya existentes en alguno de los contextos web y «pintarlos». Al oir esto el campeón del software de turno tomó la palabra:
Campeón — ¿es eso correcto? – preguntó con cara de estar pensando fuertemente.
Juergas- correctísimo – afirmamos tajantemente en un intento vano de esquivar una discusion inutil
C — pero nuestras librerias de tags funcionan asi… son «estandar»…
Por no decir que sus librerias están mal, y ganarnos un «amigo», intentamos hacerle ver los problemas de usar así las taglibs:
J — Y con ese «standard» ¿En qué estado queda el modelo de tu aplicación después de ejecutar la JSP? ¿Estas seguro de que lo tienes controlado?
C — No se, en este caso se supone que no afecta a datos importantes….
J — ¿Y como de reutilizables serían esas taglibs en otras aplicaciones?
C — No hemos contemplado que sean reutilizables, pero parametrizando algunos campos….
J — ¿Y Que pasa con la transaccionalidad? en las JSPs ya has dejado atrás la lógica de aplicación, y resulta que vuelve a ser invocada!
C — muy facil, la ponemos al nivel de la request tal y como te dicen que hay que hacerlo si usas Hibernate en el foro «somoslomas.com»
J — ¿Harías eso mismo desde el código de una JSP?
C — No, no claro….
J — ¿Y que diferencia crees que hay entre una taglib y una JSP?
… aquí esta conversación fue interrumpida… y como no eramos ninguno un gurú, ni los invocamos, ni todavía he escrito mi libro (un par de post mas como esto y lo habré logrado), nuestro amigo fue poco receptivo y no se retomo el tema ni se decidió nada al respecto…
Nota: debo reconocer que si detecto estos malos hábitos de uso de las taglibs es porque en su día hice algo parecido y sufrí las consecuencias en forma de horas extra….
Por ultimo y de nuevo os animo a contar aqui vuestras batallitas…. os aseguro que «desestresa» bastante y es mas barato que ir al psicologo….
Querido Juergas, precisamente la intención de mi post era provocaros. La verdad es que yo me cruzo con muchos «gurus» de la moda, víctimas y fanáticos. Lo que realmente me preocupa del tema es que nos proclamamos ingenieros y terminamos tomando decisiones de la misma forma que lo haría una persona que entra en una tienda de ropa o en en el peor de los casos, en una secta. Y lo peor de lo peor es que esta «práctica» está bien vista. Me entristece que una discusión técnica termine pareciendo una pelea entre fanáticos religiosos.
Lo de las «taglibs hormonadas» y el «session in view» es un clásico. Se ve que a la gente le cuesta entender el MVC y SOC (Separation Of Concerns), y eso que ya se conocían a principios de 1980 (que en informática es lo mismo que decir «desde siempre»)
En mi caso me he encontrado últimamente con el caso del «Widget RIA con Esteroides». Claro ejemplo es la supertabla que ordena por cualquier criterio conocido, sabe sacar los datos del servidor, formatearlos, controlar la paginación, y todo esto para cualquier aplicación imaginable. Afortunadamente siempre tengo a mano mi medallita del MVC (hecha en silicio del bueno) para evitar la tentación del mal.
El problema de fondo es que la gente se cree el marketing de un framework, producto o tecnología, y no aplica ni sus conocimiento ni su capacidad de raciocinio. Quiero creer que es esto que digo y no que la gente no tenga raciocinio o conocimientos…
Por cierto, se os olvida una moda muy chula, la del «Portal» 🙂
Estimado amigo Juergas,
Una vez mas enhorabuena por el comentario. Te animo (de nuevo) a que escribas mas seriamente en un blog (o en el blog de notas) y publiques todas tus «batallitas».
Tu historia de las JSP y las taglibs me recuerda a uno de los proyectos en los que participé. Allí las JSPs y taglibs eran consideradas elementos demoniacos, el que las usara iba directamente al infierno. En su lugar,se hizo un «framework» en el que se pintaba el código HTML en clases Java (si, si clases Java) las cuales se encargaban de «escupir» el String con el resultado html, concatenando cadenas de forma superoptimizada . Todo esto era invocado en un maravilloso servlet!
Genial verdad? En este caso fue producto de la falta de conocimiento de las personas «responsables» de la arquitectura. Venían de un mundo cobol. Debido a esto, otro pequeño detalle era quetodo el framework estaba montado con clases con métodos estáticos (siiiiii, todos absolutamente todos era static)…..
Aunque este post trata sobre las tecnologías de moda, el desconocimiento de las tecnologías provoca herejías si cabe iguales que su mal uso.
En fin, si no lo cuento reviento…Ay, es verdad, que a gusto que se queda uno…y gratis.
Por cierto, aprovecho este post para lanzaros una pregunta:
Anotaciones SI? o Anotaciones no?
HombreCurso, no nos tientes con tus anotaciones.
Anotaciones para añadir metainformación, SI
Anotaciones para configurar, NO
Creo que se ha abusado de ellas porque son cool, están de moda.
Pero las anotaciones simplifican gran parte de la complejidad de muchos frameworks.
Por ejemplo, hacer una aplicación con Spring MVC con anotaciones es facilísimo…
Sí, ya lo se, no me crucifiqueis ya se que hacer cosas de configuración en una clase Java dedicada a código, conceptualmente puede ser incorrecto pero…
No creeis que compensa? Me remito al ejemplo de JPA:
Suponemos que no somos JPA Talibanes, y que utilizamos una buena separación de lo que son DTOs de lo que son Beans de Vista y bla bla bla….
Que problema hay en utilizar @Entity? Me facilita la vida, ahora ya no tengo que hacer un complejo Entity EJB para hacer el acceso a base de datos…utilizo un POJO Anotado!..it isn’t cool…it’s easy!
@Entity es metainformación y por lo tanto válido, tu POJO es desde un punto de vista lógico una entity esté en el entorno que esté.
Ahora bien, usar anotaciones para hacer el mapeo objeto/bbdd es configuración, ya que esto depende del esquema de bbdd y el esquema depende de que bbdd estes usando si es que tienes una base de datos relacional…
Tu aplicación debe ser portable, si cambias de entorno, o de bbdd debes poder configurarla sin necesidad de tener que cambiar fuentes y recompilarla !
@HombreCurso
Tu batallita me resulta familiar, ¿nos conocemos?
@Juergas
Eres un incendiario, ¿que te pasa, que no has leido nunca a Martin Fowler? Hay gente que sabe más que tú, que escribe libros y nos hace la vida más fácil y bla bla bla. Escribe ese libro que dices, hazte famoso, y podrás tener un séquito detrás alabando tus teorías.
Cada día tengo más claro que quiero convertirme en un tunicado….
Quizás nos conozcamos!!Yo también tengo un poster de Martin Fowler en mi habitación. Vamos que siguiendo a nuestro bueno amigo @Juergas:
@Fowlerette
public class HombreCurso{..}
Como sigais mencionando en vano el nombre de Martin Fowler os va a caer una maldición gitana 😉
Madre mía, menudo hilo de comentarios que se ha formado, nos gusta más la polémica que probar un nuevo framework!
Ya que se ha nombrado tantas veces, lo que siempre me he preguntado del amigo Fowler es porque tiene una foto tan grande suya en la web, me lo imagino pensando «soy feo pero estoy podrido de pasta, tengo más fans que Ricky Martin y mi mujer está tremendamente buena»
Eso sí que es una reacción de la buena!!
Y veo por aquí claras caras conocidas, cada una con su estilo, jejeje.
Yo me confieso además de Fashion Victim (aunque investigándola antes), Version Victim: Dícese de aquel que apenas tarda en actualizar en sus sistemas la versión de una herramienta una vez que se publica!
Cada uno decide. Para mi, lo de las modas tiene algo que ver con la propia actitud hacia la vida:
¿Me interesa cómo funcionan las cosas por dentro?, ¿Prefiero seguir siempre la manada?,
¿Me realizo con algo meramente superficial?
Luiso tiene razón. Si el problema es tuyo pero no es algo privado o importante para tu vida, llegas a SaaS.
Pero si sientes una vocación hacia el software, sientes casi todo como muy importante y tuyo: te interesa cómo funcionan las cosas por dentro, no sigues siempre la manada (y nunca ciegamente) y no soportas temas superficiales. Simplemente no piensas en modas.
Otro tema es la influencia desde fuera – desde el sistema emergente de la sociedad global. Si tienes experiencia, no te suele afectar tanto la opinión de otros desconocidos.
Sin insultar a nadie, pero yo veo las modas muchas veces como un resultado de esta conversación:
Dijo el rey al cura: «Tú, mantenlos tontos, yo los mantengo pobres. Así tendremos una larga vida.»
[…] } La idea para este post me la dio un comentario en el post de víctimas de la moda, alguien dijo que un arquitecto era visto como 5 programadores por parte de los gestores de […]
(Envié este comentario pero me dio un error extraño al enviarlo y me da la sensación que al final no se llegó a enviar correctamente, por lo que lo vuelvo a enviar, disculpad si resulta que finalmente saliera duplicado…)
Hola, he conocido hoy tu blog, y aunque sé que son artículos que tienen ya algunos años, son interesantes. Quería aportar mi punto de vista sobre este tema que habéis estado hablando aquí.
Personalmente sufro también muchas veces el tema de las modas, cuando una persona con poder de decisión decide imponer el uso de ciertas tecnologías, herramientas o lenguajes para el desarrollo de un proyecto, simplemente porque ha oído que ahora es lo que se lleva, o imponer ciertas metodologías a todo (Scrum hoy en día está de moda y se aplica a todo, tenga o no tenga sentido).
Pero por otro lado también me pongo en el lado de quien toma a veces estas decisiones ya que no siempre las cosas son blancas o negras, puede haber muchas otras variables con mayor o menor importancia para según quién las evalúe.
Si yo tengo que gestionar un proyecto y voy a tener que buscar a gente, igual la tecnología AAA es la más adecuada para ciertos aspectos, pero resulta que es mucho más minoritaria que la tecnología BBB que está de moda, que por ello sin embargo tiene montones de usuarios hoy en día y de profesionales trabajando en ella, por lo que si elijo la tecnología AAA lo mismo se me complica mucho encontrar un equipo al que contratar (y me sale caro) mientras que si cojo la tecnología BBB sé que no voy a tener problema en encontrar ese equipo y posiblemente a un coste menor.
¿Qué es mejor hacer?, pues dependerá de lo que busque cada uno, igual el factor coste es para él más importante que el factor optimización (entendiéndose por elegir lo más óptimo) y prefiere simplificar y abaratar el formar ese equipo y el asegurarse el tener un amplio abanico de profesionales disponibles, cogiendo la tecnología BBB de moda, antes que coger la AAA que le limita más en este sentido, y que si un día se le va una persona del equipo lo mismo se tira meses buscando a alguien que pueda sustituirlo.
Sin contar que en informática una misma cosa se puede hacer de muchas maneras, una puede ser más barata a costa de menos óptima, otra más sencilla a costa de menos versátil, otra puede ser más legible, otra más rápida… y encontrar una forma que sea la mejor en todos los aspectos no siempre es posible, por lo que toca elegir qué prefiere cada uno. Yo a veces hago código más legible a pesar de saber que no es el más óptimo, pero doy prioridad a que quien lo tenga que leer en un futuro (yo mismo podría ser ese alguien) lo entienda fácilmente, antes que hacer un código optimizado que luego cueste entender. Pero si lo ve alguien que dé prioridad a la optimización, pensará que vaya mierda de código porque no está optimizado.
En definitiva, creo que muchas decisiones, mientras estén argumentadas y te lleven hacia lo que buscas, pueden ser igual de validas, sean o no acordes a la moda, e incluso en una ingeniería a veces tienen cabida los gustos personales como variable o argumento a considerar.
Scherzo