El Mito del Campo de los Programadores

¿Es consciente de la generalizada opinión pública sobre nuestro campo: Informática igual a programación? Debería serlo. Está fuertemente asentado en películas, novelas, informativos, anuncios, discursos políticos, pensamientos de otros científicos e ingenieros y en las mentes de futuros integrantes de nuestra profesión. Es más, mucha gente cree que la informática es sólo un campo de la tecnología sin mucho de ciencia e ingeniería en sí misma; que la palabra “ciencia” en nuestro título1) es inmerecida. ¿Desea saber por qué esto es así y cómo puede ayudar? Siga leyendo.

La historia de que la Informática es igual que la programación es vieja. A mediados de los años ochenta llegó a ser tan molesta que la delegación de computación del ACM/IEEE-CS se propuso deshacer ésta opinión. Su informe, La Computación como una Disciplina, representó el campo con la ayuda de una matriz de 9×3, mostrando nueve áreas principales y tres procesos (teoría, abstracción y diseño). A la programación la pusieron como una subparte del componente de diseño de la mayoría de las nueve áreas, especialmente algoritmos e ingeniería del software. Su modelo se convirtió en la columna vertebral de la recomendación del Curriculum '91 de la ACM. Pero la vieja historia perdura.

En los últimos años, la historia se ha convertido en un estorbo mayor. Muchos informáticos no están algo molestos, están enfurecidos. Muchos trabajos de programación e ingeniería del software se perdieron en la crisis que siguió al desplome de los negocios de Internet en el 2001. Sin embargo muchos trabajos no se restablecieron en la recuperación sino que fueron liquidados en tanto que las empresas se aprovecharon de las tasas laborales más bajas en otros laborales en otros países. [esta frase hay que cambiarla entera…]. Los contratos en informática e ingeniería se redujeron un 30% entre 2002 y 2004. Las tasas de caída de las incorporaciones fluctuaron entre un 35% y un 50%. Las mujeres siguen prefiriendo otros campos.

Los futuros estudiantes se preguntan: «Si el corazón y la esencia de la computación (programación) está siendo subastada al más bajo postor extranjero g¿Cuál es mi futuro?» ¿Qué les decimos? Bill Gates, de Microsoft, en un esfuerzo para persuadirlos a elegir …(computing majors)… [averiguar cómo traducir eso…], hizo una gran visita a varias universidades americanas a principios de éste año para contarles a los estudiantes los numerosos trabajos en computación que nunca migrarán al exterior.

¿De donde viene la historia de la programación? ¿Por qué perdura? La respuesta corta es: Estamos recogiendo lo que hemos sembrados. Se ha arraigado en la lógica que los ordenadores necesitan programas para funcionar y, por lo tanto, esa programación es fundamental. Esta lógica impregnan nuestros planes de estudios y cómo la gente aprende Informática. Nuestros primeros cursos son de programación. Muchos proyectos de curso suelen ser llamados “proyectos de programación” –no proyectos de diseño, proyectos de bases de datos, proyectos de redes o proyectos de gráficos. Cuando se forman opiniones sobre su campo más importante en el colegio, los estudiantes echan un vistazo a sus cursos de Informática y ven… programación. Aquellos interesados en situaciones avanzadas ven… programación orientada a objetos con Java. [Media outlers(=salidas)] cuentan muchas historias sobre informática. ¿Quién creó y distribuyó la criptografía moderna de clave pública? Programadores. ¿Quién programó a la mayoría de microprocesadores de su coche? ¿Quién creó el software que analiza tu examen MRI2)? ¿Quién creó el navegador Web? ¿Quién escribió el código SETI que ayuda a buscar inteligencia extraterrestre mientras tu ordenador está sin hacer nada? Todo programadores. ¿Quién irrumpe en los sistemas? Hackers, una secta de hábiles programadores. ¿Quién escribe los virus o los gusanos? ¿Quién provoca los ataques de denegación de servicio, sabotea páginas Web o secuestra ordenadores para dejarlos a los spammers? Más programadores hábiles. ¿Quién cometió el error que provocó que una prueba en Marte fracasase? Un programador. Están en todos lados, [gang]. Lo bueno y lo malo, todo hecho por programadores.

Muchas personas no están observando las historias de los jefes informáticos (computer architects), ingenieros de redes, ingenieros de bases de datos, especialistas gráficos, jefes de software, diseñadores de software, expertos en seguridad, simuladores, los encargados de hacer Realidad Virtual, los expertos en supercomputación, los robóticos, etcétera. [revisar todos estos nombres de campos de la informática, analogías en castellano/España]. Todas las historias que se están contando como hechas por programadores. Bill Gates está alarmado por ésto. Nosotros también deberíamos estarlo. ¿Cómo deberíamos cambiar ésto? Ofrecí una solución en mi columna de noviembre de 2003, “Los Grandes Principios de la Computación”. El esqueleto de grandes principios [que mal suena esto…] es una nueva descripción de nuestro campo que acentúa nuestros principios científicos e ingenieriles y nuestras cuatro prácticas principales. Nuestros principios fundamentales están en el diseño y mecánica de la computación, coordinación, recolección y automatización. Estos principios no fueron tomados prestado desde otros campos; los científicos informáticos los desarrollaron. Nuestras cuatro prácticas principales son programación, ingeniería de sistemas, modelado e innovación. Mirar en éste mundo a través de una ventana de programación es como mirar una construcción a través de una abertura en una barrera: no puedes ver demasiado. Nuestro reto es adoptar una gran visión del campo que muestre la ciencia y no confunda ciencia y práctica.

La Programación No ha Sido el Problema Central de la Industria durante Mucho Tiempo

Cuando el campo era joven (en los años cincuenta) y más pequeño, la preocupación principal era crear sistemas computacionales. Los dos trabajos más comunes eran jefe programador y programador. Muchos líderes en la industria vieron cómo de intensivo era el trabajo de programador y preguntaron a las universidades para instruirlo desde el principio y así sus graduados podrían tapar puestos de trabajo de programación. El principal foco intelectual estaba en la lógica del hardware y el software, y en la principal destreza profesional era la programación. La programación fue considerada como el único medio posible para traducir conceptos informáticos en realidad funcional [no suena nada bien…].

En 1968, la OTAN patrocinó una reunión histórica de los líderes académicos y de la industria para discutir lo que llamaron la crisis del software. Vieron como los sistemas de software fueron creciendo en tamaño y complejidad y comenzaron a hacer aplicaciones donde los fallos pudieran costar vidas y arruinar negocios. Creían que la noción esencial detrás de la programación –que los programas implementan funciones matemáticas– no podría hacer frente a la complejidad y opacidad de las grandes y verdaderas aplicaciones críticas. Creyeron que los futuros desafíos del desarrollo del software serían idear procesos propios de la ingeniería para traducir requisitos complejos a sistemas de trabajo para ocuparse de aquellos requisitos confusos y que variaban, para determinar y manejar riesgo, para sistematizar el proceso de localizar y eliminar errores, para organizar y manejar a equipos de programadores y para satisfacer a los clientes. Fueron a buscar la creación de una nueva disciplina: ingeniería del software.

Una de las inefables conclusiones de esa reunión fue que lo que estabamos enseñando bajo el título de programación era inadecuado y que sería necesario un nuevo sistema de acercamiento a la ingeniería.

Diecisiete años después, Fred Brooks recogió los avances obtenidos de la ingeniería del software en su crítica, “Ninguna bala de plata” [1]. ¿Qué distancia habíamos avanzado hasta llegar a construir sistemas fiables y seguros? Él mantuvo que el obstáculo principal de esta meta fue, y siempre lo será, el complejo comportamiento de los sistemas grandes de software. Mucho del trabajo de la ingeniería del software –lenguajes, herramientas, ayudas gráficas, ayudas de depuración, programación estructurada, automatización del código y similares– había sido impresionante. No obstante, dijo, éstas tecnologías sólo demostraron un mínimo de utilidad frente al principal problema del desarrollo del software: conseguir un aprovechamiento intelectual en la complejidad de la aplicación. Concluyó diciendo que la producción del software es, inherentemente, un problema de talento-diseño que sólo puede ser resuelto por determinación para identificar y educar grandes diseñadores.

Brooks no dijo “educar grandes programadores”; su preocupación estaba en el diseño de los sistemas. Ahora entendemos que el talento y la habilidad individual tienen un efecto enorme en la calidad de un trabajo de desarrollo de software: los buenos desarrolladores son con frecuencia diez veces más productivos que los principiantes, y los más hábiles pueden serlo 50 veces más. ¿Es la gran productividad un regalo concedido sólo a unos pocos o es una habilidad que puede ser aprendida? Brooks invitó a la comunidad a realizar un esfuerzo en común para enseñar a los programadores cómo ser grandes diseñadores y expertos desarrolladores de software. A pesar de los muchos elogios y fascinación por ésta idea, pocos han respondido a su desafío.

En 1989, Edsger Dijkstra, uno de los gigantes de nuestro campo y un fiel apasionado del concepto matemático de los programas y la programación, discutió con su …. para enseñar ciencia de la computación [6]. Él mantuvo que el arte de la programación es el proceso enlazante […esto suena fatal…] que recoge ramas dispares en una sola disciplina. Sobre el cuarto de siglo anterior, había formulado muchos de los grandes desafíos intelectuales del campo en cuanto a la programación –la declaración goto, programación estructurada, procesos concurrentes, semáforos, interbloqueo, programación recursiva en ALGOL, y la obtención de programas correctos. Abogó por que elimináramos todos los lenguajes de programación del mundo real de los primeros cursos y, en su lugar, enseñáramos la obtención precisa de programas desde sus predicados lógicos que expresan sus requisitos. Sus críticos pensaron que éste acercamiento estaba demasiado limitado y abogaron por una aproximación más cercana a la ingeniería del software. La mayoría de nuestros planes de estudios no hacen hoy ni lo uno ni lo otro: la programación no se enseña como construcción de algoritmos para funciones matemáticas o como un paso hacia la ingeniería de software de sistemas; se enseña como una introducción a un lenguaje profesional, Java o C++. Varios estudios han documentado las trise éxisto de proyectos de software: aproximadamente una tercera parte son entregados a tiempo y dentro de presupuesto; otra tercera parte es entregada tarde y con presupuesto de sobra; y el resto no son del todo entregados. Los autores de los estudios llegan constantemente a la conclusión de que los malos proyectos se extravían debido a varios problemas de la gente –interrupción de relaciones interpersonales, escuchar inadecuadamente al cliente. Muy pocos cursos de ingeniería de software se ocupan de estos asuntos y enseñan a los estudiantes buenos requisitos, detección de errores, trabajo en equipo, y cómo tratar al cliente. ¿Por qué? Muchos miembros facultativos consideran éstos aspectos como “blandos” y creen que no ha habido suficiente sitio en el plan de estudios para todo el material técnico “fuerte” principal.

En La Revolución Inacabada, Michael Dertouzos documentó 15 defectos comunes en sistemas informáticos. Hemos tenido idea de ellos durante años pero nuestros métodos al enseñar desarrollo de software han sido ineficaces –parece que tengamos una ceguera que se pasa en cada nueva generación de estudiantes. Él recomienda moverse desde el desarrollo del producto-centrado al desarrollo humano-centrado.

Así que todavía tenemos un largo camino que recorrer. Estamos atrapados por una tradición histórica que considera a los programas como funciones matemáticas y a la programación como la práctica central para portar éstas funciones a sistemas de trabajo. Sólamente hemos abarcado, de modo parcial, la tradición más nueva que considera los programas como componentes de sistemas complejos que deben ser diseñados bajo severas limitaciones. La industria nos ha empujado durante mucho tiempo hacia la tradición más nueva pero no hemos dejado …

Prácticas de computación

A lo largo de los años, las prácticas de sistemas, moledado e inovación …..