DISEÑO E INVESTIGACIÓN

January 2003

(Este artículo se deriva de una charla magistral en la reunión de otoño de 2002 de NEPLS.)

Los visitantes de este país a menudo se sorprenden al descubrir que a los estadounidenses les gusta comenzar una conversación preguntando "¿a qué te dedicas?". Nunca me ha gustado esta pregunta. Rara vez he tenido una respuesta precisa a ella. Pero creo que finalmente he resuelto el problema. Ahora, cuando alguien me pregunta a qué me dedico, lo miro directamente a los ojos y digo: "Estoy diseñando un nuevo dialecto de Lisp." Recomiendo esta respuesta a cualquiera que no le guste que le pregunten a qué se dedica. La conversación girará inmediatamente a otros temas.

No me considero un investigador de lenguajes de programación. Simplemente estoy diseñando uno, de la misma manera que alguien podría diseñar un edificio, una silla o una nueva tipografía. No estoy tratando de descubrir nada nuevo. Solo quiero hacer un lenguaje que sea bueno para programar. En cierto modo, esta suposición facilita mucho la vida.

La diferencia entre el diseño y la investigación parece ser una cuestión de nuevo frente a bueno. El diseño no tiene que ser nuevo, pero tiene que ser bueno. La investigación no tiene que ser buena, pero tiene que ser nueva. Creo que estos dos caminos convergen en la cima: el mejor diseño supera a sus predecesores al utilizar ideas nuevas, y la mejor investigación resuelve problemas que no solo son nuevos, sino que también realmente vale la pena resolver. Así que en última instancia estamos apuntando al mismo destino, solo que nos acercamos a él desde direcciones diferentes.

De lo que voy a hablar hoy es de cómo se ve tu objetivo desde atrás. ¿Qué haces diferente cuando tratas los lenguajes de programación como un problema de diseño en lugar de un tema de investigación?

La mayor diferencia es que te centras más en el usuario. El diseño comienza preguntando, ¿para quién es esto y qué necesitan de él? Un buen arquitecto, por ejemplo, no comienza creando un diseño que luego imponga a los usuarios, sino estudiando a los usuarios finales y descubriendo qué necesitan.

Fíjate que dije "lo que necesitan", no "lo que quieren". No quiero dar la impresión de que trabajar como diseñador significa trabajar como una especie de cocinero de comida rápida, haciendo lo que el cliente te dice que hagas. Esto varía de un campo a otro en las artes, pero no creo que haya ningún campo en el que el mejor trabajo lo hagan las personas que simplemente hacen exactamente lo que los clientes les dicen.

El cliente sí es siempre el que tiene la razón en el sentido de que la medida de un buen diseño es cuán bien funciona para el usuario. Si haces una novela que aburre a todos, o una silla que es terriblemente incómoda para sentarse, entonces has hecho un mal trabajo, punto. No es una defensa decir que la novela o la silla están diseñadas de acuerdo con los principios teóricos más avanzados.

Y aún así, hacer lo que funciona para el usuario no significa simplemente hacer lo que el usuario te dice que hagas. Los usuarios no saben cuáles son todas las opciones y a menudo se equivocan sobre lo que realmente quieren.

La respuesta a la paradoja, creo, es que tienes que diseñar para el usuario, pero tienes que diseñar lo que el usuario necesita, no simplemente lo que dice que quiere. Es como ser médico. No puedes simplemente tratar los síntomas de un paciente. Cuando un paciente te dice sus síntomas, tienes que averiguar qué es lo que realmente le pasa y tratarlo.

Este enfoque en el usuario es una especie de axioma del que se derivan la mayor parte de las prácticas de buen diseño, y en torno al cual se centran la mayoría de los problemas de diseño.

Si el buen diseño debe hacer lo que el usuario necesita, ¿quién es el usuario? Cuando digo que el diseño debe ser para los usuarios, no quiero dar a entender que el buen diseño apunte a una especie de denominador común más bajo. Puedes elegir cualquier grupo de usuarios que quieras. Si estás diseñando una herramienta, por ejemplo, puedes diseñarla para cualquiera, desde principiantes hasta expertos, y lo que es un buen diseño para un grupo puede ser malo para otro. El punto es que tienes que elegir algún grupo de usuarios. No creo que puedas ni siquiera hablar de buen o mal diseño, excepto con referencia a algún usuario previsto.

Es más probable que obtengas un buen diseño si los usuarios previstos incluyen al propio diseñador. Cuando diseñes algo para un grupo que no te incluye a ti, tiende a ser para personas que consideras menos sofisticadas que tú, no más sofisticadas.

Eso es un problema, porque mirar por encima del hombro al usuario, por muy benévola que sea la intención, parece corromper inevitablemente al diseñador. Sospecho que muy pocos proyectos de vivienda en los EE. UU. fueron diseñados por arquitectos que esperaban vivir en ellos. Puedes ver lo mismo en los lenguajes de programación. C, Lisp y Smalltalk fueron creados para que los usaran sus propios diseñadores. Cobol, Ada y Java fueron creados para que otras personas los usaran.

Si crees que estás diseñando algo para idiotas, las probabilidades son que no estás diseñando algo bueno, ni siquiera para idiotas.

Incluso si estás diseñando algo para los usuarios más sofisticados, sin embargo, todavía estás diseñando para humanos. Es diferente en la investigación. En matemáticas, no eliges abstracciones porque son fáciles de entender para los humanos; eliges las que hacen que la prueba sea más corta. Creo que esto es cierto para las ciencias en general. Las ideas científicas no están hechas para ser ergonómicas.

En las artes, las cosas son muy diferentes. El diseño es todo sobre las personas. El cuerpo humano es una cosa extraña, pero cuando estás diseñando una silla, es para lo que estás diseñando, y no hay forma de evitarlo. Todas las artes tienen que complacer los intereses y las limitaciones de los humanos. En la pintura, por ejemplo, siendo todas las cosas iguales, una pintura con gente en ella será más interesante que una sin gente. No es un simple accidente de la historia que las grandes pinturas del Renacimiento estén llenas de gente. Si no hubieran sido así, la pintura como medio no tendría el prestigio que tiene.

Te guste o no, los lenguajes de programación también son para personas, y sospecho que el cerebro humano es tan abultado e idiosincrásico como el cuerpo humano. Algunas ideas son fáciles de comprender para las personas y otras no. Por ejemplo, parece que tenemos una capacidad muy limitada para lidiar con los detalles. Es este hecho lo que hace que los lenguajes de programación sean una buena idea en primer lugar; si pudiéramos manejar los detalles, podríamos programar directamente en lenguaje de máquina.

Recuerda también que los lenguajes no son principalmente una forma para programas terminados, sino algo en lo que los programas tienen que desarrollarse. Cualquiera en las artes podría decirte que es posible que desees medios diferentes para las dos situaciones. El mármol, por ejemplo, es un medio agradable y duradero para las ideas terminadas, pero un medio desesperadamente inflexible para desarrollar nuevas ideas.

Un programa, como una prueba, es una versión podada de un árbol que en el pasado ha tenido falsos comienzos ramificándose por todos lados. Así que la prueba de un lenguaje no es simplemente cuán limpio se ve el programa terminado en él, sino cuán limpio fue el camino hacia el programa terminado. Una opción de diseño que te da programas terminados elegantes puede no darte un proceso de diseño elegante. Por ejemplo, he escrito algunas macros de definición de macros llenas de corchetes de cierre anidados que ahora parecen pequeñas gemas, pero escribirlas llevó horas del ensayo y error más feo, y francamente, todavía no estoy del todo seguro de que sean correctas.

A menudo actuamos como si la prueba de un lenguaje fuera cuán buenos se ven los programas terminados en él. Parece tan convincente cuando ves el mismo programa escrito en dos lenguajes, y una versión es mucho más corta. Cuando te acercas al problema desde la dirección de las artes, es menos probable que dependas de este tipo de prueba. No quieres acabar con un lenguaje de programación como el mármol.

Por ejemplo, es una gran victoria en el desarrollo de software para tener un nivel superior interactivo, lo que en Lisp se llama un bucle de lectura-evaluación-impresión. Y cuando tienes uno, esto tiene efectos reales en el diseño del lenguaje. No funcionaría bien para un lenguaje donde tienes que declarar las variables antes de usarlas, por ejemplo. Cuando estás simplemente escribiendo expresiones en el nivel superior, quieres poder establecer x en algún valor y luego empezar a hacer cosas con x. No quieres tener que declarar el tipo de x primero. Puede que disputes cualquiera de las premisas, pero si un lenguaje tiene que tener un nivel superior para ser conveniente, y las declaraciones de tipo obligatorias son incompatibles con un nivel superior, entonces ningún lenguaje que haga que las declaraciones de tipo sean obligatorias podría ser conveniente para programar en él.

En la práctica, para obtener un buen diseño tienes que acercarte, y mantenerte cerca, de tus usuarios. Tienes que calibrar tus ideas sobre usuarios reales constantemente, especialmente al principio. Una de las razones por las que las novelas de Jane Austen son tan buenas es que las leyó en voz alta a su familia. Es por eso que nunca se hunde en autocomplacientes y artísticas descripciones de paisajes, o filosofías pretenciosas. (La filosofía está ahí, pero está entretejida en la historia en lugar de pegarse como una etiqueta.) Si abres una novela "literaria" promedio e imaginas leerla en voz alta a tus amigos como algo que tú mismo has escrito, sentirás con demasiada viveza qué imposición es ese tipo de cosas para el lector.

En el mundo del software, esta idea se conoce como Worse is Better. En realidad, hay varias ideas mezcladas en el concepto de Worse is Better, razón por la cual la gente todavía está discutiendo sobre si Worse es realmente mejor o no. Pero una de las ideas principales en esa mezcla es que si estás construyendo algo nuevo, deberías conseguir un prototipo frente a los usuarios lo antes posible.

El enfoque alternativo podría llamarse la estrategia Hail Mary. En lugar de sacar un prototipo rápidamente y refinarlo gradualmente, intentas crear el producto completo, terminado, en una sola pasada de touchdown. Que yo sepa, esta es una receta para el desastre. Innumerables empresas emergentes se destruyeron a sí mismas de esta manera durante la burbuja de Internet. Nunca he oído hablar de un caso en el que haya funcionado.

Lo que la gente fuera del mundo del software puede que no se dé cuenta es que Worse is Better se encuentra en todas las artes. En el dibujo, por ejemplo, la idea se descubrió durante el Renacimiento. Ahora casi todos los profesores de dibujo te dirán que la forma correcta de obtener un dibujo preciso no es trabajar lentamente alrededor del contorno de un objeto, porque los errores se acumularán y encontrarás al final que las líneas no se juntan. En cambio, debes dibujar unas pocas líneas rápidas en el lugar aproximado, y luego refinar gradualmente este boceto inicial.

En la mayoría de los campos, los prototipos tradicionalmente se han hecho con diferentes materiales. Las tipografías que se iban a cortar en metal se diseñaron inicialmente con un pincel sobre papel. Las estatuas que se iban a fundir en bronce se moldeaban en cera. Los patrones que se iban a bordar en tapices se dibujaban en papel con tinta china. Los edificios que se iban a construir con piedra se probaban a menor escala en madera.

Lo que hizo que la pintura al óleo fuera tan emocionante, cuando comenzó a ser popular en el siglo XV, fue que se podía hacer realmente la obra terminada a partir del prototipo. Podías hacer un dibujo preliminar si querías, pero no estabas atado a él; podías trabajar todos los detalles, e incluso hacer cambios importantes, a medida que terminabas la pintura.

También puedes hacer esto en software. Un prototipo no tiene que ser solo un modelo; puedes refinarlo hasta convertirlo en el producto final. Creo que siempre deberías hacer esto cuando puedas. Te permite aprovechar las nuevas ideas que tienes a lo largo del camino. Pero quizás aún más importante, es bueno para la moral.

La moral es clave en el diseño. Me sorprende que la gente no hable más de ello. Uno de mis primeros profesores de dibujo me dijo: si te aburres cuando estás dibujando algo, el dibujo se verá aburrido. Por ejemplo, supongamos que tienes que dibujar un edificio y decides dibujar cada ladrillo individualmente. Puedes hacer esto si quieres, pero si te aburres a mitad de camino y empiezas a hacer los ladrillos mecánicamente en lugar de observar cada uno, el dibujo se verá peor que si simplemente hubieras sugerido los ladrillos.

Construir algo refinando gradualmente un prototipo es bueno para la moral porque te mantiene comprometido. En software, mi regla es: siempre tener código que funcione. Si estás escribiendo algo que podrás probar en una hora, entonces tienes la perspectiva de una recompensa inmediata para motivarte. Lo mismo ocurre en las artes, y especialmente en la pintura al óleo. La mayoría de los pintores comienzan con un boceto borroso y gradualmente lo refinan. Si trabajas de esta manera, entonces en principio nunca tienes que terminar el día con algo que realmente se vea inacabado. De hecho, incluso hay un dicho entre los pintores: "Una pintura nunca está terminada, simplemente dejas de trabajar en ella". Esta idea le resultará familiar a cualquiera que haya trabajado en software.

La moral es otra razón por la que es difícil diseñar algo para un usuario poco sofisticado. Es difícil mantenerse interesado en algo que a ti mismo no te gusta. Para hacer algo bueno, tienes que estar pensando: "guau, esto es realmente genial", no "qué mierda; esos tontos les encantará".

Diseñar significa hacer cosas para humanos. Pero no solo el usuario es humano. El diseñador también es humano.

Fíjate que todo este tiempo he estado hablando del "diseñador". El diseño generalmente tiene que estar bajo el control de una sola persona para que sea bueno. Y, sin embargo, parece que es posible que varias personas colaboren en un proyecto de investigación. Esto me parece una de las diferencias más interesantes entre la investigación y el diseño.

Ha habido casos famosos de colaboración en las artes, pero la mayoría parecen haber sido casos de unión molecular más que de fusión nuclear. En una ópera es común que una persona escriba el libreto y otra la música. Y durante el Renacimiento, los aprendices del norte de Europa a menudo se empleaban para hacer los paisajes en el fondo de las pinturas italianas. Pero estas no son verdaderas colaboraciones. Se parecen más a ejemplos de las "buenas cercas hacen buenos vecinos" de Robert Frost. Puedes pegar instancias de buen diseño juntas, pero dentro de cada proyecto individual, una persona tiene que estar al mando.

No estoy diciendo que el buen diseño requiera que una sola persona piense en todo. No hay nada más valioso que el consejo de alguien en cuyo juicio confías. Pero una vez que se termina de hablar, la decisión sobre qué hacer tiene que recaer en una sola persona.

¿Por qué la investigación se puede hacer entre colaboradores y el diseño no? Esta es una pregunta interesante. No sé la respuesta. Tal vez, si el diseño y la investigación convergen, la mejor investigación es también un buen diseño, y de hecho no se puede hacer entre colaboradores. Muchos de los científicos más famosos parecen haber trabajado solos. Pero no sé lo suficiente para decir si hay un patrón aquí. Podría ser simplemente que muchos científicos famosos trabajaron en una época en la que la colaboración era menos común.

Cualquiera que sea la historia en las ciencias, la verdadera colaboración parece ser extraordinariamente rara en las artes. El diseño por comité es un sinónimo de mal diseño. ¿Por qué es eso? ¿Hay alguna forma de superar esta limitación?

Estoy inclinado a pensar que no la hay, que el buen diseño requiere un dictador. Una razón es que el buen diseño tiene que ser una sola pieza. El diseño no es solo para humanos, sino para humanos individuales. Si un diseño representa una idea que encaja en la cabeza de una persona, entonces la idea encajará también en la cabeza del usuario.