Esta nuestra profesión, aunque sea considerada joven, entiendo que con respecto a otras, ya tiene los suficientes años como para disponer de ciertos mitos, leyendas y misterios en lo que refiere a sus orígenes y en cómo muchos conceptos antiguos han llegado hasta nuestros días.
Además, no es que existan numerosos y rigurosos estudios sobre los orígenes, lo que ha creado que, aun más si cabe, con los años muchos conceptos hayan transformado su significado original, otros hayan sido atribuidos a autores que no los crearon, otros hayan tomado más credibilidad de la que nunca debieron tener, tomándose como dogma, etc.
Hoy te quiero dejar una selección de tres, tres mitos y leyendas de la antigüedad de la ingeniería del software, que han llegado muy distorsionados hasta nuestros días.
El mito y misterio del origen de la llamada “crisis del software”
Si hay una conferencia sobre la que se han cargado un montón de males, orígenes, mitos y leyendas, es la primera, la primera conferencia sobre ingeniería software, la del 68 (te dejo más datos en un post de hace tiempo, 2013, así fue la primera conferencia sobre ingeniería del software), la de la OTAN (hoy la conocemos popularmente como 1ª conferencia sobre ingeniería software, si bien no se tituló como conferencia “sobre ingeniería software”, por lo que dudaría de si este nombre es el correcto).
Ciertamente, de aquella conferencia vienen muchas orientaciones que hoy consideramos erróneas, pero no tantas como muchas veces pensamos. Y una de ellas es el concepto de la famosa “crisis del software”, que frecuentemente se dice que fue un concepto originado en aquella conferencia sobre “ingeniería software”.
Como bien analiza el libro The Leprechauns of Software Engineering, y más profundamente aún el artículo de Tomas Haigh, ninguno de los participantes citados en las actas de aquella conferencia de la OTAN se refieren a una «crisis del software», con ese nombre. La frase «crisis del software» aparece exactamente una sola vez en las actas.
Según Haigh, parece ser que fue Dijkstra el creador del término, que se menciona por primera vez en 1972, varios años después de las conferencias de la OTAN, cuando recibe el premio Turing y da su discurso sobre “el programador humilde”. Aquí puedes encontrar dicho discurso, donde software crisis aparece por primera vez en…
“But instead of finding ourselves in the state of eternal bliss of all programming problems solved, we found ourselves up to our necks in the software crisis! How come?”
El mito y misterio informe de Standish Group, el llamado Chaos Report
Hace un montón de años, en 2008, le dedicque un post enterito a este mito, te lo recomiendo si quieres ampliar información. Es la típica estadística que muestra de manera dramática lo mal que esta el sector y con la que suelen comenzar gran cantidad de presentaciones sobre ingeniería del software, el informe de Standish Group, el llamado Chaos Report. De hecho, dicho informe es conocido como la estadística de referencia más citada en ingeniería software.
Dentro de estos informes Chaos el más famoso es el publicado en 1994, que en muchas ocasiones ha sido utilizado para apoyar la llamada “crisis del software”, y que muestra, de manera resumida, que: El 31% de los proyectos se cancelaron, el 53% tenían deficiencias, el 16% fueron un éxito y de media los proyectos tienen un 189% de sobre costes.
No entro mucho más porque ya le dedique un post, si lo lees, sobre todo, lo más polémico es de dónde salió ese 189%.
Dicho informe ha sido cuestionado en numerosas ocasiones, que han sembrando la duda al respecto, sobre todo por su inconsistencia con otros informes de la época y por el poco conocimiento sobre como se elaboró el informe Chaos (criterios para la selección de proyectos, medición del sobre coste, etc.).
Populares estudios críticos son los de Glass o Infoworld, que lo cita en su especial sobre los mitos de las tecnologías de la información como el “IT Myth 5: Most IT projects fail”.
El mito y misterio del origen y padre del ciclo de vida en cascada
También le dediqué en su día, en 2014, un post, aquel de el verdadero origen del ciclo en cascada, sobre cazas de brujas y errores históricos.
Aquí el caso es que lo que hoy todos conocemos como ciclo de vida en cascada, la primera vez que alguien lo describió fue en un artículo llamado “Managing the Development of Large Software Systems”, escrito en 1970 por el “popular” y “señalado” como culpable… Winston W. Royce.
Pero, si te descargas el artículo, que está en abierto, es en la página 2 donde aparece el famoso diagrama del ciclo de vida en cascada, he ahí su primera descripción, hito histórico. Desde aquel momento, Royce se llevó todas las culpas por haber llevado este ciclo de vida, al “maligno”, al mundo del software.
Pero realmente el pobre Royce, no defendía tal modelo, es más, ni siquiera lo llamó “cascada”. El nombre de “cascada” se lo pusieron en el 76, Thomas y Thayer, en el artículo “Software Requirements: Are They Really A Problem?”. También lo puedes descargar en abierto y ver en la página 2, párrafo 2, otro hito de nuestra historia, un hito de la gestión de proyectos software… la primera aparición de la palabra “cascada”.
Al contrario, Royce, en la línea justo debajo de su dibujo del ciclo de vida “en cascada” escribe “but the implementation described above is risky and invites failure” (pero la implementación de este concepto es riesgosa e invita al error).
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023