El error de Interface que casi termina en tragedia en el vuelo espacial Apolo 8

"Eso nunca va a pasar" es una frase que está destinada a la tragedia. Aunque tenga baja probabilidad de ocurrencia, "eso", tarde o temprano pasa. Quienes diseñamos sistemas informáticos lo sabemos. Lo aprendemos más o menos a los golpes. Con noches largas frente a la pantalla o en largas sesiones de reuniones donde se nos machaca con los inconvenientes que ocasionó nuestro "pequeño" desliz.

Un sistema informático de mediana complejidad, desde su puesta en marcha en un entorno productivo, vive en un estado latente de aparición del "eso nunca va a pasar". No me refiero en este caso a errores por mala programación o implementación, sino a errores causados por un análisis o diseño defectuoso para encarar la resolución del problema. Dentro de esta categoría entran los problema de interfaces.
Los problemas de interface ocurren tanto a nivel de algoritmos - por ejemplo con el valor de un parámetro no contemplado - como a nivel de interacción con el usuario.

El "eso nunca va a pasar" tiene historias trágicas y también épicas. Un ejemplo que encontré leyendo está dentro de un interesante artículo de WIRED sobre Margaret Hamilton, una programadora pionera. A fines de la década de los 60 no eran muchos los que trabajaban en programación y no eran muchas las computadoras. La NASA trabajaba en plena guerra fría a contra reloj en el programa Apolo. La Unión Soviética y Los Estadounidenses tenían como meta llevar al hombre a la luna.

Margaret Hamilton junto al DSKY

Margaret Hamilton, trabajaba en el MIT Instrumentation Laboratory con la misión de construir la programación de la computadora de a bordo de las nave espacial, el Apollo Guiding Computer (AGC). El código se escribía en tarjetas perforadas, se probaba en un mainframe que simulaba el trabajo de la AGC y luego de varias pruebas se pasaba a la computadora de a bordo. Para hacer más real las simulaciones en el MIT tenían un módulo de comandos similar al que usarían a bordo de la nave. Mediante llaves y pantallas se podía interactuar tal como lo realizarían los astronautas en pleno vuelo. Esta interface recibía el nombre de DSKY (DiSplay&KeYboard, pronunciado como 'DISS-key').

Un día mientras interactuaba con el DSKY, Hamilton inició en pleno vuelo un proceso de pre-lanzamiento - el P01. Instantaneamente provocó un error que inhabilitó la computadora de a bordo. Preocupada con ese descubrimiento informó a la NASA del problema. Sugirió agregar en el código los controles necesarios para que eso no ocurra. La respuesta fue "Los astronautas no van a cometer errores. Están entrenados para ser perfectos". La solución de compromiso fue escribir una nota en la documentación del programa que informaba "No inicie el proceso P01 durante el vuelo".

Insignia del programa Apolo

Lo que nunca pasaría ocurrió en pleno vuelo del Apolo 8. 5 días luego del lanzamiento uno de los astronautas inició inadvertidamente el P01. Como resultado todos los datos de navegación se perdieron, sin esos datos la vuelta a la tierra era imposible. Hamilton y sus compañeros programadores fueron llamados de emergencia para pergeñar una solución. Afortunadamente tras 9 horas de trabajo duro encontraron la forma de cargar la información nuevamente enviándola desde la tierra.

El entrenamiento de los astronautas para el programa Apolo era muy extenso, cerca de 84.000 horas (casi 10 años). Fueron entrenados para conocer los protocolos al pie de la letra, para saber que hacer y como reaccionar antes diferentes situaciones. Aun así, lo "imposible" - que debía ser catalogado como improbable - ocurrió. 

La mayoría de los que trabajamos en la elaboración de sistemas informáticos no tenemos oportunidad de trabajar en programas para naves espaciales, pero si trabajamos en sistemas de mediana a gran complejidad donde la interacción del usuario es un factor importante. El diseño de interfaces y sus controles se transforman en una tarea importante y que no debe ser descuidada. Los usuarios de nuestros sistemas no suelen recibir entrenamientos extensos, ni suelen leer manuales extensos. La intuición muchas veces es la herramienta con la que los usuarios salen a enfrentar nuestros sistemas. Por ese motivo la elaboración de interfaces requiere una planificación y una etapa de pruebas considerable.

En las metodologías de desarrollo tradicionales, existe una amplia etapa de diseño y de pruebas. Donde se planean y definen los casos de uso (como será el flujo de cada proceso que se puede realizar en el sistema) y los controles sobre la naturaleza de los datos de entrada (que valores son validos y cuales no). La etapa de prueba cerraba un ciclo donde todo eso se evaluaba.
La irrupción de las metodologías ágiles de desarrollo con el concepto de integración continua rompe con este circuito y agrega nuevos desafíos en las etapas de control de procesos. Las interfaces de usuario pueden mutar entre iteración e iteración y por lo tanto los procesos de pruebas se deben ir redefiniendo constantemente.

Existen herramientas para la automatización de pruebas de interface que pueden hacernos menos fastidiosas las pruebas. Incluso nos permiten simular diferentes situaciones. Por ejemplo Selenium es un proyecto que permite hacer pruebas de sistemas con interfaces web. Nos permiten simular la utilización de diferentes browsers y diferentes circuitos.

Ninguna herramienta por ahora reemplaza el buen ojo y tino de un buen trabajador en el área de control de calidad. La capacidad y el entrenamiento de analizar una interface y preguntarse "que pasaría si..." y ponerlo a prueba nos van a decir que tan robusta es nuestra solución. Luego con los resultados de las pruebas se puede definir los pasos a seguir. Rediseñar un proceso, agregar un control de seguridad, un cartel de aviso o unas lineas en un manual del usuario.

Habiendo hablado de la intuición, también muchas veces mal llamada "sentido común",  agrego una nota sobre este tema más mundano. Si compra café y lo toma mientras está manejando un auto. Si la bebida caliente se le derrama y se quema... de quién es la culpa? Según el caso Liebeck v. McDonald's Restaurants, el responsable es quien hace el cafe. La solución a este conflicto fue agregar una advertencia en el recipiente contendedor (un aviso de seguridad en el vaso) que advierte que el café es una bebida caliente y que debe ser manejado con cuidado. En última instancia, una buena documentación y sistema de alerta, es la última linea de defensa. La intuición no es infalible.

---