Arquitectura de subconsumo: Cómo iRobot habilitó Scrum

por Jeff Sutherland | 14 de febrero de 2020 | Blog | 0 comentarios

Una definición sencilla de Arquitectura de subsunción en Wikipedia. Sin embargo, esa definición es una versión diluida de la realidad.

Es como escuchar la historia de cuarta mano, donde la comprensión se hace cada vez más débil a medida que pasa de persona a persona. Obtendrá una imagen mucho más clara si lee a alguien que trabaja en la zona. Control de robots móviles.

A principios de los noventa, alquilé un espacio de oficinas durante un par de años al inventor de la Arquitectura del Subsumo. Rodney Brooks y sus estudiantes de posgrado utilizaron ese espacio para fundar iRobot. Así que Brooks y su equipo me enseñaron directamente utilizando robots reales como demostración de lo que decía.

Los robots se escapaban a menudo de su laboratorio y entraban y salían de mi oficina con regularidad. Recibirlo directamente de la fuente es siempre una experiencia más vívida y precisa. Eche un vistazo a los artículos de Brooks sobre scholar.google.compor ejemplo, éste sobre sistemas robustos de control por capas. 

Los viernes por la tarde, Brooks venía a ver a su equipo. Uno de esos viernes, le pedí al profesor Brooks que me explicara cómo funcionaba el robot (que entonces se llamaba Ghengis Khan). "Es muy interesante", añadí, "cuando entra corriendo en mi despacho intentando cazarme con sus sensores infrarrojos".

Fotografía: Carlton SooHoo, PanoSpin

Brooks dijo: "Primero tienes que entender que durante 30 años hemos intentado construir un sistema inteligente en el Laboratorio de Inteligencia Artificial del MIT y ha sido un fracaso total". Lo mejor que habían sido capaces de hacer, me dijo Brooks, era un programa de ajedrez inteligente.

"Así que estoy adoptando un enfoque radicalmente distinto con la arquitectura de subsunción. Este robot no tiene procesador central. Cada pata tiene un chip que puede moverla. Hay un chip en la columna vertebral que coordina las piernas. Un chip de red neuronal en la cabeza decide qué hacer. Antes de encender el robot, el chip está en blanco. No existe ninguna base de datos. El mundo son los datos y todos los datos los crean los sensores."

Me enseñaban el chip vacío, lo conectaban al cabezal y encendían el robot. Sus patas empezaban a agitarse como las de un pulpo y rodaba erguido, luego se tambaleaba como un bebé que aprende a andar hasta que unos minutos más tarde correteaba por la habitación.

Le dije a Brooks que esto me recordaba a los programadores realmente lentos que tenía en la empresa bancaria frente a la Sloan Business School del MIT. "Apuesto a que si les diéramos a los programadores lentos unas reglas sencillas como las del robot y cada día se juntaran y sincronizaran sus redes neuronales podrían arrancar hasta convertirse en un equipo superinteligente y muy rápido". Entonces pregunté: "¿Crees que funcionaría?". Brooks respondió: "No lo sé, ¿por qué no lo pruebas?".

Al año siguiente entré en Easel Corporation y tuve mi oportunidad. El Scrum arrancó igual que el robot.

Así, Scrum surgió de una profunda inmersión en el trabajo de investigadores primarios en robótica y teoría de la informática, principalmente en el MIT y los Laboratorios Bell, pero también de la teoría de sistemas adaptativos complejos basada en la simulación por superordenador de células en evolución durante mis 11 años de investigación en la Facultad de Medicina de la Universidad de Colorado.

Siempre me ha interesado ver a gente intentando retocar el Scrum sin entender la arquitectura de subsunción. Es como si un hombre de las cavernas se encontrara con un smartphone e intentara arreglarlo.

Recuerdo a un vicepresidente de ingeniería en Silicon Valley que me dijo por la época de la reunión del Manifiesto Ágil, quizá antes. "¡El Scrum es lo más grande que ha llegado al valle desde la invención del chip informático!".

Se diseñó para resolver el problema de la ley de Moore, que provocaba aumentos exponenciales de la potencia de cálculo, mientras que la productividad del desarrollo de software crecía linealmente.

Hoy en día, con el despliegue continuo varias veces al día a partir de una única rama de código como hacen en Google y en otros lugares, estamos viendo órdenes de magnitud de mejora en la productividad, algo que traté de explicar en mi trabajo de investigación Agile 2005 sobre "El futuro de Scrum."

La última iteración de este tipo de pensamiento está en los coches autoconducidos. En 2016 actualicé mi Tesla a la última versión con la nueva placa inteligente de NVidia y sensores ampliados. Se trata de una caja $500 que es una versión comprimida de un superordenador $50M del año 2000.

Y Elon Musk dice que programarlo requiere miles de desarrolladores, pero sólo unos pocos años de iteraciones. No sería posible construirlo sin la combinación de los chips de hardware y métodos ágiles.

Mientras tanto, Google sigue atascada con los coches inteligentes en un entorno de laboratorio. No son lo suficientemente ágiles.