Me gusta empezar mis cursos de Ingeniería del Software rememorando un hecho puntual. Y es que antes de afrontar el ‘adonde vamos’ al que dedicamos el resto del curso, considero imprescindible conocer el ‘de donde venimos’.
No me voy a retrotraer ni a la época del ábaco, ni a al-Jwārizmī, ni a Pascal, Babbage o Leibniz. Porque no me interesa la evolución de la máquina computadora. Lo relevante hoy es hablar de, quizás, el primer momento en que el trabajo con computadores fue considerado más que ciencia, ingeniería.
Estamos en los estertores de la década de los 60, en plena guerra fría. La época de las grandes computadores, los Mainframes.
Máquinas de difícil programación, de austeras interfaces, con elevados tiempos de respuesta y trabajo por lotes. Se encontraban principalmente en los Centros de Investigación y en Departamentos de Defensa. La carrera aeroespacial o simulaciones militares eran sus principales tareas. Años más tarde, Edsgar Dijkstra pone nombre en su libro “The Humble Programmer” a la problemática general en la computación de esta época: la dificultad en escribir programas libres de defectos, fácilmente comprensibles y mantenibles, y que sean verificables. Dijkstra lo denomina “Crisis del Software”
Concienciados de que los sistemas de diseño y producción tradicionales no sirven en la fabricación de algo tan etéreo como el software, científicos e investigadores de todo el mundo (el germen pudo estar en el comité de trabajo de la IFIP para el lenguaje ALGOL) se reúnen en Garmish (Alemania) en la que fue la NATO Software Engineering Conference, bajo el patrocinio de la OTAN.
Fritz Bauer, no sin cierta polémica y de manera provocativa, decide darle el nombre de Software Engineering Conference.
Uno de los editores de las actas del congreso, Brian Randell, describía de la siguiente manera el ambiente:
As I and other participants have since testified, a tremendously excited and enthusiastic atmosphere developed at the conference. This was as participants came to realize the degree of common concern about what some were even willing to term the “software crisis”, and general agreement arose about the importance of trying to convince not just other colleagues, but also policy makers at all levels, of the seriousness of the problems that were being discussed.
Las conferencias tuvieron dos ediciones, 68 y 69 y entre los asistentes se encontraban muchos pioneros de nuestra ciencia, como el físico holandes E. W. Dijsktra (¿te suena el algoritmo de caminos mínimos?), el danés Peter Naur (originalmente astrónomo y filósofo, ¿te suena la notación BNF?), el canadiense J.N.P. Hume (autor junto a Holt de varios libros de programación estructurada), el británico C.A.R. Hoare (algoritmo ordenación Quicksort, Lógica Hoare, CSP), el estadounidense Alan J. Perlis (técnicas avanzadas de programación y construcción de compiladores), el suizo Niklaus Wirth (autor de Algoritmos + Estructuras de datos = Programas, creador de los lenguajes PASCAL, MODULA-2, Oberon), etc.
Las actas recogen, principalmente, los debates producidos en cada ponencia, por lo que son especialmente interesantes.
Algunas reflexiones de la época:
Kolence: The basic problem is that certain classes of systems are placing demands on us which are beyond our capabilities and our theories and methods of design and production at this time. There are many areas where there is no such thing as a crisis — sort routines, payroll applications, for example. It is large systems that are encountering great difficulties. We should not expect the production of such systems to be easy.
Programming management will continue to deserve its current poor reputation for cost and schedule effectiveness until such time as a more complete understanding of the program design process is achieved.
David and Fraser: Particularly alarming is the seemingly unavoidable fallibility of large software, since a malfunction in an advanced hardware-software system can be a matter of life and death.
Graham: We build systems like the Wright brothers built airplanes — build the whole thing, push it off the cliff, let it crash, and start over again.
d’Agapeyeff: (from Reducing the cost of software) Programming is still too much of an artistic endeavour. We need a more substantial basis to be taught and monitored in practice on the:
(i) structure of programs and the flow of their execution;
(ii) shaping of modules and an environment for their testing;
(iii) simulation of run time conditions.
Ross: The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from.
The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.
Es interesante constatar lo joven de nuestra ingeniería (muchos de nuestros pioneros aún viven) así como la perdurabilidad y complejidad de muchos de los problemas a los que nos enfrentamos. La solución y el camino desde entonces hasta ahora sólo puede ser más ingeniería y más ingeniería.
Los contenidos de esta web están bajo una licencia Creative Commons
