Ir al contenido principal

Extremos Peligrosos

Era popular entre mis amigos de carrera la expresión “Para qué lo vamos a hacer fácil si lo podemos hacer difícil”, y es esta expresión la que resume el primero de los extremos de los que hablaré en esta publicación.
Me refiero al Sobre diseño. Entendiendo como tal la consideración e implementación de estructuras de software con características de funcionalidad, configuración, mantenimiento y usabilidad innecesarias, o totalmente prescindibles, para alcanzar un objetivo o resolver un problema.



Imagine que Ud. se encuentra almorzando plácidamente, cuando de pronto es importunado por el zumbido y presencia de una asquerosa mosca volando cerca de su plato de comida. Visiblemente molesto, se dispone a resolver el problema y dar cacería al desagradable intruso. Para ello contrata a tres consultores, con miras a que le propongan la mejor alternativa para resolver su problemática con la plaga voladora.

El primer consultor le recomienda usar simplemente sus manos y perseguir y aplastar, a modo de aplauso, al irritante enemigo volador.


Esto es directo, casi natural, aunque bastante sucio, un poco riesgoso para la salud (las mocas portan muchos patógenos) y cansón.

El segundo le propone usar un insecticida muy efectivo, de esos que matan “al instante”, y de preferencia en aerosol.

Esto parece práctico, económicamente viable y efectivo, pero genera inquietudes respecto  al estar inhalando esos venenos durante la operación del insecticida, la permanencia de estas sustancias en el aire, la contaminación que esto puede generar e incluso el cómo disponer  de estos aerosoles una vez corresponda desechar el embace.

El tercero, por su parte, le propone desarrollar un pequeño misil, una especie de mini cohete impulsado por combustible sólido ecológico, con sensores de temperatura, ruido y movimiento, que pueda ser montado en una plataforma que facilite la detección, seguimiento y eliminación no sólo de moscas, sino de otros insectos voladores en general.  Podemos incluso colocarle un chip fotográfico que permita identificar la especie del insecto a eliminar, tomarle una foto, y enviar estos datos a un sitio en la nube, IOT en acción, para obtener gráficas sobre la gestión para una eliminación efectiva de insectos. La octava maravilla pues.



Esto suena tentador y parece sacado de una película de ficción, pero es, a todas luces, un despropósito de solución. Para nada práctico e incluso de dudosa efectividad, eso sin mencionar los costos de operación y mantenimiento de tal plataforma.

De hecho, con un simple matamoscas de calidad, esos duraderos y baratos de plástico, podemos resolver nuestro problema con elegancia, a bajo costo, alta eficacia y un mínimo de efectos secundarios.
Actualmente en el mundo del desarrollo de software se está dando la tendencia que aplicar soluciones como las que proponen el primer y tercer consultor.

O contratan a unos pseudoprogramadores, parloteros y practicantes de estas mal llevadas metodologías ágiles, que odian documentar, a los que la palabra “enterprise”  les huele a vómito e incluso se los provoca, esos que su credo es  lo “rápido” y lo “productivo”, que mal oyeron de patrones de diseño y los usan a su libre albedrío y para los que el Browser o el móvil es todo el cliente que puede y merece existir. Produciendo aplicaciones en forma rápida, pero que son lentas e inseguras operando, difíciles de mantener, con nulo o escaso criterio sobre buenas prácticas de integración y comunicación y, en fin, con bajos estándares de calidad y seguridad.

O contratan  estos “NovatosExpertos” que han aprendido a usar un martillo y creen que todo es un clavo. Los que piensan que el hecho de poder hacer algo ya justifica que deba ser hecho. Los que siguen religiosamente todos los principios de diseño en POO, patrones de diseño, anti patrones, programación funcional, BI, data mining, IOT, IA, Mobile, Responsive, Alternative, Progresive, HTML 10, css 6, JS, Ultra JS, Plus Plus JS, SOA, SOAP, REST… y si pueden meter todo eso junto en un solo sistema o APP MEJOR!!!!... y terminan produciendo o, peor aún, intentando producir unos sistemas que  realmente son unos bodrios híper complejos, innecesariamente robustos, inextricablemente configurados, devoradores de recursos en todos los ámbitos y niveles, costosos de mantener y "lentos" de desarrollar.

Tan necesario es conocer las reglas, como saber cuándo romperlas.

Como diría un conocido político Venezolano “Ni lo uno Ni lo otro sino todo lo contrario”.

No podemos supeditar la calidad del software a los objetivos de productividad. Producir rápido y hacer un “Go Live” sin la menor de la supervisión y estructura, casi basados en la confianza y la buena suerte. Tampoco podemos dejar de ser productivos por empeñarnos en ADAPTARNOS a todo, PROTEGERNOS de todo y con cero riesgos. Eso es una total utopía, por demás poco rentable e improductiva.


Hay que contratar verdaderos expertos, gente inteligente y dejar que hagan su trabajo con sentido común y con la capacidad de casar los objetivos de productividad con la calidad intrínseca y esperable de las aplicaciones empresariales.

Como suelo decir, con Dios y PHP no tengo problemas, a quienes no soporto es a su club de Fans!!! jajajaja

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