miércoles, 30 de noviembre de 2016

Desarmando deslizadores chequeo cruzado

Al tomar un vuelo el ritual antes del despegue es generalmente el mismo: desde mi silla es difícil ver lo que está sucediendo y solo se escuchan las puertas cerrar, los motores que se encienden y ruidos hidráulicos y eléctricos que van y vienen. Lo único que puedo observar es cómo son probados los alerones, a la tripulación vigilando cada silla y que los equipajes estén en su sitio. Luego se escucha la frase del capitán, que siempre me ha causado curiosidad: "Desarmando deslizadores chequeo cruzado". 

El desarmado de deslizadores o armado de deslizadores es una orden que reciben los tripulantes o azafatas para que enganchen o desenganchen los toboganes a la puerta del avión; el tobogán debe permanecer enganchado o "armado" así en caso de emergencia al abrir las puertas las personas podrán salir por los toboganes desplegados una vez que el avión se encuentre detenido y con los motores apagados.


Deslizadores desplegados en una emergencia.

Como podemos ver en el siguiente video el procedimiento es bastante sencillo:


Procedimiento desarmando deslizadores chequeo cruzado.

El chequeo cruzado es usado también en labores críticas del vuelo y es fundamental en la comunicación entre el piloto y el copiloto, como lo muestra la siguiente historia:
El 27 de Agosto de 2006, un Bombardier CL-600-2B19, N431CA, de Comair se estrelló cuando despegaba del aeropuerto “Blue Grass” en Lexington, Kentucky (USA). La tripulación tenía autorización para despegar por la pista 22 pero el despegue se realizó por la pista 26, pista que es mucho más corta que la pista autorizada. El avión se salió al final de pista y se estrelló contra la valla del perímetro del aeropuerto, contra un grupo de árboles y finalmente contra el terreno. 47 pasajeros, un Tripulante de Cabina de Pasajeros y el Comandante fallecieron, el Primer Oficial resultó gravemente herido. El avión quedó completamente destruido por el impacto y el fuego que posteriormente surgió. 
La NTSB determinó que la causa probable del accidente fue el fallo de los pilotos al no emplear las referencias visuales disponibles para identificar la posición del avión en las calles de rodaje y el de no realizar el chequeo cruzado para asegurarse que iban a despegar por la pista correcta.
El Factor Humano en los Accidentes Aéreos - 2011

Por lo tanto, el chequeo cruzado sirve para asegurar que la información, un cálculo o un proceso sea correcto, y se realiza preguntando a una persona diferente o verificando los resultados con una herramienta o otro método de cómputo. En conclusión, uchequeo cruzado es en esencia el conjunto pruebas de cualquier índole en ingeniería, esta puede tener diferentes nombres o roles: auditor, certificación, supervisor, revisor o interventor. 

Bien ¿ahora estamos en pruebas en software?


¿Recuerdan nuestro carro soñado, al cual llamamos "el jefe"?. Ahora supongamos que hemos aprendido la lección y corregimos el diseño para que el mantenimiento fuera más sencillo: ahora para hacer el cambio de aceite sólo es necesario quitar una tornillo y el tablero de sonido es operado desde una aplicación del celular o tablet, y debido a esto y fuera de toda lógica, una gran compañía de automóviles quiere construirlo.

Ahora, la compañías de automóviles tienen líneas de producción en donde los humanos ya no realizan trabajos repetitivos y aburridos. Pero realmente liberar al hombre de trabajos repetidos y aburridos no es la verdadera razón por la cual se usan robots en las líneas de ensamblaje. Si desmenuzamos la palabra original del Latin, manofactura es usar las manos (manu) para crear cosas (factura). Los robots son una historia diferente. El término viene de la palabra checa Robotnik, que significa nada menos que trabajo de esclavo. No deje que la ciencia ficción y la ternura japonesa lo confundan: Los seres humanos crean robots para hacer su trabajo de esclavo.

En otras palabras, los robots realizan tareas que los seres humanos a menudo encuentran peligrosas o aburridas, y pueden hacerlo a velocidad y precisión constantes. Nunca se reportaran enfermos, no crean sindicatos, no intercambian chismes, no entran en huelga, no violan normas de la empresa y no están buscando cambiar de empresa o situación sentimental con cada falda robótica que ven. Cubren turnos de 24 horas sin desperdiciar un solo minuto de tiempo pensando si su equipo de fútbol por fin este año va a subir de categoría. No hace falta decir, los propietarios de las grandes compañías inmediatamente se volvieron adictos a los robots, y como toda droga es costosa y tiene consecuencias, pero, a la larga la inversión se retorna pues los empresarios tendrán esclavos las 24 horas del día.


Robots haciendo el trabajo de esclavo.

Sin embargo, los robots también tienen sus limitaciones. En su forma más simple, los robots industriales son meros autómatas. Los seres humanos los programan para realizar tareas simples, y repiten esa tarea una y otra vez. Los puestos de trabajo que tienen tareas que requieren la toma de decisiones, creatividad, adaptación y el aprendizaje tienden a ir a los seres humanos, pero, incluso esto último está cambiando con el uso redes neuronales y Deep Learning. En el futuro probablemente veremos máquinas que trabajarán junto a los seres humanos e incluso aprenderán de nosotros para realizar un número creciente y claramente preocupante de otras tareas. Ahora, cuando un trabajo es adecuado para los robots, la productividad tiende a aumentar de forma espectacular.

Recapitulando, nos hemos ganado la lotería pues una gran compañía de automóviles va a construir "al jefe" a gran escala en su línea de producción automatizada. Una línea de producción automatizada significa tener una obvia adicción a los robots. Esta droga robótica es costosa no solo en inversión de las máquinas, si no también es necesario cambiar los procesos internos de la compañía, incluso esto significa cambiar la forma en que son diseñados y probados los productos. Ahora, "el jefe" como nuevo producto debe ser rediseñado para que pueda ser armado y probado automáticamente.

¿Por qué el jefe debe ser rediseñado? 


Eso, amigos, es parte de otra historia.

Referencias




martes, 11 de octubre de 2016

Si compila funciona

Y no es suficiente que solo funcione


Un tiempo atrás, mejor, hace ya mucho tiempo atrás, cuando empecé a desarrollar software, las cosas sucedían por esfuerzos heroicos de todos los implicados, entonces, no existían ambientes independientes, desarrollábamos en las mismas bases de datos de pruebas, cada quien probaba lo que se le ocurría y el control de configuración era llevar los archivos a un directorio de donde sacaban una copia la cual luego era nuestro "release", en conclusión el producto funcionaba de milagro, y era otro milagro, aún mayor, si el cliente aplicaba lo que enviábamos.
Cuando en el universo ocurría una de esas extrañas singularidades de espacio y tiempo, nuestros clientes instalaban y aparecía el perfil de desarrollador de servicios profesionales, quien no era más que un ingeniero que se iba armado con nuestro "release" a copiarlo, así fuera a la fuerza, en los servidores del cliente y luego trataba de resolver todos los errores que encontraba, la solución de esos errores a veces era reportada a la fábrica y la mayoría de las veces se perdía con el café de la siguiente mañana. Es justo anotar también que, mucho del soporte era dado directamente por los grupos de desarrollo pues los encargados del cliente a veces no daban abasto.
Todo ese modelo fue como «un bebé concebido durante una caótica orgía en la que todo el mundo acaba con un terrible dolor de cabeza, y cuando aparece este hijo todos dicen:“No es mío”»

¿Y en donde empieza el sermón?


En esa epoca, y en los años posteriores, acuñamos el término "si compila funciona" refiriéndonos, en forma de chiste, a nuestra desconfianza por el código que hacíamos, pues al no tener ambientes, independientes de desarrollo y pruebas, control de versiones y un proceso de pruebas robusto era como manejar: de noche, sin luces, lloviendo, en una carretera sin señalización, manejábamos alocadamente tumbando algunos árboles, pequeños y grandes, de la orilla del camino.
just-a-tree-growing-through-a-car
Carro leñador
Ahora, la expresión "si compila funciona" surge de las decisiones que se toman en desarrollo sin tener una etapa previa de diseño, y mucho menos teniendo en cuenta el mantenimiento posterior de la aplicación.

Fue una época difícil ¿y?


Ya pasaron los tiempos de las caóticas orgías y el carro leñador, ahora tenemos procesos estructurados de entrega y liberación de producto. Los desarrolladores y líderes están siempre preocupados por terminar funcionalidades o tareas del cronograma y los productos funcionan.

Y eso es bueno ¿cierto?


Depende. Déjenme les cuento una historia, supongamos que diseñamos nuestro automóvil soñado: debe tener mucho espacio interior, en caso que quisiéramos ir al supermercado o realizar un trasteo de una casa de 3 pisos, además el equipo de sonido será capaz de amenizar un concierto de reggaetón en el estadio y estéticamente debe proyectar la imagen de "Yo soy el jefe"
1x-1
El jefe con un tremendo equipo de sonido y gran espacio interior
Ahora, como somos unos bisoños diseñadores automotrices hemos cometido algunos pecados que serán castigados cuando tengamos que hacer alguna reparación, puesto que el mantenimiento no fue pensado en el diseño original y fue una decisión de último momento, así:
  • Es necesario bajar el equipo de sonido para hacer un cambio de aceite y para eso necesita una grúa industrial de 20 toneladas.
  • El tablero de sonido es tan complicado que solo puede ser operado y reparado  por un ingeniero de sonido que previamente ha sacrificado 2 gallinas como ofrenda a su dios Kukulkán.
  • El mecánico que realizó la construcción estaba tan convencido que era el mejor automóvil jamás construido, entonces, trabajo sin descanso en el proyecto, propulsado por bebidas energizantes y drogas psicoactivas, entregando a tiempo y volviéndose un loco adicto a estas sustancias lo que lo alejo definitivamente del mundo automovilístico. Ahora nadie sabe las herramientas usadas en la construcción o los cambios en la implementación final.
Entonces podemos afirmar, no es suficiente que solo funcione.

Pero esos son carros no software


El software tiene una complejidad mayor pues es algo virtual, son un enjambre de unos y ceros dando vueltas sin cesar por circuitos electrónicos, que representa información a un usuario u otras máquinas.
El carácter virtual del software lo hace más propenso a cometer errores de diseño, algo que sucede rara vez en la ingeniería que trabajan con cosas concretas, en algo tangible es más sencillo notar los problemas, en cambio, en el software es difícil percibir estos inconvenientes incluso en el producto final.
car-fails-079
Un error muy tangible

¿Y cómo es diseñar para hacer más fácil el mantenimiento en el software?


Existen diversas técnicas que ayudan en este objetivo una es el Test-driven development (TDD) en donde las piezas son cuidadosamente nombradas y separadas para mejorar la legibilidad y facilidad de mantenimiento.

¿Y cómo funciona TDD?


De niño una de las tareas que menos me gustaba era ir a comprar plátanos a una tienda que quedaba a 3 cuadras, pues como tengo cierto grado de daltonismo confundo algunos tonos del color verde, por lo tanto, para mi todos los plátanos verdes son iguales y no podía distinguir cuales eran para: freír, sopa o de otra especie, adicionalmente, mi madre algunas veces no me daba dinero suficiente para la compra, por lo tanto, en muchas ocasiones debía volver a la tienda a cambiar los plátanos o a llevar el dinero que faltaba.
Viendo el problema de la compra del plátano daltónico desde el punto de vista del TDD, las labores deben estar separadas en: escoger, pagar y correr. Necesitamos una persona que tenga una experiencia, rapidez y visión perfecta en la escogencia de esta fruta, el encargado del pago debe tener el cambio exacto y el que corre a la casa puede ser el campeón olímpico de los 100 metros planos, ahora, si necesitamos un mejor experto o contratar a alguien con una moto podemos cambiarlos fácilmente. Lo anterior es parte de TDD, en donde cada unidad debe tener responsabilidades bien definidas y concretas, además, deben cumplir con características suficientes para realizar pruebas de unidad automáticas, pero esto último es parte de otra historia.
Si quieren conocer más de TDD pueden ver las siguientes referencias: