Cuando se estudia Ingeniería de software, es común estudiar los mitos del software y en concreto hay un mito de los gestores que dice lo siguiente:
¿Por qué debemos cambiar nuestra forma de desarrollar software, si estamos haciendo el mismo tipo de programación ahora que hace 10 años?
Evidentemente las funciones del software son las mismas (como por ejemplo, sacar los datos de una base de datos y mostrarlos en un monitor), pero los requisitos han cambiado, el software ahora controla procesos de fabricación mas sensibles, el nivel de tolerancia al fallo tampoco es el mismo, las necesidades de escalabilidad y reusabilidad no son las mismas, el nivel de seguridad, la accesibilidad, los interfaces de usuario, la multitarea, ... Porque ahora además de mostrar datos en un monitor, hay que presentar un informe con los datos, exportarlo a PDF, JPG, Excel y rtf..., Además tiene que tener la lógica de negocio publicada mediante servicios Web, integrarse con un gestor documental, actualizar los datos de 4 gestores de bases de datos diferentes, mostrar los datos en una PDA y en un Spectrum... ¡¡¡nada es lo mismo!!! Bueno! los bucles, los condicionales y la declaración de variables, apenas ha cambiado... pero evidentemente la manera de hacerlo funcionar no es la misma, ahora tenemos arquitecturas en capas, programación modular, orientada a Objetos, orientada a Aspectos, orientada a Servicios, ...
Este mito, también está en muy presente en algunos desarrolladores estancados en el "cuaternario", habilidosos con el Visual Basic 5, cuyo único argumento es que para hacer un desarrollo, es que son más productivos utilizando la tecnología que conocen y dominan. Son muy comunes comentarios del tipo: los informes vamos a hacerlos con Crystal Reports 7, que así los llevo haciendo yo siempre y nadie nunca se ha quejado. No os olvidéis: "Así se ha hecho siempre" y el "nunca nadie se ha quejado", son las frases que identifican a este tipo de desarrolladores. ¡Ojo! No hay que huir de ellos, ni obligarles a cambiar ya que su experiencia es muy valiosa cuando hay que hacer mantenimientos en entornos "Natural/Adabas"..., simplemente hay que aceptarlos y convivir... y ¿si podemos? enseñarles los nuevos entornos, metodologías, sistemas, tecnologías y herramientas, pero no imponérselos, porque de la imposición sale el rencor, y del rencor el odio, y del odio sale la desmotivación y la baja productividad.
¿Entonces? ¿Tenemos que cambiar nuestra manera de crear software?
La respuesta: Si ¿y mañana? También ¿pasado mañana? ¡Seguro!
Por todo esto doy un grito de "ÁNIMO" a las nuevas generaciones de desarrolladores, de mentes abiertas e inquietas, cuyo afán es mejorar, innovar, probar las nuevas tendencias y tecnologías, y todo esto tiene como trasfondo el aplicar procesos de mejora y calidad al desarrollo de software.