La arquitectura de la complejidad

Herbert A. Simon dedicó su vida al estudio de sistemas: organizaciones, economía o inteligencia artificial. En 1962, publicó un paper titulado «The architecture of complexity» donde presenta cómo el estudio general de sistemas significa entender la formación de jerarquías.

Sistemas complejos y jerarquías

Simon aproxima un sistema complejo como aquél que está compuesto por un número grande de componentes que interactúan de manera no trivial. Un sistema jerárquico sería aquél que se puede descomponer en subcomponentes interrelacionados, que no necesariamente tienen que estar subordinados en una relación de autoridad maestro-esclavo.

La razón por la que es más habitual encontrar jerarquías de cualquier tipo en los sistemas complejos es porque forman estructuras estables de manera más rápida. Para defender esta tesis repasa ciertos ejemplos de la naturaleza y sociales, pero baste cita la famosa parábola de los dos relojeros para entender lo que quiere decir:

There once were two watchmakers, named Hora and Tempus, who manufactured very fine watches. Both of them were highly regarded, and the phones in their workshops rang frequently – new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer and finally lost his shop. What was the reason?

The watches the men made consisted of about 1.000 parts each. Tempus had so constructed his that if he had one party assembled and had to put it down -to answer the phone, say- it immediately fell into pieces and had to be reassembled from the elements. The better the customers liked his watches, the more they phone him, the more difficult it became for him to find enough uninterrupted time to finish a watch.

The watches that Hora made were no less  complex than those of Tempus. But he had designed them so that he could put together subassemblies of about ten elements each. Ten of these subassemblies, again, could be put together into a larger subassembly; and a system of ten of the latter subassemblies constituted the whole watch. Hence, when Hora had to put down a partly assembled watch in order to answer the phone, he lost only a small part of his work, and he assembled his watches in only a fraction of the man-hours it took Tempus.

Es decir, la organización en subsistemas, facilitaría la estabilidad de la estructura global.

Sistemas casi-descomponibles

Para entender las jerarquías, Simon propone dos aspectos fundamentales:

  • el número de componentes en que se particiona el sistema: o el span. En los límites, un sistema jerárquico con span = 1 sería una cadena de componentes; un sistema jerárquico se consideraría como plano si su span es alto.
  • cómo se agrupan sus componentes: aunque los sistemas físicos y químicos se suelen agrupar por las propiedades espaciales y los sociales por la interacción entre componentes, Simon argumenta que esta es una falsa dicotomía. Él propone que los componentes de un sistema se agrupan por la “intensidad de la interacción” entre ellos y que la cercanía espacial es un subproducto de ciertas estructuras físicas que necesitan cercanía para intercambiar información.

Es precisamente la interacción –entre subsistemas y dentro del subsistema- lo que Herbert usa para estudiar las jerarquías. Su tesis es que podemos entenderlas como sistemas casi-descomponibles: es decir, que las interacciones dentro de un subsistema son muy intensas mientras que las interacciones entre subsistemas son más débiles aunque no despreciables. En parábola:

Consider a building whose outside walls provide perfect thermal insulation from the environment. We shall take these walls as the boundary of our system. The building is divided into a large number of rooms, the walls between them being good, but not perfect, insulators. The walls between rooms are the boundaries of our major subsystems. Each room is divided by partitions into a number of cubicles, but the partitions are poor insulators.

A thermometer hangs in each cubicle. Suppose that at the time of our first observation of the system there is a wide variation in temperature from cubible to cubicle and from room to room – the various cubicles within the building are in a state of thermal disequilibrium. When we take new temperature readings several hours later, waht shall we find? There will be very little variation in temperature among the cubicles within each single room, but there may still be large temperature variations among rooms. When we take readings again several days later, we find an almost uniform temperature throughout the building; the temperature differences among rooms have virtually disappeared.

Es decir, a  corto plazo, se podría entender el comportamiento de un subsistema de manera individual; sin embargo, a largo plazo, necesitaríamos incluir en la ecuación el resto de componentes de manera agregada para tener en cuenta los efectos de esas interacciones.

La descripción de la complejidad

El hecho de que muchos sistemas complejos tengan una estructura jerárquica casi-descomponible, facilita nuestra comprensión de ellos. O quizás nuestra comprensión de otro tipo de sistemas está limitada por nuestra capacidad de procesamiento. En cualquier caso, según Simon, cualquier actividad humana que suponga problem-solving se puede asimilar a un sistema de este tipo: el progreso hasta llegar al objetivo se produciría por un proceso de prueba/error selectivo; nos apoyaríamos en resultados intermedios que tendrían la misma función que los subsistemas biológicos (estabilizar la estructura) y nos señalizarían el camino hacia el objetivo.

¿Cómo, pues, podemos usar en nuestro beneficio las jerarquías para entender y construir sistemas complejos?

  • La jerarquía es, al fin y al cabo, una manera de encapsular la redundancia del sistema y hacerlo más económico en términos de esfuerzo.
  • Aunque no conocemos reglas generales que describan cómo encapsular esa redundancia para cualquier sistema, tenemos a nuestra disposición dos tipos de representaciones útiles: describir su estado y describir el proceso.

Usando la descripción de estado, podríamos definir un círculo como “el lugar de los puntos equidistantes de un punto dado“. La definición del proceso podría ser algo como “pinchar el compás en un punto del plano y rotar el otro brazo hasta que dé una vuelta completa“.

Coda

La arquitectura de la complejidad, de Herbert A. Simon aborda una tarea difícil y consigue reducirla a algo manejable: propone que el estudio de sistemas complejos es fundamentalmente el estudio de su jerarquía, encontrar la redundancia que nos permita representar su estructura de manera comprensible, para lo que tenemos a nuestra disposición dos herramientas fundamentales, estado y proceso.

Una teoría de sistemas aplicable a multitud de entornos (biología, sociales, etc) es necesariamente generalista. Como programador, sin embargo, hay lecciones en este paper que se pueden extrapolar a nuestro día a día.

code-hierarchy

La teoría de la casi-descomponibilidad es atractiva. Explica, por ejemplo, por qué los tests unitarios en subsistemas son posibles pero no suficientes para modelar el comportamiento del sistema. Explica también que para una mayor eficiencia en nuestro trabajo deberíamos enfocarnos en la búsqueda de submódulos estables. No menos importante: apunta que para agregar código en componentes (funciones, clases, módulos, etc) deberíamos primar agregaciones con gran interacción interna pero con interacción externa baja – es decir, loose coupling y high cohesion.

Por otro lado, alguna vez he bromeado con que el título que mejor me representa es el de físico-químico de sistemas de control interactivos. Tras la boutade se esconde una pequeña píldora de verdad: en el fondo, el día a día de todo programador consiste en eliminar la redundancia de un sistema. Me paso el día codificando esa redundancia con 2 herramientas principales: estado y proceso, datos y algoritmos.

Xerox Star

El Xerox Star fue el primer ordenador moderno que salió a mercado. Lanzado en 1981, definió una nueva relación con los ordenadores que prevalece todavía hoy en los sistemas que usamos a diario.

El contexto

En los 70, las computadoras estaban reservadas a entornos militares y universitarios, tenían el tamaño de una habitación y eran sistemas de tiempo compartido: un ordenador central al que se conectaban “terminales tontos”. Las interfaces eran orientadas a texto.

A mediados de la década, el signo de los tiempos apuntaba ya en otra dirección: la de las computadoras personales. Xerox, que era una de las mayores compañías tecnológicas del mundo gracias al negocio de copiadoras, no era ajena a ese ambiente y su visión era que los ordenadores podrían automatizar la oficina: fundamentalmente ayudando en la creación de informes y documentos – que se podrían imprimir con sus copiadoras, claro. Su visión -y la de muchos otros- era que el negocio estaba en el WordProcessing no en el DataProcessing.

Rank_Xerox_8010+40_brochure_front

Los anuncios del  Xerox 8010 InformationSystem –como era conocido el Star en el mercado- captan muy bien esa atmósfera. El que vemos a continuación es uno de los primeros que le muestran al público un ordenador con ventanas, iconos y otro tipo de metáforas referidas al escritorio (carpetas, archivadores, impresoras, etc):

Xerox PARC

En Xerox PARC, el centro neurálgico de Xerox, se reunía la gente que había estudiado y trabajado con los pioneros de la generación anterior (Douglas Englebart e Ivan Sutherland) para investigar y aterrizar qué podía significar eso de la automatización de la oficina. Un caldo de cultivo que favoreció multitud de invenciones: desde la impresión por láser, hasta el estándar de comunicaciones Ethernet, incluyendo la interfaz gráfica de usuario y el primer lenguaje de programación orientado a objetos, SmallTalk. Incluso habían construido un prototipo de “ordenador personal“: el Xerox Alto, bajo el tutelaje del Learning Research Center liderado por Alan Kay y que pretendía concretar las ideas en torno al Reactive Engine o el Dynabook.

Merece la pena recordar todo el background, ideas y trabajo previo que recoge el Star con un gráfico realizado por los propios diseñadores para la retrospectiva del producto que publicaron en 1989.

star_influences

Se puede ver en este gráfico también las influencias sobre los productos posteriores, que no son exclusivamente de ideas, sino que vienen muchas veces derivadas de personas que cambian de equipos: Larry Tesler que se va a Apple para trabajar en el diseño del Lisa, donde también estuvo Tom Malloy creando el LisaWrite, Simonyi a Microsoft para crear el Word continuando así el trabajo que él mismo había hecho con Lampson en la aplicación Bravo, el primer editor WYSIWYG y un largo etc.

El Xerox 8010 Information System

Para llevar a mercado esas invenciones, los directivos de Xerox decidieron crear el SDD (Systems Development Department), una división interdepartamental que contaba con 2 centros situados en California: Palo Alto y El Segundo. Dirigidos por David Liddle, el SDD inició su tarea en el verano de 1978 y tres años después, en 1981, el Star se presentó al público.

Esta división, además de nutrirse de muchos ingenieros de PARC, también contrató gente externa como Bill Verplank, un consultor de lo que entonces se conocía como Human Factors. Liddle describe el proceso de trabajo como:

It began with task analysis, looking at a fairly wide range is users. Next came the job of developing scenarios for uses of the imagined product based on the task. Then, it proposed a model for a graphical user interface, carefully distinguishing three aspects: the display of information, the control or command mechanisms and the user’s conceptual model.

Es decir, trabajaron con conceptos como análisis orientado a la tarea, design personas, prototipos como herramienta de selección de conceptos, etc.

El resultado fue un ordenador que costaba, consumía y pesaba un tercio menos que cualquier otro de la época:

El diseño de interacción

Una de las cosas verdaderamente únicas del Star fue proponer el escritorio como metáfora central para organizar los elementos y sus interacciones. Sorprende descubrir hasta qué punto se adhiere a esa metáfora. Vale la pena revisar videos y capturas de pantalla para descubrir pequeñas joyitas y grandes ideas que, en cierta medida, muchos sistemas operativos modernos están tratando de recuperar.

Algunas cosas que me han parecido curiosas del sistema y que son todavía hoy novedosas:

— Objetos y propiedades, no menús

El sistema es una verdadera interfaz orientada a objetos: cada elemento es un objeto y, por lo tanto tiene ciertas propiedades. Los objetos de texto (carácter, párrafo, etc) tienen propiedades de alineación, tipográficas, etc; los gráficos tienen como propiedades los datos que representan, visualización, colores, etc.

Por ejemplo, al abrir el editor de documento no hay menú, es una hoja en blanco. Se empieza a escribir y, para poner algo en cursiva no seleccionamos una herramienta de un menú una sino que se selecciona lo que se quiere modificar y se abre su panel de propiedades. De alguna manera, la no existencia de menús refleja la no existencia de estado o variables globales en la aplicación. Una interfaz orientada a objetos pura.

text_property_sheet

— Comandos generales

No tener un menú tiene limitaciones, ya que hay ciertas acciones que son entre objetos: buscar, copiar, mover, etc. La manera en que resolvieron esto fue creando comandos generales que tenían sus propias teclas en el teclado del Star.

Estos comandos son usados ampliamente en el sistema y mantienen su coherencia a lo largo de los diferentes contextos: mover, por ejemplo, puede significar tomar una frase de un párrafo y llevarla a otro; pero también significa lanzar una impresión si se mueve un documento al icono de la impresora.

— Orientación a la tarea: no se abren aplicaciones, sino documentos

El Star no tenía iconos para aplicaciones, esto fue algo que se introdujo en sistemas posteriores. Por otro lado, como dije anteriormente, funciones como la impresión o el envío de un mail se tratan como cualquier otro elemento: existe la impresora y la bandeja de salida de mail como objetos independientes; para imprimir se copia el documento sobre el objeto impresora; para enviar un mail se copia el documento sobre el objeto bandeja de entrada. La diferencia es sutil y separa la metáfora del escritorio (donde sólo hay documentos) de la metáfora del banco de trabajo (donde hay herramientas que aplicamos sobre un elemento).

Así lo definieron los propios diseñadores del Star en 1989:

«Having windows and a mouse does not make a system an embodiment of the Desktop metaphor. In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs. They do not “invoke a text editor”, they “open a document”. The system knows the type of each file and notifies the relevant application program when one is opened.

Most systems, even many windowed ones, use a Tools metaphor, in which users deal mainly with applications as tools: users start one or more application programs (e.g., word processor, spreadsheet), then specify one or more data files to edit with each. Such systems do not explicitly associate applications with data files; the burden of doing that — and of making sure not to try to edit a spreadsheet file with the text editor or vice-versa — is on users. Different kinds of files are distinguished by user-convention, usually via filename extensions (e.g., memo.txt). Star relieves users of the need to keep track of which data file goes with which application.

SunView is an example of a window system that is based upon the Tools metaphor rather than the Desktop metaphor. Its users see a collection of application program windows, each of which is used to edit certain files. Smalltalk-80, Cedar, and various Lisp environments also use the Tools metaphor rather than the Desktop metaphor.

This is not to say that the Desktop metaphor is superior to the Tools metaphor. The Desktop metaphor was intended for office automation and publishing. It may not be appropriate for other applications (e.g., software development). However, it can be argued that orienting users toward their data rather than toward application programs and employing analogies with the physical world are useful techniques in any domain

— Y mucho más

Para una revisión de las interfaces del Star es necesario desaprender lo que uno sabe de las interfaces actuales. Conceptos como el WYSIWYG fueron usados en un sistema comercial por primera vez aquí, también el uso de teclados virtuales para la introducción de fórmulas o la escritura en múltiples idiomas (incluyendo los RTL). Podríamos hablar también de cómo el Star usaba técnicas como el progresive disclosure, direct manipulation, etc.

Es muy recomendable revisitar los videos del producto y abrir bien los ojos y la mente.

¿Por qué no tuvo éxito el Star?

Sin embargo, a pesar de lo maravilloso del producto, el Star no fue un éxito comercial, como sí lo fueron sus inmediatos competidores que copiaron sus ideas. ¿Qué falló?

Jobs argumenta que Xerox sufrió lo que otras compañías con un cuasi-monopolio: la gente que influye en el futuro de la compañía era gente que veían de las posiciones de ventas y márketing, no los de producto. Debido al cuasi-monopolio, el common wisdom de la compañía es que lo que la hace más exitosa no es crear una nueva copiadora, sino aumentar el mercado mediante márketing y ventas. De esa manera, progresivamente la gente de producto queda relegada de los puestos de decisión hasta que, las compañías, en cierta manera, olvidan cómo se hacen buenos productos.

Complementariamente a lo que dice Jobs hay otras razones de peso para el fracaso, algunas de las cuales eran ya claras en 1989 para el equipo de diseñadores del Star:

  • Prestar atención a las tendencias de la industria y reducir los tiempos de salida del producto.

«At the time they were developed, these technologies were unique in the industry. Xerox elected to keep them proprietary for fear of losing its competitive advantage. With hindsight, we can say that it might have been better to release these technologies into the public domain or to market them early, so that they might have become industry standards. Instead, alternative approaches developed at other companies have become the industry standards.»

  • Prestar atención al mercado: el hecho de haber sido una plataforma cerrada les impidió ser beneficiarios de la innovación que estaban realizando otros.

«The personal computer revolution has shown that it is futile to try to anticipate all of the applications that customers will want. Star should have been designed to be open and extensible by users from the start, as the Alto was. In hindsight, extensibility was one of the keys to the Alto’s popularity. The problem wasn’t that Star lacked functionality, it was that it didn’t have the functionality customers wanted. An example is the initial lack of a spreadsheet application. The designers failed to appreciate the significance of this application, which may have been more important even than word-processing in expanding the personal computer revolution beyond engineers and hobbyists into business. Eventually realizing that Star’s closedness was a problem, Xerox replaced it with ViewPoint, a more “open” system that allows users to pick and choose applications that they need, including a spreadsheet and IBM PC software. Apple Computer learned the same lesson with its Lisa computer, and similarly replaced it with a cheaper one having a more open software architecture: Macintosh.

  • Conocer el mercado al que te diriges.

«Star’s initial per-workstation price was near that of time-shared mini-computers, dedicated word-processors, and other shared computing facilities. Star was, however, competing for desktop space with micro-computer-based PCs.»

En definitiva, el fracaso de Xerox parece que tuvo más que ver con la desalineación con el mercado que con las bondades del producto. Sin embargo, hablar con la sabiduría que nos da la perspectiva histórica es ventajoso. Muy pocos podrían haber predicho que una aplicación con el VisiCalc, crearía el término Killer Application y convertiría un mercado para ingenieros amateurs en uno de computadores personales para profesionales del conocimiento, creando y dando el pistoletazo de salida a la carrera por el dominio del nuevo mercado.

William Morris para makers

William_Morris_age_53

«To give people pleasure in the things they must perforce USE, that is one great office of decoration; to give people pleasure in the things they must perforce MAKE, that is the other use of it.»
— William Morris, The lessert arts

Morris en el siglo XIX

William Morris vive entre 1834 y 1896, entre la primera revolución industrial y la segunda.  Es decir, un período donde los beneficios de la primera industrialización no eran visibles pero sí toda su dureza (horas interminables en trabajos alienantes, ciudades no preparadas para la masificación y que se convierten en cultivo para las epidemias, etc). Por entonces, el corazón de Inglaterra es el BlackCountry, donde se ambientan las novelas victorianas de Dickens. Las arterias, son las vías de tren, que estallan en la crisis a mediados de siglo.

Es por ello que la vida de William Morris puede leerse como un resumen de los debates y fuerzas que latían bajo el siglo XIX, una sociedad de incipiente capitalismo industrial y moral victoriana. A lo largo de su vida, trabajó dos ideas básicas: por un lado, una teoría del consumo fundamentada en dotar de sentido y belleza a los objetos de la vida cotidiana; por el otro, una teoría de la producción que se sustentase en la recuperación del placer en el trabajo.

Morris y el consumo

«I do not want art for a few, any more than education for a few , or freedom for a few.»

— William Morris, The lessert arts

A mediados de siglo, culminan los esfuerzos de Henry Cole por organizar la primera exposición internacional industrial y de comercio, «The great exhibition» en 1851, que fue todo un éxito: 14.000 expositores, 100.000 artículos en exposición, 6 millones de visitantes. Aunque la idea es francesa sólo un país con debates sobre libertad de comercio recientes como Inglaterra estaba preparada por entonces para llevarla a cabo. El mismo Cole, veía la exhibición como la muestra de que Inglaterra estaba preparada para el libre comercio y la primera globalización.

Pero para Cole la exposición era también un impulso a lo que él mismo había iniciado dos años antes con la publicación de la revista «Journal of design and manufacturers»: estimular el debate del diseño en la producción en serie. En este aspecto, la exhibición fue polémica. Muchos la consideraron un horror, la confirmación de que la deshumanización del trabajo que supuso la industrialización no podía producir cosas bellas. De fondo, lo que se estaba rumiando era un debate estético: ¿son las bellas artes (pintura, escultura, …) y las artes decorativas (orfebrería, cerámica, textiles, …) la misma cosa? ¿es posible que la producción en serie integre la belleza?

Owen Jones, uno de los pioneros del diseño, decía que la decoración de los objetos no era importante:

«Ornament must be secondary to the thing decorated, wallpapers and carpets must not have any patterns suggestive of anything but a level or plain.»

Era algo que se hacía a posteriori, una vez la pieza está acabada. El barniz.

Morris, sin embargo, consideraba que la búsqueda de la belleza trascendía el arte y las actividades artísticas (pintura, escultura, etc), que el diseño de los objetos importa. Esta declaración es lo que pone a Morris en el árbol genealógico del diseño industrial. Según él, el objeto en sí mismo porta contextos y la relación que tenemos con ellos debe tener significado. La felicidad no estaría en el número de objetos que poseemos, sino en la belleza y significado que tengan. Critica, además, cómo esa diferenciación entre bellas artes y artes decorativas favorece la creación de clases sociales: los artistas, que serían personas intelectuales, gentilhombres y profesionales; los artesanos, que serían mano de obra asalariada que cobran por semanas.

Se consolida así en Morris el deseo de producir objetos bellos, de calidad y duraderos que puedan ser asequibles para todos.

Morris y la producción

De formación arquitecto, la vida de Morris es en realidad la de un renacentista: diseñador de interiores, tipógrafo, poeta, traductor, escritor de novelas de ciencia ficción, pintor, fundador de la Sociedad por la Recuperación de edificios históricos, etc. Aunque quizás por lo que hoy en día más se le conoce es por haber sido uno de los fundadores del movimiento Arts&Crafts. Y todo empezó con una casa.

Con motivo de su boda, consigue reunir a sus amigos para construir una nueva vivienda familiar como regalo a su esposa, la Red House.Philip_Webb's_Red_House_in_Upton

Al acabarla, unidos por el sentimiento cooperativo y el juego que ha supuesto esa creación inician una empresa conjunta de diseño de interiores que todavía hoy existe, y que se consolida en los siguientes años como la Morris&Co. Es en esta compañía en la que Morris puede aplicar las ideas renacentistas del trabajo desarrollando una teoría organizativa que bebe de los gremios medievales:

  • orgullo por el trabajo bien hecho
  • una relación maestro/aprendiz en las relaciones internas
  • productos de calidad, duraderos y con sentido hacia el mercado

Aunque Morris no era un ludita, consideraba aberrantes las condiciones de trabajo industriales que ponían al hombre al servicio de la máquina, desconectaban al artesano de su relación con los objetos y desposeían de placer al trabajo mismo. Tampoco era ajeno a que la industrialización suponía que el capitalista era el que tenía la relación con el mercado, no el trabajador/artesano.

Es decir, la lectura que hace Morris de la industrialización es que supone una pérdida de independencia que la clase media había ganado en el medioevo.

Morris como activista y filósofo

Morris se define a sí mismo como un socialista constructivo, que ofrece esperanza frente al socialismo destructivo que piensa que la situación actual es insoportable y horrible y la manera de superarla es conmover la sociedad a golpes hasta que se tambalee y caiga. Su objetivo es la búsqueda de la abundancia para todos:

El progreso y victoria sobre la naturaleza para generar riqueza es clara en nuestra época. Todos deberíamos ser ricos. Sin embargo existe un gran masa social explotada que no puede acceder a los bienes más básicos y muchos otros que no pueden perseguir sus disfrutes y deseos para los que la civilización es mezquina y torturadora. Los frutos del progreso nos han sido robados, impidiendo el disfrute de las tres esperanzas.

A nivel político, plantea una visión muy moderna que desarrolla principalmente en «Cómo vivimos y cómo podríamos vivir»: la competencia comercial entre naciones lleva a la guerra, la colonización y al desaprovechamiento de recursos. Como alternativa, propone una aldea global con producción y distribución coordinada en calidad/cantidad, libre comercio y movilidad de personas y el renacimiento social basado en el empoderamiento e independencia de la clase media.

A nivel individual, considera que existen 3 facetas principales que nos harán personas plenas:

  • Esperanza del descanso, o de reposar lo suficiente: seremos mejor que las bestias.
  • Esperanza de obtener un buen resultado y disfrutar de lo realizado: seremos mejor que las máquinas.
  • Esperanza por tener placer en el propio trabajo: seremos hombres.

Su programa político podría definirse como la subordinación del trabajo y capital a las necesidades de la comunidad a la que sirve. No producir objetos inútiles o sin sentido, no crear tareas vacías o no gratas.

Morris en los albores del mundo maker

Hay varias lecciones que podemos aprender de la historia de Morris:

  • la clase media como esperanza: si el cambio productivo significa algo es ganar la capacidad de vender productos diseñados por nosotros mismos en un mercado global. Es decir: apostar por la globalización de los pequeños. El enfoque es recuperar la autonomía que se perdió en la industrialización.
  • el diseño en el centro: fue medio siglo después de que Morris apostase por el diseño en los objetos cotidianos, que las modernas escuelas de diseño rusa (Vkutemas) y alemana (Bauhaus) consiguieron imponer su legado. Hoy, como entonces, el diseño es el centro de la producción.
  • productos, no artesanía: si bien el movimiento Arts&Crafts acertó el diagnóstico (integrar el arte en la producción de objetos cotidianos), erró en la receta (quedar al margen de la industrialización y la producción en masa). Fueron empresarios como Thonet, con 50 millones de sillas vendidas entre 1859 y 1930, los que llevaron su arte a las clases populares, siendo la gran tragedia de Morris (y una de las razones por las que abandonó la empresa) que su base de cliente fuesen las clases adineradas. Aunque no eran luditas, sí tardaron en crear un discurso favorable al uso de tecnología e introducirlas en su trabajo, y eso impidió que sus ideas de organización del trabajo y la sociedad tuviesen mayor recorrido.

El mundo de Morris tiene muchas similitudes con el nuestro. Vivimos, al igual que él, en un futuro muy steampunk.

Diseño de interación, según Bill Verplank

Billverplank_ciid_2010He estado revisando recientemente el trabajo de Bill Verplank. De su perfil me llamaron la atención 3 momentos en particular: participa en el desarrollo del Xerox Star, trabaja con Bill Modridge en IDTwo (luego IDEO) donde acuñan el término Interaction Design y funda con Terry Winograd el programa de HCI en Standford.

Desafortunadamente, no he podido encontrar mucha información suya online. Apenas un video donde explica la tarea a la que se enfrenta el diseñador de interación (donde, entre otras cosas, cita la diferencia entre mapa y ruta):

Tenemos también un par de entrevistas y alguna keynote. Ésta última muy recomendable. Pero lo que parece ser su núcleo actual de pensamiento lo condensa en un librito no acabado sobre diseño de interacción. Es una lectura breve pero profunda. Diría que es un marco de pensamiento muy XEROX: consigue integrar las ideas respecto al aprendizaje del grupo de Alan Kay con la experiencia en HCI del grupo de David Liddle, asignándole importancia a cosas como el modelo conceptual en el que se embebe tu producto.

Verplank, en su afán por dibujar una visión holística del desarrollo de producto ha llegado a un interesante marco de pensamiento:

IxDesign_Matrix

 

A falta de procesarlo por completo, me fascina lo bien que encajan las piezas. Diría que es el puzzle que todo diseñador debe rellenar a lo largo de la evolución del producto.

Douglas Engelbart, the father of all demos

the_mother_of_all_demos

¿Qué somos, como programadores, sino diseñadores de la interacción máquina-humano? ¿Dónde nos hemos dejado las capacidades de inventar el futuro? Es lo que me evoca la visión de “The mother of all demos” que Bret Victor se encarga de rescatar en el epitafio a Douglas Engelbart.

Cuando la veáis, poned en perspectiva que Bill Gates y Steve Jobs -los líderes de la siguiente generación- tenían 13 años cuando Engelbart hizo esta demo; y apenas unos años atrás hemos empezado a disfrutar parcialmente de aplicaciones que el equipo de Doug había desarrollado en 1968 (colaboración en tiempo real sobre un documento, por ejemplo).

Categorizar a Doug Engelbart es difícil. Su rol fue el de un visionario. Quizás Alan Kay fue el que mejor lo describió: un Moisés que nos dirigía a la tierra prometida.

Más info:

 

Beck and Cunningham

Con Alan Kay inicié una serie de entradas sobre pioneros de la informática. Referentes de los que uno lee o descubre algo. Hoy continúo con Kent Beck y Ward Cunningham.

Kent y Ward crecieron con el SmallTalk de Ingalls y Kay. Me aventuro a pensar que su temprano contacto con este lenguaje pionero influyó en cómo se aproximaron después a la programación. De algún modo son sus discípulos y representan la segunda generación de ingenieros informáticos de la historia. Ambos han tenido un papel relevante en los principales temas de los 90 en el desarrollo de software: los patrones de diseño, la orientación a objetos y la emergencia de las metodologías agile en la gestión de proyectos.

Por todo ello, a pesar del pesimismo de Kay, yo creo que esta generación sí tomó su relevo:

«I think one of the things we liked the most about Smalltalk was not what it could do, but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building.»

— Alan Kay

La génesis de los patrones de diseño

La referencia al término patrones de diseño en programación más antigua se le atribuye a Ward y Kent, que la presentaron en OOPSLA 87: Using pattern languages for Object-Oriented programs. El concepto de patrón lo toman prestado del mundo de la arquitectura:

«Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.»

— ChristopherAlexander

Una vez planteado el problema en la OOPSLA, los siguientes años son frenéticos. Mucha gente trabaja en los patrones. Las siguientes conferencias tienen multitud de referencias a ellos. La idea flota en el ambiente. Uno tras otro van acumulando conocimiento, a hombros de gigantes. Su extensión fue meteórica, apenas 7 años después de que Beck y Cunnigham lanzasen el guante, la GoF (Gang of Four) tenía publicado su libro canónico. Estábamos en el peak del movimiento:

En paralelo a todo ello, Ward y Beck se convierten en una referencia en el mundo Smalltalk que inaugura la moderna orientación a objetos. Para aquellos que deseéis apenas catar lo que fueron esos años, ese maravilloso caldo de cultivo de las ideas, os recomiendo que leáis este artículo: History of patterns.

Coders at work: netscape y javascript

Estoy leyendo a ratos Coders at work, un libro de entrevistas a programadores inspirado en lo que hizo The Paris Review con su serie Writers at work, por la que pasaron Hemingway, Capote, Borges, …

He empezado por aquellas que más me sugerían, por ejemplo, la de Jamie Zawinski, uno de los líderes detrás de la liberación del código de Netscape y cofundador de la fundación Mozilla; seguida por la de Brendan Eich, también cofundador de Mozilla y creador de javascript. Me ha gustado descubrir no sólo su trayectoria personal, si no el ambiente que se respiraba en Netscape en aquella época. Totalmente imprescindible como complemento el documental Code Rush:

Al acabar la de Eich, he empezado con la de Douglas Crockford, creador de JSON y uno de los principales gurús del lenguaje. Mundialmene conocido por Javascript: the good parts y sus talleres de introducción a Javascript. El libro y la serie completa son una deliciosa joya para todos los que aspiren a saber algo del lenguaje. De entre todos los videos, por contexto, recomendaría ahora el primero, que versa sobre la historia del javascript (según sus propia interpretación):

Estoy disfrutando enormemente del libro. No sólo me sirve para conocer más ciertos aspectos de nuestra reciente historia (la de la informática y sus empresas) si no también para de algún modo entrar en el proceso creativo de grandes programadores, cómo se enfrentan ellos a la tarea de programar. Conocer, de cara a mejorar el mío propio.

Alan Kay: “the computer revolution hasn’t happened yet”

Alan Kay es uno de los pioneros de la informática. Uno de los fundadores de XEROX PARC, ha llevado el premio Turing por sus contribuciones al mundo del software con las ideas detrás de la orientación a objetos implementadas en Smalltalk y en la última década está muy enfocado en sistemas que permitan la enseñanza (y creación) siguiendo métodos constructivistas (como el OLPC).

Os recomiendo que leáis esta entrevista A conversation with Alan Kay, y que veáis el video de su charla en OOPSLA (1997): The computer revolution hasn’t happened yet (transcripción).

Habla en su charla sobre cómo las ideas evolucionan y qué podemos aprender de eso a la hora de construir software: habla de diseño y evolución, de cómo los principios de la biología fueron fuente de inspiración para la orientación a objetos o de cómo la idea de encapsulación es la idea principal de todo diseño de software. Es un buen orador.

Aunque Kay es una fuente inagotable de ideas. En la charla encontraréis cosas como:

  • la apología de vivir arrebatados por el cambio, favoreciendo el florecimiento de nuevas ideas:

«If you had to pick one cause, of both particular difficulty in our field, and also a general difficulty in the human race, it’s taking single points of view and committing to them like they’re religions. This happened with Smalltalk. There’s a wonderful quote by Schopenhauer, a German philosopher of the nineteenth century, who said, “Every idea goes through three stages. First, it is denounced as the work of madmen.” […] and then later, it’s remarked as being totally obvious the whole time, and then the last stage is when the original denouncers claim to have invented it. [Laughter] That’s when it gets in its religious stage. To me, the most distressing thing that happened to Smalltalk when it came out of Xerox PARC, was, for many respects and purposes it quit changing. I can tell you, at Xerox PARC there are four major versions—completely different versions of the language—over about a ten year period, and many dozens and dozens of significant releases within those different versions. I think one of the things we liked the most about Smalltalk was not what it could do, but the fact that it was such a good vehicle for bootstrapping the next set of ideas we had about how to do systems building. That, for all intents and purposes—when Smalltalk went commercial—ceased.»

  • de la orientación a objetos:

«Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. […] I would compare the Smalltalk stuff that we did in the ’70s with something like a Gothic cathedral. We had two ideas, really. One of them we got from Lisp: late binding. The other one was the idea of objects. Those gave us something a little bit like the arch, so we were able to make complex, seemingly large structures out of very little material, but I wouldn’t put us much past the engineering of 1,000 years ago.»

  • o de cómo él cree que muchas ideas en el desarrollo de software todavía no han llegado a su potencial:

«For a Scientific American article 20 years ago, I came up with a facetious sunspot theory, just noting that there’s a major language or two every 10/12 years, and in between those periods are what you might call hybrid languages. These could be looked at as either an improvement on the old thing or almost a new thing. I chronicled Fortran as an improvement on an old thing or almost a new thing, and Algol and Lisp were the new thing.

Then there was Simula, which the designers thought of as an extension of Algol. It was basically a preprocessor to Algol the way C++ was a preprocessor for C. It was a great concept and I was lucky enough to see it as almost a new thing. Smalltalk and Prolog happened in the early 1970s. The predecessor of Prolog was a wonderful thing that Carl Hewitt did in the late 1960s called Planner.

Perhaps it was commercialization in the 1980s that killed off the next expected new thing. Our plan and our hope was that the next generation of kids would come along and do something better than Smalltalk around 1984 or so. We all thought that the next level of programming language would be much more strategic and even policy-oriented and would have much more knowledge about what it was trying to do. But a variety of different things conspired together, and that next generation actually didn’t show up. One could actually argue—as I sometimes do—that the success of commercial personal computing and operating systems has actually led to a considerable retrogression in many, many respects.

You could think of it as putting a low-pass filter on some of the good ideas from the ’60s and ’70s, as computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare. What television was able to do was to capture people as they were.

So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture.»

Actualización 16:00

Actualización 02/05

  • Este fin de semana he estado leyendo y viendo más material de Alan Kay. No os perdáis este texto: The early story of smalltalk. No sólo es un repaso a la historia del lenguaje y la metáfora de la orientación a objetos, sino también una panorámica colateral de algunas de las leyendas fundacionales de la informática y los ordenadores tal y como los conocemos.