En estos días de enero, voy a escribir lo que yo pediría al 2010 para mejorar la profesión (desde el punto de vista de mejorar el conocimiento que en el ámbito profesional tenemos de la misma, no voy a tocar otros como la regulación de la profesión, planes de estudio, reconocimiento, etc.). Que conste que las siguientes son opiniones personales, tras las que no hay ningún estudio empírico o riguroso (para comenzar contraviniendo una de las recomendaciones que cuento más abajo), y que se basan en mi humilde apreciación y experiencia. Opiniones que suelo comentar y contrastar en el trabajo, en clase, en charlas, etc., con la idea constructiva de mejorar (y auto mejorar) profesionalmente.
En mi opinión, como profesionales de la ingeniería del software (de la calidad software, del desarrollo software, consultoría, auditoría, etc., o como cada uno quiera llamarlo) deberíamos mejorar el que:
- Normalmente tenemos muy poca “memoria histórica”, y con ello me refiero a que algunas veces conocemos poco el pasado y la evolución de nuestra ingeniería del software. Lo que hace que muchas veces (demasiadas) veamos (o “nos intenten vender”) nuevas técnicas y soluciones donde realmente hay ideas antiguas con un cambio de nombre, o a veces nos creamos cosas que desde hace tiempo la experiencia dijo que no funcionaban (“silver bullets”) o que no apliquemos buenas prácticas que llevan ahí desde hace mucho tiempo (como comentábamos en el post del veterano ciclo de vida iterativo e incremental).
- Normalmente somos poco rigurosos a la hora de seleccionar una práctica de ingeniería del software, nos solemos basar mucho en sensaciones más que en evidencias. Bueno, esto es más un problema de la disciplina en general que del profesional en particular, pero nos afecta profesionalmente. Me refiero a que por lo general las ideas sobre qué es mejor o peor, porque aplicar esto y no lo otro, si este método de estimación es el más idóneo, si este ciclo de vida es mejor, si este modelo de procesos es bueno y nos hará competitivos, este paradigma metodológico, creer que sabemos cuántos proyectos software fallan, etc., no suelen basarse en algo riguroso (empírico, evidencias, revisiones sistemáticas, casos de estudio, etc.) y se basan mucho en sensaciones (que muchas veces hemos visto que son erróneas, aunque muchos al principio creyéramos que no).
- Normalmente las dos anteriores provocan que, normalmente, solemos ser bastante extremistas, y pasamos del blanco al negro en poco tiempo. Pasamos de UML para todo a UML para nada, de documentar todo a no documentar nada, de metodologías muy rigurosas a lo ágil al extremo, de CMMI todo el mundo a no está tan claro lo de CMMI, de todo con patrones a muchos patrones no es bueno, de modelos relacional a todo Objetos para terminar en Objeto-Relacional, de las CASE son el futuro a no valen, de siempre ciclo de vida en cascada a nunca, etc.
Como cada uno de los anteriores me da para escribir un rato, he dividido esta entrada en dos, en las que comentar el porque pienso cada una de las anteriores.
(Enlace a la parte 2 de este artículo:Algunos retos de los profesionales del software: La memoria histórica (2/2))
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Hola Javier:
Realmente buena la entrada.
Un saludo
Pingback: SEMAT: Propuestas para refundar la ingeniería software | Javier Garzás
Pingback: Algunos retos de los profesionales del software. La memoria histórica (2/4) | Javier Garzás
Javier,
Aprecio mucho tus reflexiones y que pescaste SEMAT. A mi también me parece que puede ser un parteaguas en el enfoque de la Ingeniería de Software.
Hanna Oktaba
OK gracias e igualmente Hanna. Saludos
Que buena entrada! Realmente creo que es absolutamente cierto lo que describes aquí.