Ir al contenido principal

Modas y demodé (Revisited)

Cuando la programación estructurada era la que mandaba en el mundo, y submundos, del desarrollo de software, muchos fuimos los evangelizadores, cuando no creyentes, que proponíamos esta forma de programación y, aún más relevante, sus metodologías asociadas RUP, Waterfall, Etc., como la panacea, la crema y nata, de la construcción de soluciones de software.

Pasamos lustros, décadas, en esas lides. Y nos fue bastante bien.




Luego vino la programación orientada a objeto (OOP), con sus alternativas metodológicas asociadas, y lo cambió todo nuevamente. Y, como era de esperarse, no faltábamos los nuevos conversos, los profetas de la OOP y de sus métodos, filosofías y procesos. No a pocos, lo que no sonara a OOP les hacía fruncir el ceño, casi les producía arcadas pues!!

Vale decir que con la OOP también nos ha ido bastante bien como vendedores de “vaporware” (luego explico el término) que somos jajajajaja…. Y así por el estilo.
Programación funcional, Cloud, Quantum… es la lógica evolución, e involución en algunos casos, de los procesos vivos del desarrollo de software.  


En esta lista de modas que van y vienen no podía faltar la ya desgastada “metodología agile” o Agile, como suelen decirle en los ruedos de software. Esta también tuvo su momento de gloria, no conmigo, y, por supuesto, su lenta muerte.

Nunca he sido fan de la Agile, ni de la xtreme, ni nada que se le parezca. Pero no me mal interpreten, esa forma de trabajo y de desarrollo de proyectos tiene sus méritos, pero en mi caso he visto siempre como ha servido sólo para refugio de una partida de indisciplinados que la usan como excusa para el desorden y la falta de documentación. Obvio que también estos vagos mal aprendidos quieren utilizar la Agile para TODO. Cualquier proyecto, de cualquier magnitud lo quieren manejar con Agile, así no más, sin ninguna evaluación o sin tomar mayor tiempo en decidir o verificar si en verdad eso es lo más conveniente… pero claro, pararse a pensar no es Agile para ellos, NO, lo de ellos es echar código y presentar “resultados” ya, calentito, rapidito. Vamos chaval, muévelo, que lo importante es hacerlo! No cómo lo haces!... y allí es donde no me gustan a mí. Yo como arquitecto de software tengo claro que mi rol implica ser responsable de la CALIDAD, así que el COMO es un asunto que me concierne y atañe.

Repito. No estoy diciendo que las metodologías agiles, Agile, promuevan estas malas prácticas. Hablo es de los “Agileros” mal aprendidos y peor practicantes que pululan en estas tierras de la producción de artefactos de software. De esos hablo.

Ahora me salen con el Post-Agile, que claro, según sus evangelizadores, es el retorno al verdadero Agile. Al Agile sin vicios. Ummm… no sé porque esto me suena como los economistas que se gastan medio año explicando cómo va a funcionar su plan, y el otro medio año explicando porque no funcionó.

Lo mismo ocurre con los ya trillados Micro-servicios. Ahora son la moda, la panacea, la silver bullet que sirve para todo!!! En mi experiencia mas del 64% de los clientes (empresas) que están usando micro-servicios, NO LOS NECESITAN y los están usando mal!!!.  Todo se quiere resolver con micro-servicios. Los micro-servicios son la respuesta a cualquier problema de arquitectura actual. No importa que su uso implique mas problemas de los que solucionan (en casos específicos, que no son pocos).

El caso es que se ha impuesto la tendencia  de tomar decisiones de arquitectura basados en el main stream, en la moda, en la tendencia, sin contar con criterios claros, verificables y medibles. Estamos ante una tendencia a centrarnos, los responsables del desarrollo de software, en el diseño de nuevas herramientas, nuevos procesos, nuevos y mejores métodos, nuevos lenguajes, nuevos frameworks, nuevas arquitecturas, nuevas metodologías, nuevos equipos e instrumentos, nuevas filosofías, y un larguísimo etc...

Pero nos hemos olvidado de desarrollar lo esencial. Desarrollar mejores programadores. Todo lo anterior es baladí sin el adecuado factor humano. Sin la gente correcta. Sin los mejores programadores. Es la gente la que hace la diferencia; y eso no pasa de moda.


Pero bueno, de todo hay en este gran universo de la tecnología y sus recovecos. Todo pasará de moda. No se sorprenda que algunas modas vuelvan y, ojala, otras vengan para quedarse.

Comentarios

Entradas populares de este blog

El Melange todavía corre

Ese era el estribillo de un capítulo de unas de mis series favoritas de la infancia, Meteoro o Speed Racer. En ese capítulo un auto “fantasma” el X-3, aparecía de imprevisto y dejaba a todos asombrados con su rendimiento y prestaciones y volvía a desaparecer. Traigo ese episodio a colación puesto que recientemente sostuve una amena charla con un querido amigo, en la que el me manifestaba como los Mainframes habían muerto, o mejor dicho, el concepto de la computación distribuida basada en Mainframes había desaparecido. Para variar, yo no estuve de acuerdo, y le dije que por el contrario, el modelo de computación basado en Mainframes está mas vigente que nunca. Estos fueron mis argumentos:

Primeros pasos con Camunda BPM – Modelando un Proceso BPMN 2.0

Tenemos entre manos la tercera publicación de nuestra serie sobre la Plataforma de BPM de Camunda .  El día de hoy vamos, por fin, a empezar a modelar o construir nuestro primer proceso sencillo en notación BPMN 2.0. Para ello vamos a usar el modelador o editor que ya hemos instalado en nuestra primera publicación , y vamos a guardarlo en la sección de recursos del proyecto Maven Java que configuramos en la segunda publicación . Así que, como ya es costumbre, manos a las sobras…

Como configurar jBPM para usar nuestra propia Base de Datos en un sólo paso

Llevo un buen rato trabajando con jBPM en su serie 6.x, y mi opinión sobre este producto en la versión mecionada no ha mejorado para nada. Es una herramienta plena de funciones y caracteristicas avanzadas, pero tambien está llena de Bugs y es realmente inestable, sobre todo en el ambiente de modelamiento.  Así mismo, debo decir que tiene una muy aceptable API REST y que el motor de procesos y la consecuente ejecución de los procesos es estable y bastante rápida. En esta publicación daré inicio a una serie de artículos que hablan sobre ciertas configuraciones comunes e importantes que se hacen con jBPM. Hoy iniciamos con la configuración de jBPM para que use nuestra base de datos favorita. Esto tiene sentido porque el producto viene con la base de datos H2 por omisión, la cual es excelente para pruebas y evaluaciones rápidas de la herramienta, pero es completamente inaceptable en un ambiente de desarrollo, QA o producción cualquiera. Así que manos a l