Algunos retos de los profesionales del software (1/2)

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))

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024