Software apocalipse

Esta es mi traducción del artículo publicado en Medium como "Software Apocalipse" por James Somers en septiembre de 2017. Para mi gusto, apasionante y muy bien documentada visión de la forma en la que se actualmente se construye software.

Hubo 6 horas durante la noche del 10 de abril de 2014, en la que la población del estado de Washington no tuvo servicio del número 911. La gente que llamaba para pedir ayuda recibía la señal de ocupado. Una mujer de Seattle marcó 911 al menos 37 veces mientras un extraño estaba intentando entrar en su casa. Cuando finalmente el extraño consiguió entrar en su sala de estar por la ventana, ella cogió un cuchillo de cocina y el hombre huyó.

El apagón del 911, en ese momento el más largo nunca registrado, fue localizado en un software que estaba ejecutándose en un servidor de Englewood, Colorado. Operado por un proveedor de sistemas llamado Intrado, el servidor mantenía un contador de cuantas llamadas se habían realizado al 911 en todo el país. Los programadores de Intrado habían puesto un límite sobre la capacidad del contador. Concretamente eligieron una magnitud de millones.

Poco antes de la media noche del 10 de abril, el contador excedió esa magnitud y se produjo el caos. El contador se usaba para generar un identificador único de cada llamada, una vez excedida su capacidad se rechazaban nuevas llamadas. Los programadores no se habían anticipado al problema y no habían creado alarmas para avisar de que se iba a producir. Esto provocó que nadie entendiese lo que estaba ocurriendo. Los centros de Washington, California, Florida, Carolina, y Minnesota, que daban servicio a 11 millones de americanos, luchaban por entender porque cualquier llamada  recibía  la señal de ocupado. Hasta la mañana siguiente no se dieron cuenta que era el software de Intrado el responsable y que arreglarlo consistía solo en cambiar la capacidad del contador.

Hasta hacía poco las llamadas se gestionaban localmente. Los apagones eran pequeños y fáciles de diagnosticar y arreglar. El aumento de los teléfonos móviles y la promesa de nuevas capacidades cómo poder enviar documentos o videos al 911, condujeron a un sistema más complejo que se apoyó en internet. Por primera vez, podían producirse cosas como un apagón nacional del 911. Ahora, desde la implantación del nuevo sistema se habían producido cuatro.

Se dice que el software se está comiendo el mundo. Cada vez más sistemas críticos que hace tiempo se controlaban mecánicamente o por personas, ahora dependen de código. Esto quedo claro el verano de 2015, cuando en un solo día, United Airlines dejo a su flota en tierra porque había un problema en su sistema de gestión de salidas. O cuando se suspendieron las operaciones en la bolsa de Nueva York después de una actualización del software, también la primera página de The Wall Street Journal se cayó. El fallo simultáneo de muchos sistemas software pareció al principio un ciberataque. Casi más aterrador fue la constatación, al final del día, de que era solo una coincidencia.

"Cuando teníamos sistemas electromecánicos, solíamos revisarlos exhaustivamente” dice Nancy Leveson, que es profesora de aeronaútica y astronaútica en el MIT y ha dedicado más de 35 años a estudiar la seguridad del software. Ella se hizo conocida por su informe sobre Therac-25, una máquina de terapia de radiación que mató a seis pacientes debido a un error de software. Cuando las máquinas eran electromecánicas dice: "Solíamos ser capaces de pensar sobre todas las cosas que podía hacer, todos los estados en los que podía estar" Por ejemplo, los interbloqueos electromecánicos que controlaban los movimientos de un tren en los cruces tenían varias configuraciones que en unas pocas páginas se podían describir y se podían probar con los trenes físicamente todas para ver como se comportaban. Una vez que lo habías configurado y probado, se sabía exactamente qué pasaba con cada configuración. El problema con los sistemas software dice Levenson en su libro "es que estamos intentando construir sistemas que están más allá de nuestra capacidad intelectual".

El software es distinto. Editando un texto en alguna parte de un fichero, el mismo trozo de silicio puede convertirse en un piloto automático o en un sistema de control de inventario. Esta flexibilidad es el milagro del software y su maldición. Cómo se puede cambiar en principio a bajo precio, se cambia constantemente y cómo no tiene entidad física - un programa puede ser es mil veces más difícil que otro y ocupar el mismo espacio- tiende a complicarse sin límites.

Nuestro marco estándar para pensar sobre fallos de ingeniería - reflejados, por ejemplo, en las regulaciones para dispositivos médicos- fue desarrollado poco después de la Segunda Guerra Mundial, antes de la llegada del software, pensando en sistemas electromecánicos. La idea era hacer algo seguro haciendo sus partes seguras (es decir, construyes tu motor para soportar 40,000 ciclos de despegue y aterrizaje) y se planea algo por si las partes fallan (se construyen 2 motores). Pero el software no se rompe físicamente.  El nivel del fallo de Intrado no es como el nivel del fallo de un remache que estrella un avión. El software hizo exactamente lo que se le dijo que hiciese. De hecho lo hizo perfectamente. La razón de que fallase es que se le digo mal lo que tenía que hacer. Los fallos de software son fallos de comprensión e imaginación. Intrado actualmente tiene un router de backup al cual se hace intercambio automáticamente si hay problemas y restaura el 911 inmediatamente. Cómo se describe en un informe de la Federal Communications Commission (FCC) "la situación se produjo en la lógica de la aplicación porque no estaba diseñada para realizar acciones correctivas".

Este es el problema de hacer cosas en el software, como algo opuesto a algo físico. "La complejidad" como Levenson dice "es invisible a los ojos".

Actualmente todos los intentos en marcha para cambiar como hacemos software parecen comenzar con la misma premisa: El código es muy difícil de idear. Merece la pena intentar comprender por qué es tan extraño el código a la mente y qué lo hace tan diferente a todo lo anterior.

El progreso tecnológico ha cambiado la forma en que vemos el mundo. Hoy raramente se puede decir cuando algo se ha rehecho, porque a menudo lo que se rehace es el código. Cuando se aprieta el pie sobre el acelerador de un coche, por ejemplo, ya no se está controlando nada directamente, no hay un enlace mecánico desde el pedal al acelerador. En su lugar, se está usando una llamada a una pieza de software que decide cómo frenar. El coche es un ordenador en el que usted está sentado. El volante y los pedales son como teclas de un teclado.

Cómo todo lo demás, el coche ha sido computarizado para dotarle de nuevas características. Cuando un programa está a cargo del acelerador y los frenos, puede ralentizarlo cuando está demasiado cerca de otro automóvil, o controlar con precisión la inyección de combustible para ayudarle a ahorrar. Cuando controla el volante, puede mantener el coche en su carril si se tuerce o guiar la colocación en la plaza de aparcamiento. Estas funcionalidades no se podrían construir sin código. Si se intentara, un automóvil podría pesar 40,000 libras, una masa inamovible.

El software ha permitido que se construyan las máquinas más sofisticadas que nunca han existido. Y, sin embargo, apenas nos hemos dado cuenta, porque toda esa complejidad está empaquetada en pequeños chips de silicio con millones y millones de líneas de código. Pero el hecho de que no podamos ver la complejidad no significa que no exista.

El renombrado científico holandés especialista en informática Edsger Dijkstra escribió en 1988, "tiene que ser posible pensar en términos de jerarquías que son más profundas que las que una mente ha enfrentado hasta ahora" Con esto Dijkstra nos envió un mensaje. A medida que los programadores vertían software en sistemas críticos, se convirtieron, cada vez más, en los pilares del mundo, y Dijkstra pensó que tal vez se había sobreestimado.

Lo que hace que la programación sea tan difícil es que requiere que pensemos cómo un computador. Esto era aun más evidente en los primeros tiempos de la programación donde todo se hacía con ceros y unos. Cualquiera que mirase por encima del hombro de un programador le vería leyendo líneas cómo "100001010011” y “000010011110” , esto evidentemente está alejado de los problemas reales que intentaban resolver; viendo los ceros y unos hubiera sido imposible saber si estaban tratando de calcular trayectorias de artillería o simular un juego de tres en raya. La introducción de los lenguajes de programación cómo Fortran y C, los cuales se asemejaban al inglés y la aparición de herramientas conocidas como "Integrated Development Environments" o IDEs, que ayudan a corregir errores sencillos (cómo el chequeador gramatical de Microsoft Word pero para programas), hizo que se consiguieran mejoras, pero la mejora fue pequeña. El hecho es que los programadores siguen sin trabajar directamente sobre el problema que intentan resolver, en su lugar pasan el día escribiendo instrucciones para una máquina.

El problema es que los ingenieros de software no comprenden el problema que ellos están intentando resolver y no les importa. dice Levenson, la experta en seguridad de software del MIT. La razón es que están muy ocupados en mantener su código funcionando. "A los ingenieros del software les gusta utilizar toda clase de herramientas que les ayuden con los errores de codificación" dice Levenson en referencia a los IDEs. "Los problemas más serios que han existido en el software han tenido que ver con los requisitos no con los errores de codificación. "Cuando estás escribiendo código que controla el acelerador de un coche, por ejemplo, lo importante son las reglas sobre cuándo y cómo y por cuánto abrirlo. Pero estos sistemas han llegado a ser tan complejos que raramente alguien puede mantenerlos completos en su cabeza. "Hay 100 millones de líneas de código en los coches de hoy en día" dice Levenson "Nadie puede anticiparlo todo".

En septiembre de 2007, Jean Bookout estaba conduciendo en una autopista con su mejor amigo en un Toyota Camry cuando el acelerador pareció que se atoró. Cuando ella levantó el pie del pedal, el coche no realentizó. Entonces intentó frenó pero pareció que tampoco funcionaban. Cuando se desvió hacia una rampa de salida que iba a 50 millas por hora, apretó el freno de emergencia. El auto dejó una marca de patinaje de 150 pies de largo antes de toparse con un terraplén al costado de la carretera. El pasajero murió. Bookout despertó en un hospital un mes después.

El incidente fue uno de los muchos durante las investigaciones de casi una década sobre las reclamaciones de la llamada aceleración involuntaria en automóviles Toyota. Toyota atribuyó los incidentes a alfonbrillas mal diseñadas, pedales "pegajosos" y errores de los conductores, pero otros sospecharon que el software defectuoso podría ser el responsable. La Administración Nacional de Seguridad del Tráfico en Carreteras reclutó expertos en software de la NASA para realizar una revisión intensiva del código de Toyota. Después de casi 10 meses, el equipo de la NASA no había encontrado evidencia de que el software fuera la causa, pero dijo que no podían probar que no lo fuera.

Fué durante el litigio del accidente de Bookout que alguien encontró una conexión convincente. Michael Barr, un testigo experto en software del demandante que tenía un equipo que empleó 18 meses en el código de Toyota donde la NASA la encontró. Barr describió que encontraron "código espaguetti" que dentro de la jerga de programadores quiere decir software que se ha convertido en un lío enredado. El código se convierte en espagueti cuando se explota durante muchos años y se va modificando, amontonandose y tejiendose unas funcionalidades sobre otras alrededor de lo que ya está allí; finalmente, el código se vuelve imposible de seguir, y mucho menos probar exhaustivamente sus debilidades.

Usando el mismo modelo que el Camry que provocó el accidente, el equipo de Barr demostró que había más de 10 millones de formas para el computador de a bordo de causar aceleraciones no intencionadas. Esto demostró como el cambio de un solo bit de 0 a 1, puede llevar al coche fuera de control. El código que puso Toyota no era suficiente para parar el coche. "Hay código vigilando al código" dijo Barr "si el software no funciona bien y el mismo programa o app que esta roto se supone que tiene que arreglar el problema, no lo puede hacer porque no está funcionando".

El testimonio de Barr dió la razón al demandante, resultando en 3 millones de dólares en datos para Bookout y la familia de su amigo. De acuerdo con el New York Times, fué el primero de muchos casos similares contra Toyota por los problemas con el sistema electrónico de control del acelerador y la primera vez que un jurado declaró responsable a Toyota por un accidente provocado por una aceleración no intencionada. En total, Toyota retiró más de 9 millones de automóviles y pagó casi $3 mil millones en acuerdos y multas relacionadas con la aceleración involuntaria.

Habrá más días malos para el software. Es importante que consigamos hacerlo mejor, porque sino lo hacemos, cómo el software es cada vez más sofisticado y conectado - tomando control sobre funciones cada vez más críticas - cada vez los problemas serán peores.

El problema es que los programadores están teniendo momentos difíciles para mantener su propio código. Desde 1980, la forma en que los programadores trabajan y las herramientas que usan han cambiado muy poco. Hay un grupo pequeño pero creciente que opina que esto es insostenible. "Hasta los muy buenos programadores luchan para dar sentido a los sistemas con los que trabajan" dice Chris Granger, un desarrollador de software que trabaja como jefe de Microsoft Visual Studio, un IDE que cuesta 1,199$ al año y es usado por cerca de la tercera parte de los programadores profesionales. Él me dijo que mientras estaba en Microsoft, realizó un estudio completo de Visula Studio, el más completo que nunca se había hecho. Durante un mes y medio, el miró como la gente escribía el código. "¿Cómo usaban las herramientas? ¿Cómo pensaban?" dijo. "¿Como se sientan frente a su ordenador, tocan el ratón o no? Todas estas cosas sobre las que tenemos una creencia pero no hemos visto en la realidad.

Los hallazgos le sorprendieron. "Visual Studio es una de las herramientas software más grandes del mundo" el dijo. "Tiene unos 55 millones de líneas de código. Y una de las cosas que descubrí es que más del 90% de las líneas son totalmente irrelevantes. Se realizó mucho trabajo pero faltaban cosas para los problemas mas importantes con los que se enfrenta la gente. Y el descubrimiento más grande que me llevé es que la gente intenta emular a la computadora dentro de su cabeza" Los programadores son como jugadores de ajedrez intentando jugar con una venda, de tal manera que la mayor parte de su energía mental se gasta en intentar imaginar donde están las piezas más que pensar en el juego en sí.

John Resig ha notado lo mismo entre sus estudiantes. Resig es un famoso programador de JavaScript - El software que escribió se usa en la mitad de los website existentes - y es un lider tecnológico en el sitio de formación on-line Khan Academy. A principios de 2012, el ha estado luchando con el plan de estudios del sitio. ¿Porqué es tan difícil aprender a programar? El principal problema parece ser que el código es muy abstracto. Escribir software no es como hacer un puente con palitos de helados, donde puedes ver los palos y tocar el pegamento. Para "hacer" un programa  se escriben palabras. Cuando se quiere cambiar el comportamiento del programa, ya sea un juego o un website o una simulación de física, lo que hay que cambiar es texto. Por eso los estudiantes que lo consiguen - de hecho los únicos que sobreviven - son aquellos que van paso a paso sobre el texto siguiendo la pista de los calculos intermedios. Resig, al igual que Granger, empezaron a preguntarse si eso tiene que ser de esa forma. Los ordenadores tienen el doble de poder cada 18 meses en los últimos 40 años. ¿Porqué no ha cambiado la forma de programar?.

El hecho de que los dos estaban pensando sobre el mismo problema, en los mismos términos y en el mismo momento no era una coincidencia. Ellos habían asistido a una charla,dada a un grupo de estudiantes de ingeniería del software en un hotel de Montreal por un investigador llamado Bret Victor. La charla, que se hizo viral cuando se publicó online en febrero de 2012, hacía dos remarcadas quejas. La primera era que la forma en que hacemos software está desfasada. La segunda que Victor sabía como arreglar el problema.

A Bret Victor no le gustaba escribir código. "Suena raro", dice. “Cuando quiero hacer algo, especialmente cuando quiero crear algo en software, hay una capa inicial de disgusto que tengo que atravesar, donde realmente no estoy manipulando lo que quiero hacer, estoy escribiendo un montón de texto en un editor de texto ".

"Hay una fuerte convicción que es que esta es la manera de hacer las cosas mal".

Victor tiene el semblante de David Foster Wallace, con una inteligencia relámpago que perdura bajo una pátina de timidez. Tiene 40 años, canoso y una pequeña barba no dejada a posta. Su voz es suave, casi lúgubre, pero quiere compartir lo que está en su cabeza, y cuando se pone en marcha parece saltarse las sílabas, como si estuviera dejando atrás su propia voz.

Aunque él lleva un laboratorio que estudia el futuro de los ordenadores, parece menos interasado en tecnología que en la gente que la usa. Cómo un buen constructor de herramientas, tiene una forma de mirar el mundo que es a partes iguales técnica y humana. Se graduó el primero de su promoción en el Instituto de Tecnología de California, en ingeniería electrica, y se fué a trabajar a una compañia que desarrollaba sintetizadores de música. Este era un problema que se ajustaba perfectamente a su doble personalidad. El podía gastar mucho tiempo pensando la forma en que los musicos usaban el teclado - llegando a ser una extensión de sus manos - así como pensar sobre la parte matemática del proceso de la señal digital.

En los tiempos en que daba la charla que hizo su nombre, la misma que oyeron Resig y Granger en 2012, Victor había aterrizado el principio que parecía que enebraría todo su trabajo. (A la charla la llamó  "Inventing on Principle."). El principio era que: los creadores necesitan conexión inmediata con lo que están creando". El problema es que en programación este principio se viola. Esto es lo que provoca que los sistemas sean tan duros de idear y tan propensos a errores. El programador, mirando a una página de texto,debe abstraerse sobre lo que esté haciendo.

"Nuestra concepción de que es un programa de computador es" , el dijo, esta " directamente derivada de Fortran y Algol en los finales de los 50. Aquellos lenguajes estaba diseñados para tarjetas perforadas" Ese código ahora toma la forma de una carta en una pantalla en un lenguaje como C o Java en lugar de un monton de tarjetas con agujeros, no deja de ser menos anticuado ni menos directo.

Hay una analogía con los procesadores de texto. En los procesadores anteriores usted podía ver el texto y para configurar el diseño o las fuentes o los márgenes, tenía que escribir caracteres especiales "códigos de control" o comandos que le decían al ordenador por ejemplo: "esta parte de texto va en italics". El problema era que usted no podía ver el efecto de estos códigos hasta que no imprimía el documento. Era difícil predecir lo que ibas a obtener. Tenías que imaginar cómo el ordenador iba a interpretar los código, es decir tenía que jugar a, con su cabeza, interpretar lo que iba a hacer el ordenador.

Entonces apareció el concepto WYSIWYG. Significa "Lo que ves es lo que obtienes". Cuando marcabas un pasaje en cursiva, las letras se inclinaban allí mismo en la pantalla. Si quiere cambiar el margen, puede arrastrar una regla en la parte superior de la pantalla y ver el efecto de ese cambio. De este modo, el documento se mostraba como era, y se formateaba haciendo clic aquí y alla. Con solo mirar, sabías  habías hecho algo mal. El control de un sistema sofisticado, para diseñar el formato del documento, estaba disponible para cualquiera que pudiera hacer clic en una página.

El punto de vista de Victor era que la programación en sí se podría hacer así. Para él, la idea de que las personas estaban construyendo software para cosas importantes, como diseñar sistemas adaptativos de control de crucero para aviones o tratar de entender el cáncer, que lo tuviesen que hacer mirando a un editor de texto, era espantoso. Y era el trabajo de los programadores asegurar que algún día no tuvieran que hacerlo.

Había precedentes que sugerían que no era una idea de locos. Photoshop, por ejemplo, ponía a disposición de los usuarios poderosos algoritmos de procesamiento de imágenes aunque ellos no supiesen ni lo que era un algoritmo. Es una pieza de software compleja, en el buen sentido de la palabra, con perillas, botones y controles deslizantes que el usuario aprende a tocar como un instrumento. Squarespace, una compañía que es quizás la mejor conocida por anunciarse agresivamente en podcast, hace herramientas que permiten a los usuarios construir websites haciendo clic, en lugar de escribir código HTML y CSS. Es suficiente poderosa para hacer el trabajo que podría haber sido hecho por un diseñador web profesional.

Pero estos son solo algunos de ejemplos. La abrumadora realidad es que cuando alguien quiere hacer algo comlejo con un ordenador, tiene que escribir código. Victor que es algo idealista, pensó que esto era motivo de bajar la moral de los programadores. Su charla era una llamada a las armas.

En el corazón de todo esto había una serie de demos que mostraban cómo de primitivas eran las herramientas actuales para distintos problemas - diseño de circuitos, animación por computadora, algoritmos de debuggimg - y como se veían las mejores. Sus demos eran virtuosas. El que más llamó la atención fué el que a primera vista era más trivial. Mostraba una pantalla dividida con un juego que se parecía a Mario en un lado y el código que lo controlaba en el otro. Cuando Victor cambiaba el código, las cosas en el mundo del juego cambiaban: disminuyó un número correspondiente a la fuerza de la gravedad y el personaje de Mario flotó; aumentó otra, la velocidad del jugador, y Mario corrió por la pantalla.

Suponga que quiere diseñar un nivel donde Mario, salta y rebota en una tortuga, simplemente lo convertiría en un pequeño pasillo. Los programadores de juegos resuelven esto en dos pasos: primero se concentran en el código - El código que controla cómo salta Mario, cómo de rápido corre, cuán hinchable estaba la espalda de la tortuga - y hacen agunos cambios en el editor de texto, usando su imaginación para predecir el efecto que estos tendrán. Entonces, relanzan el juego para ver lo que ocurre.

Victor quería algo más inmediato. "Si tu tienes un proceso a tiempo" el dijo , refiriendose al camino de Mario mediante el nivel, "y quires ver los cambios inmediatamente, tiene que trazar el mapa tiempo a espacio" El apretaba un boton que mostraba no solo donde estaba ahora Mario sino también donde estaría en cada momento en el futuro: una curva se sombras de Mario estirandose en la distancia.

Además, esta curva proyectada era reactiva: cuando Victor cambiaba los parámetros del juego,  controlandolos por un rápido arrastre del mouse, la forma de la curva cambiaba. Era como tener una vista del juego a los ojos de Dios. Todo el problema se había reducido a jugar con diferentes parámetros, como si se ajustaran los niveles en un receptor estéreo, hasta conseguías que Mario pasaba la aguja. Con la interfaz correcta, era casi como si no estuvieras trabajando con código en absoluto; estabas manipulando el comportamiento del juego directamente.

Cuando la audiencia vió esta acción, quedaron con los ojos abiertos. Sabían que no esto que estaba viendo no era un juego de niños, sino más bien el futuro de la industria. La mayoría del software involucraba comportamientos que se desarrollaban, de manera compleja en su relación con el tiempo, y Victor había demostrado que si se era lo suficientemente imaginativo, se podían desarrollar formas de ver cambiar ese comportamiento, como si estuviera jugando con él en sus manos. Un programador que vio la charla escribió más tarde: "De repente, todas mis herramientas me parecen obsoletas".

Cuando Hohn Resig vio la charla, él cambió sus planes para el plan de estudios de la Khan Academy. Él quería que los ejercicios de los programadores fuesen como las demos de Victor. En el lado izquierdo tenián el código y en el derecho una imagen del juego que estaban programando. Si se cambiaba el código la imagen cambiaba inmediatamente. "En un entorno que es verdaderamente receptivo", escribió Resig sobre el enfoque, "cambia completamente el modelo de cómo aprende un estudiante ... [Ellos] ahora ven inmediatamente el resultado e intuyen cómo funcionan inherentemente los sistemas subyacentes sin siquiera seguir una explicación explicita”. Khan Academy se ha convertido quizás en la clase de programación de computadoras más grande del mundo, con un millón de estudiantes, en promedio, que utilizan activamente el programa.

Chris Granger, que había trabajado en Microsoft en Visual Studio, también se inspiró. A los pocos días de ver un video de la charla de Victor, en enero de 2012, construyó un prototipo de un nuevo entorno de programación. Su capacidad clave era que le proporcionaría comentarios instantáneos sobre el comportamiento del programa. Vería lo que estaba haciendo su sistema justo al lado del código que lo controlaba. Fue como quitarse una venda en los ojos. Granger llamó al proyecto "Mesa de luz".

En abril de 2012, buscó fondos para Light Table en Kickstarter. En los círculos de programación, fue una sensación. En un mes, el proyecto recaudó más de $200,000. Las ideas se difundieron. El concepto de poder ver los datos que fluyen a través del programa al instante, se abrió paso en las herramientas de programación insignia ofrecidas por Google y Apple. Apple desarrolló el lenguaje predeterminado para crear nuevas aplicaciones para iPhone y Mac, llamado Swift, desde cero para soportar un entorno, llamado Playgrounds, que se inspiró directamente en Light Table.

Pero al ver el impacto que su charla terminó teniendo, Bret Victor se desilusionó. "Había muchas  interpretaciones erróneas de lo que estaba diciendo", dijo más tarde. Sabía que algo andaba mal cuando la gente comenzó a invitarlo a conferencias para hablar sobre herramientas de programación. "Todos pensaban que estaba interesado en los entornos de programación", dijo. Realmente estaba interesado en cómo las personas ven y entienden los sistemas, como él lo expresa, en la "representación visual del comportamiento dinámico". Aunque el código se había convertido en la herramienta elegida para crear un comportamiento dinámico, seguía siendo una de las peores herramientas para comprender eso. El objetivo de “Inventing on Principle” era mostrar que se podía mitigar el problema haciendo que la conexión entre el comportamiento de un sistema y su código sea inmediata.

En un par de charlas posteriores, "Stop Drawing Dead Fish" y "Drawing Dynamic Visualizations", Victor fue más allá. Demostró dos programas que había creado, el primero para animadores, el segundo para científicos que intentaban visualizar sus datos, cada uno de los cuales normalmente consistía en un proceso que solía involucrar escribir mucho código personalizado y los redujo a jugar en una interfaz WYSIWYG. Víctor sugirió que se podría hacer el mismo truco para casi todos los problemas donde se estaba escribiendo código actualmente. "No estoy seguro de que la programación tenga que existir", me dijo. "O al menos los desarrolladores de software". En su opinión, el rol apropiado de un desarrollador de software era crear herramientas que eliminaran la necesidad de desarrolladores de software. Solo entonces las personas con problemas que necesitan computación serían capaces de enfrentarlos directamente sin tener que hacerlo a través del código.

Por supuesto, para hacer eso, los programadores tendrían que estar de acuerdo. En un ensayo reciente, Victor imploró a los desarrolladores de software profesionales que dejaran de poner su talento en herramientas para crear aplicaciones como Snapchat y Uber. "Los asuntos de la vida diaria no son los problemas importantes", escribió. En cambio, deberían centrarse en los problemas científicos e ingenieriles, como él me dijo, "estas personas que están haciendo un trabajo que realmente importa, y que es crítico, y que utilizan herramientas muy, muy malas". Un trabajo interesante de este tipo, son las herramientas para el "diseño basado en modelos" que ya estaba en marcha, escribió, y lo había estado durante años, pero la mayoría de los programadores no sabían nada al respecto.

"Si realmente miras detenidamente todos los productos industriales que están en el mercado y que estás usando, que las compañías están usando, lo único que tienes es el código". Eric Bantégnie es el fundador de Esterel Technologies (ahora propiedad de ANSYS), una compañía francesa que fabrica herramientas para construir software crítico para la seguridad. Al igual que Victor, Bantégnie no cree que los ingenieros deban desarrollar grandes sistemas escribiendo millones de líneas de código en un IDE. "Nadie construiría un automóvil a mano", dice. “El código sigue siendo, en muchos lugares, artesanía. Cuando se crean manualmente 10.000 líneas de código, puede valer. Pero tiene sistemas que tienen 30 millones de líneas de código, como un Airbus, o 100 millones de líneas de código, como Tesla en sus autos de alta gama, el software se está volviendo muy, muy complicado ".

La compañía de Bantégnie es una de las pioneras en el uso industrial del diseño basado en modelos, en el que ya no escribe código directamente. En su lugar, crea un tipo de diagrama de flujo que describe las reglas que su programa debe seguir (el "modelo"), y la computadora genera un código para usted basado en esas reglas. Si se hace el sistema de control para un elevador, por ejemplo, una regla podría ser que cuando la puerta está abierta y alguien presiona el botón del vestíbulo, debe cerrar la puerta y comenzar a mover el ascensor. En una herramienta de diseño basada en modelos, representaría esta regla con un pequeño diagrama, como si dibujara la lógica en una pizarra, hecha de cajas que representan diferentes estados, como "puerta abierta", "en movimiento" y "puerta cerrado "- y líneas que definen cómo puede pasar de un estado a otro. Los diagramas hacen obvias las reglas del sistema: con solo mirar, puede ver que la única forma de hacer que el elevador se mueva es cerrar la puerta, o que la única manera de abrir la puerta es detenerse.

Esto no es exactamente cómo Photoshop. La belleza de Photoshop, por supuesto, es que la imagen que estás manipulando en la pantalla es el producto final. En el diseño basado en modelos, por el contrario, la imagen en su pantalla es más como un plano. Aún así, hacer que el software de esta manera es cualitativamente diferente de la programación tradicional. En la programación tradicional, su tarea es tomar reglas complejas y traducirlas a código; la mayor parte de su energía se gasta haciendo la traducción, en lugar de pensar en las reglas mismas. En el enfoque basado en modelos, todo lo que tiene son las reglas. Eso es en lo que pasas el tiempo pensando. Es una forma de enfocarse menos en la máquina y más en el problema que está tratando de resolver.

"Normalmente, el principal problema con la codificación de software, y yo mismo soy un programador", dice Bantégnie, "no son las habilidades de los programadores. La gente sabe codificar. El problema es qué codificar. Debido a que la mayoría de los requisitos son un tipo de lenguaje natural que es ambiguo, un requisito nunca es extremadamente preciso, y el tipo que codifica a menudo lo entiende de manera diferente a cómo lo entiende el que lo formuló".

Desde este punto de vista, el software se vuelve complicado porque los medios para describir lo que debe hacer el software (conversaciones, descripciones en prosa, dibujos en una hoja de papel) son muy diferentes de los medios que describen lo que hace el software, es decir, el propio código. Se pierde demasiado yendo de uno a otro. La idea detrás del diseño basado en modelos es cerrar la brecha. Los diseñadores del sistema utilizan el mismo modelo para expresar lo que quieren y para construirlo. En base al modelo la computadora genera automáticamente el código.

Por supuesto, para que este enfoque tenga éxito, mucho del trabajo debe hacerse antes de que el proyecto comience. Primero alguien tiene que construir una herramienta para desarrollar modelos que sean entendibles para las personas, que sean como las notas y los dibujos que harían ellos mismos, sin dejar de ser lo suficientemente inequívocos para que una computadora los entienda. Tienen que hacer un programa que convierta estos modelos en código real. Y finalmente tienen que demostrar que el código generado hace lo que debe hacer. "Nos hemos beneficiado de afortunadamente 20 años de experiencia", dice Bantégnie.

Esterel Technologies, que fue adquirido por ANSYS en 2012, surgió de la investigación iniciada en la década de 1980 por las industrias nucleares y aeroespaciales francesas, a quienes les preocupaba que a medida que el código crítico para la seguridad aumentara en complejidad, cada vez era más difícil mantenerlo libre de error. "Comencé en 1988", dice Emmanuel Ledinot, director de estudios científicos de Dassault Aviation, un fabricante francés de aviones de combate y aviones comerciales. “En ese momento, estaba trabajando en sistemas de aviónica militar. Y las personas a cargo de integrar los sistemas y depurarlos notaron que la cantidad de errores aumentaba ”. Los años 80 vieron un aumento en la cantidad de computadoras a bordo en los aviones. En lugar de una sola computadora de vuelo, ahora había docenas, cada una responsable de tareas altamente especializadas relacionadas con el control, la navegación y las comunicaciones. La coordinación de estos sistemas para volar el avión a medida que los datos llegaban desde los sensores y los pilotos ejecutaban comandos requería un conjunto de reacciones perfectamente sincronizadas. "El manejo de estos cientos e incluso miles de posibles eventos en el orden correcto, en el momento correcto", dice Ledinot, "fue diagnosticado como la causa principal del crecimiento de errores".  

Ledinot decidió que escribir este código tan complicado a mano ya no era sostenible. Era demasiado difícil entender lo que se estaba haciendo, y casi imposible verificar que funcionaría correctamente. Pensó en algo nuevo. "Cambiar las herramientas es extremadamente costoso en un proceso como este", dijo en una charla. "No tomas este tipo de decisión a menos que estés entre la espada y la pared".

Comenzó a colaborar con Gerard Berry, un científico informático en INRIA, el centro francés de investigación informática, en una herramienta llamada Esterel, un acrónimo del francés en "tiempo real". La idea detrás de Esterel era que, si bien los lenguajes de programación tradicionales podrían ser buenos para describir procedimientos simples que ocurrían en un orden predeterminado, como una receta, si tratas de usarlos en sistemas donde pueden ocurrir muchos eventos en casi cualquier momento, en casi cualquier orden, como en la cabina de un avión, inevitablemente es un desastre. Y un desastre en el software de control era peligroso. En un artículo, Berry fue tan lejos como para predecir que "las técnicas de programación de bajo nivel no serán aceptables para grandes programas críticos de seguridad, ya que hacen que la comprensión y el análisis del comportamiento sean casi impracticables".

Esterel fue diseñado para que la computadora maneje esta complejidad por usted. Esa era la promesa del enfoque basado en el modelo: en lugar de escribir un código de programación normal, creó un modelo del comportamiento del sistema; en este caso, un modelo centrado en cómo deben manejarse los eventos individuales, cómo priorizar los eventos, qué eventos dependían en el que otros, y así sucesivamente. El modelo se convierte en el plan detallado que la computadora usaría para hacer la programación real.

Ledinot y Berry trabajaron durante casi 10 años para llevar a Esterel al punto en que podría usarse en entornos  productivos. "Fue en 2002 que tuvimos el primer entorno de modelado de software operativo con generación automática de código", dijo Ledinot, "y el primer módulo integrado en Rafale, el avión de combate". Hoy, la familia de productos ANSYS SCADE (para "seguridad" en entornos de desarrollo de aplicaciones críticas") es utilizado para generar código por compañías en las industrias aeroespacial y de defensa, en plantas de energía nuclear, sistemas de tránsito, industria pesada y dispositivos médicos. "Mi sueño inicial era tener código generado por SCADE en cada avión del mundo", dice Bantégnie, el fundador de Esterel Technologies, "y no estamos muy lejos de ese objetivo". Casi todo el código crítico para la seguridad en El Airbus A380, incluido el sistema que controla las superficies de vuelo del avión, se generó con los productos ANSYS SCADE.

Parte del atractivo para los clientes, especialmente en la aviación, es que si bien es posible construir software altamente confiable a mano, puede ser un esfuerzo hercúleo. Ravi Shivappa, vicepresidente de ingeniería de software del grupo en Meggitt PLC, un cliente de ANSYS que fabrica componentes para aviones, como detectores de incendios neumáticos para motores, explica que los proyectos tradicionales comienzan con un documento de requisitos masivos en inglés, que especifica todo lo que el software debe hacer. (Un requisito podría ser algo así como: "Cuando la presión en esta sección se eleva por encima de un umbral, abra la válvula de seguridad, a menos que el interruptor de anulación manual esté activado"). El problema al describir los requisitos de esta manera es que cuando implementa en el código, debe verificar minuciosamente que cada uno esté satisfecho. Y cuando el cliente cambia los requisitos, el código también debe cambiarse y probarse exhaustivamente para asegurarse de que no se haya roto nada más en el proceso.

El costo se agrava por los exigentes estándares regulatorios. La FAA es fanática de la seguridad del software. La agencia exige que todos los requisitos para una pieza de software crítico para la seguridad se puedan rastrear todas las líneas de código que lo implementan, y viceversa. Por lo tanto, cada vez que cambia una línea de código, debe volver sobre el requisito correspondiente en el documento de diseño, y debe poder demostrar que el código realmente cumple el requisito. La idea es que si algo sale mal, puedes descubrir por qué; la práctica aporta orden y responsabilidad a las grandes bases de código. Pero, dice Shivappa, "es un proceso que requiere mucha mano de obra". Estima que antes de que usaran un diseño basado en modelos, en un proyecto de dos años solo se gastaban dos o tres meses en escribir el código; el resto se gastaba trabajando en la documentación.

Como explica Bantégnie, la grandeza de tener una computadora que convierta sus requisitos en código, en lugar de un ser humano, es que puede estar seguro, de hecho, puede demostrar matemáticamente, que el código generado realmente satisface esos requisitos. Gran parte del beneficio del enfoque basado en el modelo proviene de poder agregar requisitos sobre la marcha sin dejar de garantizar que se cumplan los existentes; con cada cambio, la computadora puede verificar que su programa aún funciona. Usted es libre de modificar su plan sin temor a introducir nuevos errores. Su código es, en lenguaje de la FAA, "correcto por construcción".

Aún así, la mayoría del software, incluso en el mundo de la aviación obsesionado con la seguridad, se hace a la antigua, con ingenieros que escriben sus requisitos en prosa y los programadores los codifican en un lenguaje de programación como C. Como Bret Victor dejó claro en su ensayo , el diseño basado en modelos es relativamente inusual. "Mucha gente en la FAA cree que la generación de código es mágica y, por lo tanto, exige un mayor escrutinio", me dijo Shivappa.

La mayoría de los programadores sienten lo mismo. A ellos les gusta el código. Al menos lo entienden. Las herramientas que escriben su código por usted y verifican su corrección utilizando las matemáticas de "máquinas de estado finito" y "sistemas recurrentes" suenan esotéricas y difíciles de usar, si no demasiado buenas para ser verdad.

Es un patrón que se ha desarrollado antes. Cada vez que la programación se aleja de la escritura de ceros y unos, las objeciones más fuertes provienen de los programadores. Margaret Hamilton, una célebre ingeniera de software en las misiones Apolo, de hecho, la creadora de la frase "ingeniería de software", me dijo que durante su primer año en el laboratorio Draper en el MIT, en 1964, recuerda una reunión en la que una facción estaba luchando con otra sobre la transición de "un lenguaje de máquina de bajo nivel", al "lenguaje ensamblador". "La gente que defendía el lenguaje de bajo nivel decía: "Bueno, ¿cómo sabemos que el lenguaje ensamblador lo hará bien?"

Emmanuel Ledinot, de Dassault Aviation, señaló que cuando el lenguaje ensamblador se eliminó gradualmente a favor de los lenguajes de programación que todavía son populares hoy, como C, fueron los programadores de ensamblador los que se mostraron escépticos esta vez. Entonces no es de extrañar, dijo, que "las personas no estén haciendo la transición tan fácilmente al desarrollo de software basado en modelos: lo perciben como otra oportunidad para perder el control, incluso más de lo que ya lo han hecho".

El sesgo contra el diseño basado en modelos, a veces conocido como ingeniería dirigida por modelos, o MDE, de hecho está tan arraigado que, según un artículo reciente, "algunos incluso argumentan que existe una mayor necesidad de investigar la percepción de MDE de las personas que de investigar nuevas tecnologías MDE ". Para los defensores del enfoque basado en modelos, suena casi como una broma: ya sabemos cómo hacer que el software complejo sea confiable, pero en muchos lugares, estamos eligiendo no hacerlo. ¿Por qué?

En 2011, Chris Newcombe había trabajado en Amazon durante casi siete años, y se había convertido en ingeniero principal. Había trabajado en algunos de los sistemas más críticos de la compañía, incluido el catálogo de productos minoristas y la infraestructura que administraba todos los dispositivos Kindle del mundo. Fue líder en el equipo de Amazon Web Services, muy apreciado, que mantiene servidores en la nube para algunas de las propiedades más grandes de la web, como Netflix, Pinterest y Reddit. Antes de Amazon, había ayudado a construir la columna vertebral de Steam, el servicio de juegos en línea más grande del mundo. Es uno de esos ingenieros cuyo trabajo mantiene en silencio el funcionamiento de Internet. Los productos en los que había trabajado fueron considerados éxitos masivos. Pero lo único en lo que podía pensar era en que enterrados profundamente en los diseños de esos sistemas había desastres esperando a suceder.

"La intuición humana es pobre para estimar la probabilidad real de combinaciones de eventos en sistemas que operan a una escala de millones de solicitudes por segundo", escribió en un documento. “Esa falibilidad humana significa que algunos de los errores más sutiles y peligrosos resultan ser errores de diseño; el código implementa fielmente el diseño previsto, pero el diseño no puede manejar correctamente un escenario "raro y particular ".

Newcombe estaba convencido de que los algoritmos detrás de los sistemas verdaderamente críticos (sistemas que almacenan una porción significativa de los datos de la web, por ejemplo) no deberían ser solo buenos, sino perfectos. Un solo error sutil podría ser catastrófico. Pero sabía lo difícil que eran encontrar errores, especialmente a medida que un algoritmo se volvía más complejo. Podrías hacer todas las pruebas que quisieras y nunca las encontrarías.

Es por eso que estaba tan intrigado cuando, en el apéndice de un artículo que había estado leyendo, se encontró con una extraña mezcla de matemáticas y código, o lo que parecía un código, que describía un algoritmo en algo llamado "TLA+". Lo sorprendente fue que se dijo que esta descripción era matemáticamente precisa: un algoritmo escrito en TLA+ podría en principio ser correcto. En la práctica, le permitió crear un modelo realista de su problema y no solo probarlo, sino probarlo exhaustivamente. Esto era exactamente lo que había estado buscando: un lenguaje para escribir algoritmos perfectos.

TLA+, que significa "Lógica temporal de acciones", es similar en espíritu al diseño basado en modelos: es un lenguaje para escribir los requisitos (TLA+ los llama "especificaciones") de los programas de computadora. Estas especificaciones pueden ser verificadas completamente por una computadora. Es decir, antes de escribir cualquier código, escriba un esquema conciso de la lógica de su programa, junto con las restricciones que necesita para satisfacer (por ejemplo, si estuviera programando un cajero automático, una restricción podría ser que nunca podrá retirar el mismo dinero dos veces desde su cuenta corriente). TLA+ luego verifica exhaustivamente que su lógica, de hecho, satisface esas restricciones. De lo contrario, le mostrará exactamente cómo podrían violarse.

El lenguaje fue inventado por Leslie Lamport, un científico informático ganador del Premio Turing. Con una gran barba blanca y cabello blanco desaliñado, y ojos amables detrás de grandes anteojos, Lamport parece que podría ser uno de los profesores más amigables en el Hogwarts estadounidense. Ahora en Microsoft Research, es conocido como uno de los pioneros de la teoría de los "sistemas distribuidos", que describe cualquier sistema informático compuesto de múltiples partes que se comunican entre sí. El trabajo de Lamport sentó las bases para muchos de los sistemas que impulsan la web moderna.

Para Lamport, una de las principales razones por las que el software de hoy está tan lleno de errores es que los programadores saltan directamente a escribir código. "Los arquitectos dibujan planos detallados antes de colocar un ladrillo o clavar un clavo", escribió en un artículo. "Pero pocos programadores escriben un esbozo de lo que harán sus programas antes de comenzar a codificar". Los programadores se sienten atraídos por la esencia de la codificación porque el código es lo que hace que los programas funcionen; pasar tiempo en cualquier otra cosa puede parecer una distracción. Y hay una alegría paciente, un tipo de satisfacción meditativa, que se puede tener al descifrar la micromecánica del código. Pero el código, argumenta Lamport, nunca fue un medio para pensar. "Realmente cuando estás pensando en términos de un lenguaje de programación, eso limita tu capacidad de pensar ", dice. El código hace que los árboles no te dejen ver el bosque, ya que llama tu atención sobre piezas individuales, en lugar de la imagen más amplia de cómo encaja tu programa, o qué se supone que debe hacer, y si realmente hace lo que piensas. Es por eso que Lamport creó TLA+. Al igual que con el diseño basado en modelos, TLA+ centra su atención en la estructura de alto nivel de un sistema, su lógica esencial, más que en el código que lo implementa.

Newcombe y sus colegas en Amazon continuarían usando TLA+ para encontrar errores sutiles y críticos en los sistemas principales, incluidos los errores en los algoritmos centrales detrás de S3, considerado quizás el motor de almacenamiento más confiable del mundo. Ahora se usa ampliamente en la empresa. En el pequeño universo de personas que alguna vez habían usado TLA+, su éxito no fue tan inusual. Un pasante en Microsoft usó TLA+ para detectar un error que podría haber causado que todas las Xbox del mundo se bloqueen después de cuatro horas de uso. 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 en aterrizar suavemente en un cometa. Intel lo usa regularmente para verificar sus chips.

Pero TLA+ ocupa solo un pequeño y lejano rincón de la corriente principal, si se puede decir que ocupa algún espacio allí. Incluso para un ingeniero experimentado como Newcombe, el lenguaje se leía al principio como extraño y esotérico: un zoológico de símbolos. Para Lamport, esto es un fracaso de la formación de los programadores. Aunque la programación nació en las matemáticas, desde entonces se ha divo            rciado de ella. La mayoría de los programadores no son muy fluidos en el tipo de matemática (lógica y teoría de conjuntos, en su mayoría) que necesita para trabajar con TLA+. “Muy pocos programadores, e incluidos muy pocos maestros de programación, entienden los conceptos más básicos y cómo se aplican en la práctica. Y parecen pensar que todo lo que necesitan es código ”, dice Lamport. "La idea de que hay un nivel más alto que el código que necesitas entender, y que las matemáticas realmente te permiten entenderlo, es completamente deshechada. Porque nunca lo aprendieron ".

En pocas palabras, Lamport considera que esta incapacidad para pensar matemáticamente sobre lo que están haciendo es el problema del desarrollo de software moderno: las apuestas siguen aumentando, pero los programadores no están avanzando, no han desarrollado las habilidades necesarias para manejar problemas cada vez más complejos . "En el siglo XV", dijo, "la gente solía construir catedrales sin conocer el cálculo, y hoy en día no creo que permitas que nadie construya una catedral sin conocer el cálculo. Y espero que después de un período de tiempo adecuadamente largo, a las personas no se les permita escribir programas si no entienden estas cosas ".

Newcombe no está tan seguro de que el culpable sea el programador. "He oído de Leslie que él piensa que los programadores tienen miedo de las matemáticas. Descubrí que los programadores no son conscientes, o no creen, que las matemáticas pueden ayudarlos a manejar la complejidad. La complejidad es el mayor desafío para los programadores ". El verdadero problema para lograr que las personas usen TLA+, dijo, fue convencerlos de que no sería una pérdida de tiempo. Los programadores, como especie, son implacablemente pragmáticos. Herramientas como TLA+ apestan a la torre de marfil. Cuando los programadores encuentran "métodos formales" (llamados así porque involucran descripciones matemáticas, "formalmente" precisas de programas), su instinto profundo es echarse atrás.

La mayoría de los programadores que estudiaron ciencias de la computación en la universidad han estudiado brevemente métodos formales. Por lo general, se demuestran en algo trivial, como en un programa que cuenta desde cero; el trabajo del alumno es demostrar matemáticamente que el programa, de hecho, cuenta desde cero.

"Necesitaba cambiar las percepciones de las personas sobre los métodos formales", me dijo Newcombe. Incluso el propio Lamport no pareció comprender completamente este punto: los métodos formales tenían un problema de imagen. Y la forma de solucionarlo no era implorar a los programadores que cambiaran, era cambiar usted mismo. Newcombe se dio cuenta de que para llevar herramientas como TLA+ a la corriente principal de programación, tenía que comenzar a hablar su idioma.

Por un lado, dijo que cuando presentara a TLA+ a sus colegas de Amazon evitaría decirles lo que significaba, porque temía que el nombre lo hiciera parecer innecesariamente prohibitivo: "La lógica temporal de las acciones" tiene exactamente el tipo de fallas. suena a eso que funciona bien en la academia, pero desanima a la mayoría de los programadores practicantes. También trató de no usar los términos "formal", "verificación" o "prueba", que recordaban a los programadores los tediosos ejercicios en el aula. En cambio, presentó TLA + como un nuevo tipo de "pseudocódigo", un trampolín hacia el código real que le permitió probar exhaustivamente sus algoritmos, y que lo hizo pensar con precisión al principio del proceso de diseño. "Los ingenieros piensan en términos de depuración en lugar de 'verificación'", escribió, por lo que tituló su charla interna sobre el tema a los ingenieros de Amazon "Diseños de depuración". En lugar de lamentarse por el hecho de que los programadores ven el mundo en código, Newcombe abrazó eso. Sabía que los perdería de otra manera. "He hecho que mucha gente diga:" Ahora lo entiendo "", dice Newcombe.

Desde entonces, dejó Amazon para ir a Oracle, donde pudo convencer a sus nuevos colegas para que probaran TLA+. Para él, usar estas herramientas es ahora una cuestión de responsabilidad. "Necesitamos mejorar en esto", dijo. "Soy autodidacta, he estado codificando desde que tenía nueve años, así que mi instinto era comenzar a codificar. Esa es mi forma de pensar: dibujar algo, intentar algo y evolucionar ”. En su opinión, esto es lo que muchos programadores de hoy todavía hacen. "Buscan en Google y buscan en Stack Overflow" (un sitio web popular donde los programadores responden las preguntas técnicas) "y obtienen fragmentos de código para resolver problemas que tienen en el código lo pegan y continúan". "Y eso está completamente bien hasta que te encuentras con un problema real".

En el verano de 2015, un par de investigadores de seguridad estadounidenses, Charlie Miller y Chris Valasek, convencidos de que los fabricantes de automóviles no se tomaban los errores en el software lo suficientemente en serio, demostraron que un Jeep Cherokee 2014 podría ser controlado remotamente por piratas informáticos. Aprovecharon el hecho de que el automóvil tenía una conexión al movil (de modo que, por ejemplo, puede encender el automóvil el iPhone) y estaba conectado a los sistemas centrales, como el que controla los limpiaparabrisas, dirección, aceleración y frenos (para que, por ejemplo, pueda ver las pautas en la pantalla del retrovisor que responden al girar el volante). Como prueba del ataque, que desarrollaron durante las noches y los fines de semana, piratearon el auto de Miller mientras un periodista lo conducía por la carretera y lo volvieron loco; el periodista, que sabía lo que se avecinaba, entró en pánico cuando se apagaron los motores, obligándolo a moverse lentamente por un tramo de carretera sin arcén.

Aunque en realidad no crearon uno, demostraron que era posible escribir un software inteligente, un "gusano del vehículo", que usaría la computadora a bordo de un Jeep Cherokee pirateado para buscar y piratear a otros; Si hubieran querido, podrían haber tenido acceso simultáneo a una flota nacional de automóviles y SUV vulnerables. (Hubo al menos cinco modelos de Fiat Chrysler afectados, incluido el Jeep Cherokee). Un día podrían haberles dicho a todos que, por ejemplo, giraran repentinamente a la izquierda o apagaran los motores a alta velocidad.

"Tenemos que pensar en el software de manera diferente", me dijo Valasek. Las compañías automotrices han ensamblado durante mucho tiempo su producto final a partir de piezas fabricadas por cientos de proveedores diferentes. Pero donde esas partes alguna vez fueron puramente mecánicas, ahora, casi siempre, vienen con millones de líneas de código. Y aunque parte de este código, para el control de crucero adaptativo, para el frenado automático y la asistencia en el carril, ha hecho que los automóviles sean más seguros ("Las características de seguridad en mi Jeep ya me han salvado innumerables veces", dice Miller), también ha creado un nivel de complejidad que es completamente nueva. Y ha hecho posible un nuevos tipos de fallos.

"Hay muchos errores en los automóviles", dijo Gerard Berry, el investigador francés detrás de Esterel, en una charla. "No es como la aviónica, en aviónica se toma muy en serio. Y se admite que el software es diferente de la mecánica ". La industria automotriz es quizás una de las que aún no se han dado cuenta de que realmente están en el negocio del software.

"No tenemos en la industria automotriz un regulador para la seguridad del software que sepa lo que está haciendo", dice Michael Barr, el experto en software que testificó en el caso de Toyota. NHTSA, dice, “solo tiene una experiencia limitada en software. Han llegado a esto a partir de una historia mecánica ". Las mismas presiones regulatorias que han hecho que el diseño basado en modelos y la generación de códigos sean atractivos para la industria de la aviación han tardado más en llegar a la fabricación de automóviles. Emmanuel Ledinot, de Dassault Aviation, especula que también podría haber razones económicas para la diferencia. Los fabricantes de automóviles simplemente no pueden darse el lujo de aumentar el precio de un componente por unos pocos centavos, ya que se multiplica por millones de veces; Por lo tanto, las computadoras integradas en los automóviles deben reducirse al mínimo, con poco espacio para ejecutar el código que no se ha ajustado a mano para que sea lo más delgado posible. "La introducción del desarrollo de software basado en modelos fue, creo, durante la última década, demasiado costosa para ellos".

Uno sospecha que los incentivos están cambiando. "Creo que el automóvil autónomo podría empujarlos", me dijo Ledinot, "ISO 26262 y el automóvil autónomo podría empujarlos lentamente a adoptar este tipo de enfoque en las partes críticas" (ISO 26262 es un estándar de seguridad para automóviles publicado en 2011. ) Barr dijo lo mismo: en el mundo del automóvil autónomo, el software no puede ser una cosa ideada a última hora de cualquier manera. No se puede construir como los sistemas de reserva de aerolíneas actuales o los sistemas 911 o los sistemas de negociación de acciones. El código se pondrá a cargo de cientos de millones de vidas en el camino y tiene que funcionar. Esa no es una tarea pequeña.

"La informática es fundamentalmente invisible", dijo Gerard Berry en su charla. “Cuando sus neumáticos están desinflados, los mira, están desinflados. Cuando el software no funciona, usted mira el software y no ve nada ".

"Entonces eso es un gran problema".

Mejorar el canal DevOps: Cómo tratar la seguridad y proteger el canal de despliegue

En “The DevOps handbook” de Jez Humble, John Willis, Patrick Debois y Gene Kim publicado por IT Revolution Press en 2016, tratan dos temas en la parte VI del libro. Uno de ellos es como integrar los trabajos que incorporan seguridad a los sistemas en Dev y en Ops, el otro como proteger el entorno del canal de despliegue formado por servidores en los que residen los entornos en los que se construye y explota el software. En este post se hace un resumen de lo propuesto en este texto.

Tratando la seguridad

Un pretesto para no implementar los principios y patrones de DevOps es a menudo "la seguridad de la información y el cumplimiento de las normas no nos lo permiten". Paradójicamente Devops puede ser una de las mejores formas de integrar la seguridad de la información en el trabajo diario.

El ratio de ingenieros de desarrollo, de operaciones y de seguridad en una organización suele ser respectivamente de 100:10:1. Cuando seguridad no dispone de procesos de automatización y de gestión de la seguridad en el día a día de Dev y Ops, lo único que puede hacer es validar si lo desarrollado y desplegado cumple con ciertos niveles de seguridad. Esto no es muy útil ya que se obtiene información de cómo incorporar seguridad cuando todo está ya construido y es difícil o imposible de resolver.

Para que esto no ocurra se recomienda tomar las siguientes acciones:

• Integrar a seguridad en las demos

Invitando a los especialistas en seguridad a las demos cuando finalizan los sprints, se consigue que asesoren a los desarrolladores en etapas tempranas de la construcción del código. De esta forma, el desarrollo se hará teniendo en cuenta las  necesidades de seguridad. Esto es más sencillo y barato que esperar hasta que todo está construido y después modificarlo para incorporar seguridad.

• Integrar a ingenieros de seguridad en seguimiento de defectos y en reuniones Post-Morten

Tras el acaecimiento de un fallo se debe organizar una reunión post-morten para analizar qué motivos lo provocaron y que solución se ha adoptado. Mediante la información recopilada en estas reuniones la organización va atesorando una fuente de conocimiento que la ayudará a trabajar mejor en el futuro. El objetivo es que no se vuelvan a provocar fallos parecidos y si se producen saber cúal puede ser la solución a aplicar.
Con el objetivo de tener en cuenta en los aspectos de seguridad, es adecuado invitar a ingenieros de seguridad a estas reuniones post-morten.

• Añadir mecanismos y herramientas que ayuden a asegurar que las aplicaciones y entornos están seguros.

Se tienen que proporcionar librerías y servicios de seguridad que proporcionen autenticación, autorización, gestión de contraseñas, encriptación de datos, etc. Se pueden incluir:

    - Modos de acceso seguro (por ejemplo, 2FA, bcrypt password. logging)
    - Herramientas para almacenar y proteger tokens, contraseñas, etc. (Por ejemplo: usando                        herramientas cómo Vault, sneaker, Keywhiz, credstash, Trousseau, Red October)
    - Paquetes para securizar (por ejemplo, NTP para sincronización de la hora de servidores,                     versiones seguras de OpenSSL, OSSEC para detección de intrusos)

• Integrar a seguridad en el canal DevOps 

Antes de DevOps para conseguir aplicaciones seguras se revisaban las cuestiones de seguridad una vez que el desarrollo estaba completado. Normalmente el resultado eran informes con decenas o cientos de hojas en los que se indicaban las vulnerabilidades de la aplicación. Muchas veces abordar los cambión necesarios para eliminar todas estas vulnerabilidades era imposible. Solucionar esto se consigue integrando a los especialistas de seguridad en etapas tempranas del desarrollo y la implantación  que asesoren a Dev y Ops. 

• Asegurar la seguridad de la aplicación

Consiste en establecer los medios de aseguramiento necesarios para que cuando el código llegue a producción esté en las condiciones óptimas y cumpla con todas las normas de seguridad. Para ello es oportuno establecer validaciones y verificaciones que pueden ser:

- Análisis estáticos. Con alguna herramienta revisar el código buscando debilidades, puertas traseras y código potencialmente malicioso.

- Análisis dinámicos. Los análisis dinámicos monitorizan elementos tales como la memoria, el comportamiento funcional, los tiempos de respuesta y el rendimiento del sistema. Estos análisis emulan lo que suele hacer el software malicioso y detecta vulnerabilidades.
- Búsquedas de amenazas en dependencias. Los sistemas hacen uso de librerías de terceras partes. Es necesario comprobar que dichas librerías están libres de vulnerabilidades.
- Integridad del código y firma del desarrollador. El repositorio de código es muy vulnerable, los commits deberían estar firmados para asegurarnos que han sido realizados por las personas autorizadas.

• Asegurar la seguridad de la cadena de suministro de software

Los desarrolladores utilizan múltiples librerías que realizan funcionalidades que necesitan. Realmente en gran parte construyen sus sistemas ensamblando partes de librerías de terceros. La cadena de suministro que proporciona esas librerías también hay que asegurarla. Es necesario controlar que durante el proceso de adquisición de estas librerías no se produzcan brechas en la seguridad.

• Asegurar la seguridad del entorno

Se trata de establecer controles que monitoricen las instancias de producción, para controlar que todos los entornos están en el estado esperado. Esto se consigue a través de pruebas automatizadas para asegurar que las configuraciones de bases de datos, sistemas operativos, redes, etc. son las adecuadas. Estas pruebas buscan vulnerabilidades.

• Vigilar la información de seguridad añadida a la telemetría de producción 

A veces los controles de seguridad son inefectivos para detectar brechas en el momento oportuno. Esto puede deberse a que tenemos puntos ciegos en nuestra monitorización o porque nadie examina la telemetría a diario.

Marcus Sachs, uno de los investigadores de brechas en seguridad de Verizon Data dijo en 2010, "Año tras año, en la vasta mayoría de las brechas en la seguridad de los datos, las organizaciones las detectan pasados meses. Y lo que es peor las brechas se detectan desde fuera de la organización porque algún socio o cliente es víctima de alguna transacción fraudulenta. Una de las causas de que esto ocurra es que nadie en la organización revisa regularmente los ficheros de log."

• Crear telemetria para controlar la seguridad de los entornos

Dentro del programa de mediciones a obtener, es interesante obtener medidas dedicadas a mantener los sistemas seguros. Se pueden medir:

- Cambios a los sistemas operativos
- Cambios a los grupos de seguridad
- Cambios a las configuraciones
- Cambios a la infraestructura de la nube 
- Intentos XSS (“cross-site scripting attacks”)
- Intentos SQLi (“SQL injection attacks”)
- Errores de servidor Web (4XX y 5XX)

Estas medidas pueden servir para detectar vulnerabilidades. Por ejemplo, se han detectado en marzo el doble de cambios en configuraciones que en febrero. Esta información sirve para indicar que hay que vigilar si es correcto que se haya duplicado el número de cambios. 

• Proteger los entornos y servidores

La infraestructura que soporta la integración continua y el despliegue continuo presenta una nueva área de vulnerabilidad a los ataques. Por ejemplo si alguien compromete algún servidor que aloja las credenciales para el sistema de control de versiones, puede ocurrir que alguien robe el código fuente. Peor todavía si en estos servidores hay permiso de escritura, un atacante podría inyectar cambios maliciosos en el repositorio de código.

Protegiendo el canal de despliegue

• Integrar seguridad y cumplimiento en el proceso de cambios

En las organizaciones suele existir un proceso para gestionar los cambios y que estos no disturben el normal suceder de los acontecimientos. ITIL clasifica los cambios en tres tipos: estándar, normal o urgente. Cada uno de ellos implica un nivel de riesgo distinto. Los cambios pequeños que implican poco riesgo se deberían automatizar o por lo menos eliminar la necesidad de aprobaciones por parte de comités o personas antes de su implantación, esto se suele convertir en cuellos de botella o traducir en tiempos de entrega largos. Los normales, sí se tratan a través de algún proceso de aprobación y los urgentes tendrán un proceso aparte donde se intente que no conduzcan a resultados no deseados.

•  Re categorizar la mayoría de los cambios de bajo riesgo como cambios estándar

Teniendo un canal DevOps que funciona adecuadamente, el área de TI tendrá buena reputación. Los despliegues y puestas en marcha se harán de forma rápida y segura. Se dispondrá de una historia de cambios de éxito y en el caso de problemas de un tiempo de resolución pequeño.
Estando en esta situación es bueno intentar que clasifiquemos de estándar todos los cambios que podamos. Esto es porque no hay mucho riesgo de que produzcan problemas y si los producen se resolverán de forma inmediata.

• Qué hacer cuando los cambios se catalogan como cambios normales

Para aquellos cambios que no se puedan clasificar de estándar se seguirá realizando las aprobaciones que se requieran, pero es importante asegurarse de que se automatiza todo lo que se pueda para que los despliegues sean lo más rápidos posible.
Para su correcta gestión debemos añadir a estos cambios toda la información que sea necesaria para que las aprobaciones sean lo más ágiles posible.
Es importante mantener un historial de cambios ejemplar, de esta forma podemos ganar la confianza de la organización y convertir una gran mayoria de los cambios en cambios estándar.

• Reducir la división de tareas

La separación de tareas a menudo reduce el feedback que los ingenieros reciben de su trabajo. Esto hace que sea más difícil que se sientan responsables de su trabajo. Se debe intentar donde se pueda evitar la separación de tareas, en su lugar preparar formas de trabajo colaborativas, por ejemplo pair programming, peer review, sesiones de trabajo de ingenieros dev y ops conjuntas.

• Proveer documentación y pruebas para auditores y agentes responsables de cumplimiento

Bill Shinn es arquitecto de soluciones de seguridad de Amazon Web Services y dice " En DevOps se trata de tender un puente entre Dev y Ops. Además existe el reto todavía más grande de tender el puente entre DevOps y los auditores y agentes de cumplimiento. Por ejemplo, cuantos auditores entienden el código y cuantos desarrolladores se han leído la norma NIST 800-37 del instituto de estándares y tecnología de Estados Unidos.
Hay que buscar los medios para suministrar la información a auditores y agentes dentro del canal DevOps.

Conclusiones

Los principios DevOps se pueden aplicar a la seguridad de la información, haciendo que el trabajo de los ingenieros de seguridad se integre en el de los de desarrollo y operaciones. Esto se consigue haciendo que la seguridad sea parte del trabajo diario de todos. Además se integran los controles de seguridad en los planes de métricas que debe utilizar el canal DevOps para mantener los entornos en un estado protegido y con un bajo perfil de riesgo.

Que con buenas prácticas DevOps la seguridad mejore hace que cuidemos mejor de los datos, también que sea posible recuperarse de los incidentes que producen las brechas de seguridad antes de que sean catastróficos y lo más importante de todo que la seguridad de nuestos datos y sistemas sea mejor que ha sido nunca.

Mejorar el canal DevOps: Empleando técnicas de aprendizaje.

Aprender de los éxitos y los fracasos permite mejorar en todos los aspectos de la vida. Emplear esta filosofía es aplicable a los equipos que realizan las actividades en el canal DevOps para conseguir gestionar el ciclo de vida de los sistemas, las aplicaciones, los micro-servicios, las apps, las bases de datos, los sistemas operativos, las redes y demás componentes que conforman la plataforma tecnológica de la información en las organizaciones.

En “The DevOps handbook” de Jez Humble, John Willis, Patrick Debois y Gene Kim publicado por IT Revolution Press en 2016 se proponen tres formas para mejorar el canal DevOps. La primera forma está resumida en el post “Cómo mejorar el canal DevOps. Primeros pasos.” de este blog. La segunda forma está resumida en el post “Mejorar el canal DevOps: Manejando el feedback.” La tercera y última es la que se va a resumir en este post. 

Los autores de este libro recomiendan para mejorar el canal DevOps empleando técnicas de aprendizaje:

•  Facilitar e inyectar aprendizaje en el día a día 
•  Inyectar fallos en producción para crear resistencia a fallos
• Convertir descubrimientos locales en mejoras globales
•  Reservar tiempo para conseguir aprender y mejorar

Facilitar e inyectar aprendizaje en el día a día

Para que los equipos puedan aprender de sus errores hay que implantar una cultura de “no búsqueda de culpables”.  Es decir, cuando las respuestas a incidentes y accidentes se gestionan principalmente con la búsqueda de culpables se dificulta la realización de las investigaciones adecuadas, promoviendo más bien el miedo que la atención plena de las personas que están realizando trabajos. Teniendo en cuenta que estos trabajos suelen ser críticos para la organización, que los ejecutores de los mismos vivan atemorizados no es útil. Que las personas estén atemorizadas promueve organizaciones más burocráticas que resolutivas, cultivando el secretismo, la evasión de responsabilidades y la auto-protección.”

En lugar de buscar culpables es mejor recopilar información tras los fallos, se pueden realizar reuniones post-morten. Es importante difundir los detalles del  motivo y resolución del fallo para que cualquiera pueda consultarlos.

Se debe fomentar la investigación constante analizando el motivo de cada fallo por pequeño que este sea. A medida que se van solucionando fallos se deben investigar fallos más leves actuando de esta manera de forma sostenida y tratando cada vez fallos de más bajo nivel.

Los fallos son inevitables, cuantos más cambios se hacen más probable es cometer fallos. Esto no quiere decir que no debamos hacer cambios, al revés los cambios son la única forma de mejorar pero pueden tener efectos colaterales. Entonces lo más cabal es promover los cambios y actuar calibrando el riesgo que hay que asumir. Cómo ejemplo:

“Hubo una gran caída en Netflix  que fue causada por un error francamente tonto.  El error fue provocado por un ingeniero que había tirado Netflix 2 veces en los últimos 18 meses. Pero este ingeniero es de mucha utilidad para Netflix. En estos 18 meses había trasformado el estado de las operaciones mejorando la automatización de los procesos. Su trabajo ha permitido hacer despliegues más seguros en producción”. Es decir el ingeniero provocó problemas pero por qué estaba haciendo cambios que finalmente han reportado muchos beneficios.

Inyectar fallos en producción para crear resistencia a fallos

Otras técnicas que pueden ayudar a aprender son: provocar errores a propósito para aprender a resolverlos e institucionalizar días de trabajo dedicados a experimentar fallos. A este propósito existe una herramienta llamada Chaos Monkey construida por Netflix que simula caídas de servidores sobre sistemas en producción. Trabajando en los problemas generados  las instalaciones consiguen sistemas más robustos preparados para cualquier eventualidad.

Convertir descubrimientos locales en mejoras globales

Cuando se descubre algo de interés en un punto de la organización, es importante hacerlo llegar al resto. Para ello es mejor buscar medios que sirvan para que todos los miembros de la organización puedan acceder a la información. Por ejemplo, es mejor utilizar un chat que la utilización del email para compartir información acerca de la resolución de incidentes. De esta forma todo el mundo está al tanto de los incidentes que han acaecido y aprenden de su solución.

Otra forma de difundir conocimiento es automatizar procesos que sean exitosos. De esta manera es más fácil hacerlos llegar a todos los rincones de la organización.

Utilizar un solo repositorio de código para toda la organización consigue que todos los equipos compartan el código. Google lo hace para más 25.000 desarrolladores. Para que el trabajo fluya de forma consistente es necesario establecer políticas de uso del repositorio. Por ejemplo, para el uso de ramas, para la gestión de dependencias, la gestión de versiones, etc.

También las pruebas automatizadas son útiles para transmitir información.  Las pruebas unitarias sirven de documentación del código. Usar TDD entre otras ventajas consigue que las pruebas automatizadas existan y estén al día respecto al código que testean

.

Por otra parte, los desarrolladores deberían acompañar a operaciones en el despliegue y puesta en marcha del software. Cuando los desarrolladores conocen la problemática del área de operaciones, diseñan sistemas que colaboran en su puesta en producción.

Disponer de herramientas de automatización que  por ejemplo extraigan el código del repositorio, lo desplieguen en el entorno de pre-producción, ejecuten las pruebas unitarias, realicen un análisis de código estático y marquen cómo disponible el código para producción o no. Estas herramientas facilitan que los desarrolladores puedan tener un self-service de puesta en producción, es decir ellos mismos liberan software en producción.

También es interesante acordar un marco arquitectónico entre desarrollo y operaciones. Este marco no debe ser rígido, pero si marcar los límites a no traspasar si los desarrolladores quieren acogerse a las áreas soportadas por operaciones. El marco arquitectónico se refiere a las tecnologías empleadas para desarrollar: lenguajes, bases de datos, frameworks, sistemas operativos, etc. Para ilustrar mejor esta idea, considerar que respecto al uso de distintas tecnologías ponemos las que actualmente están soportadas separadas por una boyas de las que no. Los desarrolladores son libres de traspasar la boya, pero ahí tendrán menos soporte que dentro del perímetro señalizado. La metáfora de las boyas sirve para indicar que entre las tecnologías soportadas y las no soportadas no hay un muro in-traspasable.

Reservar tiempo para conseguir aprendizaje y mejorar

Blitz improvement proviene del ciclo Kaizen cuyo objetivo es la mejora. El término Blitz improvement se puede traducir como “bombardeo de mejoras”. Aplicar esta técnica, consiste en reservar un tiempo para que los equipos ideen mejoras para problemas conocidos. Existen muchos casos de éxito asociados al uso de esta técnica.

También se puede dedicar un tiempo periódicamente a eliminar deuda técnica, se trata de dedicar cierto tiempo a trabajar en los sistemas sin ampliar ni modificar funcionalidades. 

Formas de aprender también se pueden conseguir organizando eventos en los que los profesionales enseñen lo que saben a otros y escuchen lo que otros les puedan enseñar. Además es interesante participar en eventos DevOps externos a la organización, compartir experiencias con otros será enriquecedor.

Difundir las buenas prácticas que se hayan puesto en funcionamiento en algún lugar de la organización a todos los demás se puede hacer asignando consultores internos especializados a equipos que necesiten aplicar dichas prácticas. También se pueden contratar consultores externos con especialidad en alguna técnica en la que los equipos no tengan experiencia.

Conclusiones

La tercera forma, explora prácticas que ayudan a crear una cultura de aprendizaje y experimentación. Aprender de los incidentes, crear repositorios únicos para todos los desarrolladores y compartir los descubrimientos entre todos es esencial cuando se trabaja en sistemas complejos, ayudando a caminar hacia una cultura más justa de trabajo en las cuales no se busquen culpables y hacer sistemas más seguros y robustos.

Mejorar el canal DevOps: Manejando el feedback.

En el contexto de este post feedback o retroalimentación significa: recoger datos de la ejecución de las tareas realizadas en el área de Tecnologías de la Información, analizar estos datos para obtener conclusiones objetivas sobre el resultado de las actividades y en base a estos datos planificar maneras de mejorar.

Por otro lado el canal DevOps es el conjunto de procesos y actividades que se realizan en una instalación para cubrir el ciclo de vida del software, desde su concepción hasta su puesta en producción

 Sentando las bases

La Real Academia Española de la Lengua define retroalimentación cómo “el retorno de parte de la energía o de la información de salida de un circuito o un sistema a su entrada”.

Wikipedia  define retroalimentación cómo “un mecanismo por el cual una cierta proporción de la salida de un sistema se redirige a la entrada, con señales de controlar su comportamiento”.

Un ejemplo, se dispone de una web de comercio electrónico de venta de libros. Se planifica mejorar la web con el objetivo de vender más libros. Para ello:

• Se realiza el conteo de libros vendidos cada día.
• Se calcula el número medio de libros vendidos a la semana.
• Se aplica algún cambio sobre la web. Por ejemplo se decide incorporar descuentos para los mejores clientes.
• Se compara el número medio de libros vendidos en las semanas anteriores y posteriores a la mejora.
• Si se han vendido más libros después del cambio, podemos en general sacar la conclusión de que el cambio ha sido un éxito.

En esencia esta es la base. Viendo la retroalimentación desde este punto de vista, esta puede ayudar a mejorar el canal DevOps o cualquier otro proceso en las organizaciones.

¿Qué sé puede hacer para mejorar el canal DevOps?

En el libro “The DevOps handbook” de Jez Humble, John Willis, Patrick Debois y Gene Kim publicado por IT Revolution Press en 2016 proponen tres formas para mejorar el canal DevOps. La primera forma está comentada en el post “Cómo mejorar el canal DevOps. Primeros pasos.” de este blog. La segunda forma consiste en manejar adecuadamente la retroalimentación. Para realizar una correcta gestión de la retroalimentación, el libro la enfoca desde distintos puntos de vista:

Crear telemetría para permitir encontrar y después resolver problemas

Un hecho real es que pequeños cambios pueden desestabilizar un sistema y conducir a caídas o fallos globales. No es fácil que alguien tenga suficiente conocimiento para tener una visión global de la instalación y poder saber donde se encuentra el problema. Los sistemas suelen ser complejos y el fallo puede estar en muchos sitios distintos. Para resolver el problema es necesario tener información y esta información está disponible si se han previsto los mecanismos necesarios para guardarla.

Uno de los descubrimientos del informe “State of DevOps” de 2015 fue que los equipos de operaciones que consiguen solucionar los problemas más rápidamente, emplean dos técnicas: el uso de un sistema de control de versiones y otra haciendo mediciones y monitorizándolas proactivamente en el entorno de producción.

Analizar la telemetría para anticiparse a los problemas y alcanzar los objetivos

Es deseable prever los problemas para evitar que se produzcan. Esto se puede conseguir monitorizando el funcionamiento de los sistemas y produciendo alertas cuando se detecte alguna anomalía.

Se pueden usar medias, desviaciones estándar, patrones de comportamiento de los datos, cualquier mecanismo puede ser bueno para detectar si se está produciendo una anomalía e intentar resolverla antes de que provoque caídas o efectos no deseados.

Habilitar feedback para que desarrollo y operaciones puedan desplegar código de forma segura

Es necesario que los equipos de desarrollo sepan las consecuencias del despliegue de los cambios que efectúan en el código. Para ello es conveniente que los desarrolladores participen en las tareas de puesta en marcha.

Se pueden establecer medios para que los desarrolladores puedan desplegar en producción los sistemas por sí mismos. La clave está en la automatización, hay muchas herramientas disponibles para poder controlar automáticamente múltiples aspectos del código antes de desplegarlo: pruebas automatizadas a todos los niveles, cobertura de pruebas, análisis estático de código, gestión de dependencias, etc. Todas estas herramientas contribuyen a qué la puesta en producción pueda estar en manos de los equipos de desarrollo.

Integrar desarrollo conducido por la hipótesis y A/B testing en el trabajo diario

Hay funcionalidades que se ponen en producción y nadie las utiliza. Poner en producción código que no es útil a los usuarios es negativo, porque es trabajo inútil y porque además es un código que sin ser útil hay que mantener.  

El A/B testing puede minimizar esta problemática. A/B testing consiste en poner en producción distintas versiones de una misma funcionalidad. Cada versión se le ofrece a un grupo de usuarios diferente. Luego se estudia que versión funcionó mejor y es la que se implanta.

Un paso más allá es el desarrollo conducido por la hipótesis. Este consiste en partiendo de una necesidad detectada por los expertos en negocio, realizar un experimento de implementación (no completa) y ponerlo en producción de forma controlada. Con la aceptación o no aceptación de los usuarios de las funcionalidades suministradas en el experimento, se valida si la hipótesis es una necesidad real o no. En función del resultado del experimento se actúa continuando con la implementación o abandonando la hipótesis.

Crear procesos de coordinación y revisión que incrementen la calidad del trabajo

Con el objetivo de anticiparse a los problemas que un cambio puede producir en producción, es adecuado establecer los medios de revisión y coordinación necesarios.

Ahora bien, no se trata de implantar burocráticos procesos realizados por terceras partes, ajenas al proceso de construcción y despliegue del código. Los procesos realizados por terceros tienden a alargar los procesos de despliegue y a no ser efectivos. Es difícil averiguar los problemas que tiene un código al que se es ajeno.

Es más útil preparar procesos de revisión entre compañeros o iguales (peer review). Un ejemplo de revisión entre compañeros es el pair programming, en esta técnica dos desarrolladores trabajan sobre el mismo código. De esta forma el código cuando está terminado ya está revisado y validado por dos programadores.

Conclusiones

Se ha abordado la retroalimentación desde distintos puntos de vista:

• Retroalimentación recogiendo datos sobre ejecución de tareas y análisis de los mismos para mejorar
• Retroalimentación a los equipos de desarrollo no ajenos a las consecuencias de la implantación de su código en producción
• Retroalimentación sobre los efectos de un cambio con A/B testing
• Retroalimentación para asegurar hipótesis antes de implementar mediante desarrollo dirigido por la hipótesis
• Retroalimentación partiendo de revisiones para obtener información de las consecuencias de la implantación

Todas estas formas de aprovechar las ventajas de la retroalimentación pueden ser fuente de inspiración para la mejora del canal DevOps.