DISEÑO E INVESTIGACIÓN

enero de 2003

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

Los visitantes de este país a menudo se sorprenden al descubrir que los estadounidenses suelen comenzar una conversación preguntando "¿a qué te dedicas?" Nunca me ha gustado esta pregunta. Rara vez he tenido una respuesta clara para ella. Pero creo que finalmente he resuelto el problema. Ahora, cuando alguien me pregunta qué hago, 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 qué hace. La conversación se desviará inmediatamente a otros temas.

No me considero que esté investigando sobre lenguajes de programación. Solo 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 algunos aspectos, esta suposición hace que la vida sea mucho más fácil.

La diferencia entre diseño e investigación parece ser una cuestión de nuevo versus 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 nuevas ideas, y la mejor investigación resuelve problemas que no solo son nuevos, sino que realmente valen la pena resolver. Así que, en última instancia, estamos apuntando al mismo destino, solo que nos acercamos desde diferentes direcciones.

De lo que voy a hablar hoy es de cómo se ve tu objetivo desde atrás. ¿Qué haces de manera 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 enfocas más en el usuario. El diseño comienza preguntando, ¿para quién es esto y qué necesita de ello? Un buen arquitecto, por ejemplo, no comienza creando un diseño que luego impone a los usuarios, sino estudiando a los usuarios previstos y averiguando qué necesitan.

Nota 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 pedidos rápidos, haciendo lo que el cliente te dice. 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 sea realizado por las personas que simplemente hacen exactamente lo que los clientes les dicen.

El cliente siempre tiene 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 horriblemente incómoda para sentarse, entonces has hecho un mal trabajo, punto. No es defensa decir que la novela o la silla está diseñada de acuerdo con los principios teóricos más avanzados.

Y aun así, hacer lo que funciona para el usuario no significa simplemente hacer lo que el usuario te dice. 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 muy parecido a ser un 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 tratar eso.

Este enfoque en el usuario es una especie de axioma del cual se puede derivar la mayor parte de la práctica del buen diseño, y alrededor del 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 implicar que el buen diseño apunte a algún tipo de denominador común más bajo. Puedes elegir cualquier grupo de usuarios que desees. 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 podría ser malo para otro. El punto es que tienes que elegir algún grupo de usuarios. No creo que puedas hablar de buen o mal diseño excepto en 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ñas algo para un grupo que no te incluye, tiende a ser para personas que consideras menos sofisticadas que tú, no más sofisticadas.

Ese es un problema, porque mirar por encima del hombro al usuario, por benevolente que sea, parece inevitablemente corromper 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 sus propios diseñadores los usaran. Cobol, Ada y Java fueron creados para que otras personas los usaran.

Si piensas que estás diseñando algo para idiotas, lo más probable es que no estés diseñando algo bueno, incluso 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 sean fáciles de entender para los humanos; eliges las que hacen la prueba más corta. Creo que esto es cierto para las ciencias en general. Las ideas científicas no están destinadas a ser ergonómicas.

En las artes, las cosas son muy diferentes. El diseño se trata de personas. El cuerpo humano es una cosa extraña, pero cuando estás diseñando una silla, eso es lo que estás diseñando, y no hay forma de evitarlo. Todas las artes tienen que satisfacer los intereses y limitaciones de los humanos. En la pintura, por ejemplo, todas las cosas siendo iguales, una pintura con personas en ella será más interesante que una sin. No es meramente un accidente de la historia que las grandes pinturas del Renacimiento estén llenas de personas. Si no lo hubieran estado, 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 irregular e idiosincrático como el cuerpo humano. Algunas ideas son fáciles de entender para las personas y otras no. Por ejemplo, parece que tenemos una capacidad muy limitada para lidiar con los detalles. Es este hecho el que hace que los lenguajes de programación sean una buena idea en primer lugar; si pudiéramos manejar los detalles, podríamos simplemente programar 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 podrías querer diferentes medios para las dos situaciones. El mármol, por ejemplo, es un medio agradable y duradero para ideas terminadas, pero uno 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 todas partes. 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 elección de diseño que te da programas terminados elegantes puede no darte un proceso de diseño elegante. Por ejemplo, he escrito algunos macros que definen macros llenos de comillas invertidas anidadas que ahora parecen pequeñas joyas, pero escribirlos tomó horas de la prueba y error más fea, y francamente, todavía no estoy del todo seguro de que sean correctos.

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 abordas el problema desde la dirección de las artes, es menos probable que dependas de este tipo de prueba. No quieres terminar con un lenguaje de programación como el mármol.

Por ejemplo, es una gran ventaja en el desarrollo de software tener un nivel superior interactivo, lo que en Lisp se llama un bucle de lectura-evaluación-imprimir. 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 variables antes de usarlas, por ejemplo. Cuando solo estás escribiendo expresiones en el nivel superior, quieres poder establecer x en algún valor y luego comenzar a hacer cosas con x. No quieres tener que declarar el tipo de x primero. Puedes disputar 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 la práctica, para obtener un buen diseño tienes que acercarte y mantenerte cerca de tus usuarios. Tienes que calibrar tus ideas en usuarios reales constantemente, especialmente al principio. Una de las razones por las que las novelas de Jane Austen son tan buenas es que las leía en voz alta a su familia. Por eso nunca se hunde en descripciones artísticas autocomplacientes de paisajes, o en filosofías pretenciosas. (La filosofía está ahí, pero está entrelazada en la historia en lugar de ser pegada a ella como una etiqueta). Si abres una novela "literaria" promedio e imaginas leerla en voz alta a tus amigos como algo que has escrito, sentirás con demasiada claridad lo que es una imposición ese tipo de cosas sobre el lector.

En el mundo del software, esta idea se conoce como "Peor es Mejor". En realidad, hay varias ideas mezcladas en el concepto de "Peor es Mejor", que es por lo que la gente todavía discute si lo peor es realmente mejor o no. Pero una de las ideas principales en esa mezcla es que si estás construyendo algo nuevo, deberías poner un prototipo frente a los usuarios lo antes posible.

El enfoque alternativo podría llamarse la estrategia del Hail Mary. En lugar de sacar un prototipo rápidamente y refinarlo gradualmente, intentas crear el producto completo y terminado en un solo pase largo. Hasta donde sé, esta es una receta para el desastre. Incontables startups se destruyeron de esta manera durante la burbuja de Internet. Nunca he oído de un caso en el que funcionara.

Lo que la gente fuera del mundo del software puede no darse cuenta es que "Peor es Mejor" se encuentra en todas las artes. En el dibujo, por ejemplo, la idea fue descubierta 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 al final descubrirás que las líneas no se encuentran. En su lugar, deberías dibujar algunas líneas rápidas en aproximadamente el lugar correcto, y luego refinar gradualmente este boceto inicial.

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

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

Puedes hacer esto en software también. Un prototipo no tiene que ser solo un modelo; puedes refinarlo hasta convertirlo en el producto terminado. Creo que siempre deberías hacer esto cuando puedas. Te permite aprovechar nuevas ideas que tienes en el 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, supón 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 comienzas 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 es cierto en las artes, y particularmente en la pintura al óleo. La mayoría de los pintores comienzan con un boceto borroso y lo refinan gradualmente. Si trabajas de esta manera, entonces en principio nunca tienes que terminar el día con algo que realmente se vea inacabado. De hecho, hay incluso un dicho entre los pintores: "Una pintura nunca está terminada, solo dejas de trabajar en ella." Esta idea será familiar para cualquiera que haya trabajado en software.

La moral es otra razón por la que es difícil diseñar algo para un usuario no sofisticado. Es difícil mantener el interés en algo que no te gusta a ti mismo. Para hacer algo bueno, tienes que estar pensando: "vaya, esto es realmente genial," no "qué pedazo de mierda; esos tontos lo amarán."

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

Nota 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 ser bueno. Y, sin embargo, parece ser 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 de ellos parecen haber sido casos de unión molecular más que fusión nuclear. En una ópera es común que una persona escriba el libreto y otra la música. Y durante el Renacimiento, a menudo se empleaba a artesanos del norte de Europa para hacer los paisajes en los fondos de las pinturas italianas. Pero estas no son verdaderas colaboraciones. Son más bien ejemplos de "buenas cercas hacen buenos vecinos" de Robert Frost. Puedes juntar instancias de buen diseño, pero dentro de cada proyecto individual, una persona tiene que estar a cargo.

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

¿Por qué es que la investigación puede ser realizada por colaboradores y el diseño no? Esta es una pregunta interesante. No sé la respuesta. Quizás, si el diseño y la investigación convergen, la mejor investigación también es un buen diseño, y de hecho no puede ser realizada por 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 cuando la colaboración era menos común.

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

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