El apocalipsis del software tan temido Aceleración involuntaria

Cada vez más sistemas y operaciones cruciales para la vida y la seguridad son controlados por computadoras; pero los programas fallan, y las consecuencias pueden ser nefastas

Swashington se ha dicho que el software “se está comiendo al mundo”. Cada vez son más los sistemas cuyo funcionamiento es crucial y que antes eran controlados mecánicamente o por personas, que ahora dependen de una codificación. nunca fue más evidente que durante el verano boreal de 2015, y todo en un día: United airlines tuvo que dejar en tierra a toda su flota debido a un problema en su sistema de manejo de despegues; la Bolsa de nueva York tuvo que dejar de operar tras un mantenimiento del sistema; se cayó la página online de the wall street Journal; el 911 de seattle se cayó por una falla en un enrutador. al principio, esa falla simultánea de tantos softwares olía a ciberataque. La verdad fue peor: había sido pura coincidencia.

“Cuando los sistemas eran electromecánicos, era posible testearlos exhaustivamente”, dice nancy Leveson, profesora de aeronáutica y astronáutica del Mit que estudia el tema de la seguridad del software desde hace 35 años. El software es diferente. Basta con editar el texto de un archivo que está en alguna parte, para que un mismo cacho de silicio se convierta en un sistema de automanejo o en un sistema de control de inventario. La flexibilidad es el milagro del software, y también su maldición. “El problema –dice Leveson– es que estamos queriendo construir sistemas que están más allá de nuestra capacidad intelectual para manejarlos”.

Antes del software

El esquema mental estándar que rige nuestra forma de pensar las fallas de ingeniería se desarrolló para los sistemas electromecánicos, poco después de la segunda guerra Mundial, antes de la llegada del software. La idea era que para que un sistema sea confiable las partes tienen que ser confiables y hay que planear las roturas de esas partes. Pero el software no se rompe. Las fallas de software son fallas de comprensión y de imaginación. De hecho, intrado tenía un enrutador extra, que de haber tenido la orden de encenderse automáticamente, habría restablecido el servicio del 911 de inmediato. Pero como explicó un informe a la Comisión Federal de Comunicaciones norteamericana, “la situación se produjo en un punto de la lógica de la aplicación que no estaba diseñada para realizar ninguna corrección de manera automática”.

El progreso tecnológico solía cambiar el aspecto del mundo. Uno veía el avance del pavimento en las rutas y los edificios cada vez más altos. hoy, apenas notamos si algo fue rehecho, porque la mayoría de las veces fue rehecho por codificación. Cuando pisamos el acelerador del auto ya no controlamos nada de manera directa, no hay conexión mecánica entre el pedal y el regulador de combustible. Uno le está entregando el control a una pieza de software que decide cuánto aire dejar ingresar al motor.

a medida que los programadores empezaron a introducir software en sistemas cuyo funcionamiento es crucial, se convirtieron en los ejes del mundo construido, y el renombrado científico de la computación holandés Edsger Dijkstra pensaba que tal vez se habían sobrevalorado a sí mismos. “Los ingenieros en software no entienden el problema que están intentando resolver, y no les importa”, afirma Leveson. La razón es que están enfrascados en hacer que su código funcione. “ahora en los autos hay 100 millones de líneas de código”, dice Leveson. “Es imposible que una persona pueda anticiparse a las fallas de todas estas cosas”.

En septiembre de 2007, Jean Bookout manejaba su toyota Camry con su mejor amiga cuando se trabó el acelerador. sacó el pie del pedal, pero el auto no bajó la velocidad. Entonces pisó los frenos, pero parecían haber perdido potencia. Mientras se desviaba hacia una salida a más de 80 km/h, tiró del freno de mano. El auto dejó una marca de derrape de 45 metros antes de ir a dar a un terraplén. La acompañante murió. Y Jean se despertó un mes después en un hospital.

El incidente fue uno de muchos en una investigación de casi una década en torno a las denuncias relacionadas con lo que se conoce como la “aceleración involuntaria” de los vehículos toyota. La empresa culpó de los incidentes a un mal diseño de las alfombras, a los pedales y a un error del conductor, pero fuera de la empresa sospechaban que el responsable podía ser un software defectuoso. La administración nacional de seguridad del tráfico en las Carreteras de Estados Unidos contrató a expertos en software de la nasa para que llevaran a cabo una revisión intensiva del código de toyota. Después de casi 10 meses, el equipo de la nasa no encontró evidencia de que la causa hubiera sido el software del auto, aunque tampoco pudieron probar que no lo fuera.

Pero durante el juicio por el accidente de Bookout alguien encontró una conexión convincente. Michael Barr, perito de la querella, tenía un equipo de especialistas en software que se pasó 18 meses trabajando en el código del toyota, retomando donde había dejado la nasa. Barr describe lo que encontraron como “código espagueti”, una expresión en la jerga de los programadores que hace alusión al software que se convierte en una maraña. Un código se transforma en espagueti cuando se acumula durante muchos años, superponiendo funciones. a la larga, el código se vuelve imposible de seguir y ya nadie lo revisa en busca de fallas.

Empleando el mismo modelo que el Camry del accidente, el equipo de Barr demostró que la computadora de a bordo podía fallar en la ejecución de las tareas claves en más de 10 millones de formas, que llevaban potencialmente a producir una aceleración involuntaria. Y el código a prueba de fallos que había instalado toyota no alcanzaba para detenerlo. El testimonio de Barr cerró el caso a favor de la fiscalía. Y vendrán más días malos para el software. Es importante mejorarlo porque si no en la medida en que se vuelva más sofisticado e interconectado esos días podrían llegar a ser nefastos.

Durante los últimos 40 años, las computadoras han venido duplicando su potencia cada 18 meses. ¿Por qué la programación no cambió? aunque dirige un laboratorio que estudia el futuro de la computación, Bret Victor parece estar menos interesado en la tecnología que en la mente de las personas que la utilizan. “nuestro concepto actual de lo que es un programa de computación –explica Victor– deriva directamente de los Fortran y algol de finales de la década del 50. Estos lenguajes fueron diseñados para las tarjetas perforadas”. ahora, en un lenguaje como C o Java (derivados de Frotran y algol, el código toma la forma de letras sobre una pantalla en lugar de una pila de tarjetas con agujeros. Después apareció el wysiwyg, sigla en inglés de “lo que se ve es lo que hay”. Y cuando se marcaba un párrafo para que estuviera en cursiva, ahí mismo, las letras de la pantalla se inclinaban.

La opinión de Victor era que la programación misma debía ser así. Y los antecedentes eran suficientes como para sugerir que no se trataba de una idea tan loca. El Photoshop, por ejemplo, colocó los algoritmos poderosos del procesamiento de imágenes en manos de gente que ni siquiera sabía lo que era un algoritmo. Pero estos son sólo unos pocos ejemplos. La realidad era que cuando alguien quería hacer algo interesante con una computadora, tenía que escribir código. Y Victor lo vio como una falla moral de los programadores.

Chris granger, que había trabajado para Microsoft en Visual studio, estaba inspirado. En enero de 2012, unos días después de haber visto el video de una charla de Victor, construyó el prototipo de un entorno de programación nuevo. su capacidad clave era dar respuesta instantánea sobre el funcionamiento de un programa. Uno veía lo que el sistema estaba haciendo al lado del código que lo controlaba. En abril de 2012, solicitó fondos para el proyecto en Kickstarter. En los círculos de programadores resultó un éxito. En un mes, el proyecto recaudó más de 200.000 dólares. Las ideas se difundieron. La noción de “estar en vivo”, de ser capaz de ver fluir los datos a través de un programa al instante, se abrió paso hasta las herramientas de programación emblemáticas ofrecidas por google y apple.

Autosupresión

Para Victor, el papel idóneo de un desarrollador de software sería crear herramientas que eliminen la necesidad de que haya desarrolladores de software. Por supuesto, para hacer eso, habría que contar con los propios programadores. En un ensayo reciente,

Victor les suplicó a los desarrolladores de software profesionales que dejen de volcar su talento en herramientas para construir aplicaciones como Snapchat y Uber. “Los inconvenientes de la vida diaria no son problemas significativos”, escribió. En lugar de eso, tendrían que concentrarse en los científicos y los ingenieros; “en esa gente que se ocupa de lo que de veras importa, lo que es de interés decisivo, y que está usando herramientas muy pero muy malas”.

Códigos

“Si uno observa con atención todos los productos industriales que hay, los que usamos y los que usan las empresas, el único material no industrial que llevan dentro es el código”. Eric Bantégnie es el fundador de Esterel Technologies, una empresa francesa que fabrica herramientas para construir software de seguridad crítica. Al igual que Victor, Bantégnie no cree que los ingenieros tengan que desarrollar los grandes sistemas tipeando millones de líneas de código. “Nadie fabricaría un auto a mano”, dice. “En muchos lugares, el código todavía es artesanal. Si uno elabora manualmente 10.000 líneas de código está bien. Pero hay sistemas que tienen 30 millones de líneas de código; o 100 millones, como el Tesla o los autos de alta gama. Y eso se está volviendo muy pero muy complicado”. El software se vuelve ingobernable porque los medios para describir lo que debería hacer –conversaciones, descripciones en prosa, dibujos sobre un papel– son demasiado diferentes del medio para describir lo que hace, es decir, el código.

Esterel Technologies surgió de las investigaciones que iniciaron en la década de 1980 las industrias francesas nuclear y aeroespacial, a las que les preocupaba que cuanto más crecía en complejidad el código de seguridad crítica, más difícil se hacía mantenerlo libre de errores. “Yo empecé en 1988”, dice Emmanuel Ledinot, el director de investigaciones científicas de Dassault Aviation, una empresa constructora de jets privados y de combate. “Para esa época, estaba trabajando con sistemas de aviónica militar. Y el personal a cargo de integrar los sistemas, y de depurarlos, se había dado cuenta de que el número de fallos iba en aumento”. En la década del 80 se registró un incremento en el número de computadoras de a bordo en los aviones. En vez de una única computadora de vuelo, ahora eran decenas, cada una responsable de desempeñar una tarea altamente especializada relacionada con el control, la navegación o las comunicaciones. Coordinar estos sistemas para que hagan volar el avión mientras llegan datos de los sensores y los pilotos ingresan órdenes exige una sinfonía de reacciones perfectamente sincronizadas. “La manipulación de estos cientos, e incluso miles, de eventos posibles en el orden correcto y en el momento correcto –dice Ledinot– fue la que se diagnosticó como la causa principal del aumento de los fallos”.

Ledinot decidió que escribir a mano un código así de intrincado ya no era algo sostenible. Resultaba demasiado difícil entender qué era lo que se estaba haciendo, y casi imposible verificar si iba a funcionar correctamente. Entonces empezó a buscar algo nuevo. “Hay que entender que, en un proceso como este, cambiar de herramientas es extremadamente caro”, explica Ledinot. “Uno no toma ese tipo de decisiones a menos que tenga la espalda contra la pared”.

Herramienta nueva

Ledinot empezó colaborando con Gérard Berry –experto en computación de Inria, el centro francés de investigación informática– con una herramienta llamada Esterel, el equivalente en francés a “en tiempo real”. La idea en la que se basaba Esterel era que mientras los lenguajes de programación tradicionales podían ser buenos para describir procedimientos simples que ocurrían en un orden predeterminado, si uno trataba de usarlos en sistemas donde podían ocurrir muchos eventos casi en cualquier momento y casi en cualquier orden (como en la cabina de mando de un avión), era inevitable que se produjera un desastre. Y un desastre en el software de control es peligroso.

Esterel se diseñó para hacer que la computadora maneje en lugar de uno esa complejidad. Esa fue la promesa del enfoque basado en modelos: en vez de escribir el código normal de programación, se crea un modelo de funcionamiento del sistema, en este caso, un modelo enfocado en cómo podrían manejarse los sucesos individuales, cómo priorizarlos, cuáles dependen de cuáles. El modelo se convierte en el plano detallado que la computadora va a usar para hacer la programación verdadera.

Ledinot y Berry trabajaron durante casi diez años para llevar a Esterel al punto en el que pudiera emplearse en la producción. “Fue en 2002 cuando tuvimos nuestro primer entorno con generación automática de código –relata Ledinot– y el primer módulo incrustado en Rafale, la aeronave de combate”. Hoy en día, la familia de productos Ansys Scade (por la sigla en inglés de “entorno de desarrollo de aplicaciones de seguridad crítica”) se dedica a generar código para empresas de las industrias de defensa y aeroespacial, plantas de energía nuclear, sistemas de tránsito, industria pesada y equipamientos médicos.

Computadoras en lugar de humanos

Como explica Bantégnie, lo hermoso de tener una computadora en vez de un ser humano para convertir los requerimientos en código es que se puede estar seguro –se puede probar matemáticamente– de que el código generado satisface de veras esos requerimientos. Muchos de los beneficios del enfoque basado en modelos proviene de que este permite agregar requerimientos sobre la marcha mientras todavía se está chequeando si los previos se satisfacen. Con cada cambio, la computadora puede verificar si el programa sigue funcionando bien.

Con todo, la mayor parte del software –incluso en el mundo de la aviación, obsesionado por la seguridad– se hace a la antigua, con ingenieros que escriben sus requerimientos en prosa y programadores que los codifican en un lenguaje de programación como C. La mayoría de los programadores piensan de la misma manera. Les gusta el código. Por lo menos, lo entienden. Las herramientas que escriben código en lugar de uno y revisan si es correcto a través de la matemática suenan esotéricas y difíciles de usar. Cada vez que la programación da un paso para alejarse de la escritura literal de ceros y unos, las mayores objeciones llegan de los programadores.

La tendencia en contra del diseño basado en modelos está tan arraigada que de acuerdo con un artículo reciente, “incluso algunos argumentan que hay una necesidad más fuerte de investigar la percepción que tiene la gente del diseño basado en modelos que de investigar las nuevas tecnologías”. Lo que suena casi como un chiste, pero para los que proponen un enfoque basado en modelos es un punto importante a considerar: ya sabemos cómo hacer que el software complejo sea confiable, pero en muchos lugares elegimos no hacerlo. ¿Por qué?

En 2011, Chris Newcombe llevaba casi siete años en Amazon, y había ascendido a ingeniero principal. Había trabajado en algunos de los sistemas más críticos de la empresa, incluyendo la infraestructura que gestionaba cada dispositivo Kindle del mundo. Es uno de esos ingenieros cuyo trabajo silencioso mantiene a Internet rodando. Los productos en los que trabajaba eran éxitos masivos. Pero él sólo podía pensar en que, enterrados muy hondo, en el diseño de esos sistemas había desastres esperando ocurrir.

“La intuición humana es pobre al estimar la verdadera probabilidad de las combinaciones de eventos que se supone son extremadamente raros en los sistemas que operan a una escala de millones por segundos”, escribe en un artículo. “Esa falibilidad humana significa que algunos de los fallos más sutiles y peligrosos resultan ser errores de diseño; el código implementa escrupulosamente el diseño previsto, pero falla a la hora de gestionar de forma correcta un escenario particularmente raro”.

Algoritmos detrás de los sistemas

Newcombe estaba convencido de que los algoritmos detrás de los sistemas verdaderamente críticos –los sistemas que almacenan una porción significativa de información de la Web, por ejemplo– no tenían que ser buenos, sino perfectos. Un solo fallo sutil podía resultar catastrófico. Pero él sabía lo difíciles de encontrar que son los errores, sobre todo cuando un algoritmo se vuelve más complejo. Uno puede hacer todas las pruebas que quiera y no encontrar nunca todos los fallos. “Son pocos los programadores que antes de empezar a programar escriben aunque más no sea un borrador básico de lo que va a hacer su programa”

Para el investigador informático Leslie Lamport, una de las razones principales por las que los softwares actuales están plagados de errores es que los programadores saltan a escribir el código directamente. “Antes de que se ponga un ladrillo o se clave un clavo, los arquitectos dibujan planos detallados”, escribe en un artículo. “Pero son pocos los programadores que antes de empezar a programar escriben aunque más no sea un borrador básico de lo que va a hacer su programa”. A los programadores se los arrastra al meollo de la programación porque el código es lo que hace andar al programa; dedicarle tiempo a cualquier otra cosa parece que fuera una distracción.

Según argumenta Lamport, nunca se pretendió que el código fuera un médium del pensamiento. “Cuando uno piensa en términos de lenguaje de programación, realmente se restringe la habilidad de pensar”, dice Lamport. Programar hace que se pierda el bosque por los árboles: arrastra la atención hacia el funcionamiento de las piezas individuales más que hacia la imagen general de cómo va a funcionar el programa una vez que esas partes encajen, o lo que se supone que haga, y si de veras hace lo que uno cree que hace. Fue por esto que Lamport inventó TLA+. Y, como sucede con el diseño basado en modelos, TLA+ lleva a concentrarse en la estructura de alto nivel de un sistema, en su lógica esencial más que en el código que la implementa.

Fallas críticas

Newcombe y sus colegas de Amazon siguieron usando TLA+ para encontrar fallos críticos sutiles en los sistemas principales. Los ingenieros de la Agencia Espacial Europea lo utilizaron para reescribir, con 10 veces menos código, el sistema operativo de una sonda que fue la primera que logró aterrizar suavemente sobre un cometa. Intel lo emplea con regularidad en el control de sus chips. Pero la TLA+ ocupa nada más que un rinconcito alejado de la corriente principal, si es que puede decirse que ocupa algún lugar. Hasta para un ingeniero experimentados como Newcombe, al principio el lenguaje se lee como bizarro y esotérico, como un zoológico de símbolos.

Para Lamport, lo que falla es la educación. Aunque la programación nació dentro de la matemática, desde entonces ya hace tiempo que en gran medida se divorciaron. La mayoría de los programadores no son muy fluidos en la clase de matemática que se necesita para trabajar con TLA+; más que nada, lógica y teoría de conjuntos. Lamport ve el problema del desarrollo del software moderno en esta falencia para pensar matemáticamente lo que se está haciendo: la apuesta sigue subiendo, pero los programadores no avanzan, todavía no desarrollaron el coraje que hace falta para manipular problemas cada vez más complejos. “En el siglo XV, la gente construía catedrales sin saber nada de cálculo, y hoy en día no creo que se le permitiera a nadie construir una catedral sin saber cálculo. Espero que después de un tiempo conveniente, a la gente no se le permita escribir programas si no entienden estas cuestiones simples”. © The Atlantic

Traducción de Jaime Arrambide

La mayoría de los programadores piensan de la misma manera Se sabe cómo hacer que el software sea más confiable, pero no siempre eso se aplica Enterrados muy hondo en esos sistemas había desastres esperando ocurrir