Software Lemmingineering

software lemmingineeringNota previa: Los lemmings son roedores de gran fertilidad, lo que produce frecuentes explosiones demográficas de la especie. Existe el mito de que los lemmings se suicidan en masa arrojándose al mar como parte de un mecanismo de autorregulación de la naturaleza. En su día, se hicieron populares por un videojuego para Commodore Amiga, en el que todos los lemmings seguían a uno, y si este se equivocaba de camino… todos morían.

Software  Lemmingineering, término que aparece en 1993. Dícese del proceso de seguir ciegamente técnicas que usan, o de las que hablan, las masas sin tener en cuenta la idoneidad de estas técnicas.
El autor del término, Alan Davis, presenta el hecho de que en muchos casos los ingenieros siguen a líderes mediáticos sin preguntarse si van por el buen camino. El autor ofrece varios ejemplos que en el pasado fueron casos «lemming”, o de software lemmingineering, como por ejemplo la programación estructurada, programación orientada a objetos, la madurez de los procesos software, el lenguaje de programación C, los prototipos de software, las herramientas CASE, la reutilización de software, etc.
El autor también ofrece una serie de consejos sobre cómo evaluar adecuadamente los proyectos en lugar de seguir ciegamente las modas:
– Se realista acerca de posibilidades de éxito.
– No creas todo lo que se dice por ahí.
– No ignorares otros caminos.
– No te olvides de tu objetivo.
.
.
Aunque el término es antiguo, del 93… ¿se os ocurre alguna técnica que en la actualidad esté siendo usada en modo Lemmingineering?

Javier Garzás

0 comentarios en “Software Lemmingineering”

  1. Pingback: Bitacoras.com

  2. Pues tengo que salir en defensa de la denostada Ingeniería Dirigida por Modelos, término paraguas que suele englobar la generación automática de código, MDA y un montón de técnicas, conceptos y aproximaciones relacionadas con el desarrollo de software, para responder con el clásico ”depende”: para dominios concretos y cerrados es factible el uso de modelos para generar código (y hay bastantes casos industriales por ahí). Si lo pensamois bien, llevamos toda vida usando modelos para generar código en dominios concretos: herramientas CASE para modelar esquemas de BBDD que generan el SQL que lo implementa; editores WYSIWYG para edición de paginas Web, etc. Pero lo que es más importante es que los modelos pueden ser útiles para muchas otras cosas. Por poner un escenario muy ingenieril: es completamente factible transformar modelos de análisis en modelos de diseño que combinan la funcionalidad deseada con detalles de la plataforma elegida. Luego ya podríamos discutir si generar el sistema desde esos modelos es o no factible, pero siempre nos quedará la opción de que un jefe de proyecto ”lea los planos” y asigne tareas. Por el camino, si hemos automatizado (o semi-automatizado) ese paso de análisis a diseño, hemos mejorado la gestión de la trazabilidad entre los diferentes artefactos (pues podemos producir las trazas a la vez que el modelo de salida), tenemos un proceso reproducible y, sobre todo, hemos ahorrado tiempo y esfuerzo.
    Termino con uno de los consejos de Alan Davis que cita Javier: ”No ignores otros caminos” 🙂

  3. Venga, me voy a mojar: llevar al extremo todo lo referente a las metodologías agiles, como por ejemplo, no documentar absolutamente nada (porque no aporta valor), que las metodologías ágiles con CMMI o ISO 15504 no son compatibles, etc.
    Un saludo.

  4. Pues el caso más claro ahora mismo me parece todo lo relativo a Cloud Computing. Para algunas cosas es muy útil, pero ahora parece que todo hay que llevarlo a la nube, y tampoco creo que esto sea la mejor solución

  5. Ya que se menciona…. tambien aquello de que por tener una certificación del proceso (CMMI, ISO, etc.), SIN haber mejorado la calidad, está todo resuelto (y puedo subcontratar tranquilamente)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba