DISEÑO E INVESTIGACIÓN

Enero 2003

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

A los visitantes de este país a menudo les sorprende 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 concisa 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 le 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 se desviará inmediatamente a otros temas.

No me considero a mí mismo haciendo investigación sobre 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. Simplemente quiero hacer un lenguaje que sea bueno para programar.

La diferencia entre el diseño y la 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 utilizando nuevas ideas, y la mejor investigación resuelve problemas que no solo son nuevos, sino que realmente vale la pena resolver. Así que en última instancia, estamos apuntando al mismo destino, solo que nos acercamos a él desde diferentes direcciones.

Lo que voy a hablar hoy es cómo se ve tu objetivo desde atrás. ¿Qué haces de manera diferente cuando tratas a 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 enfoques 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 impone a los usuarios, sino estudiando a los usuarios previstos y averiguando qué necesitan.

Noté 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. Esto varía de campo a campo 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 siempre tiene razón en el sentido de que la medida del buen diseño es qué tan bien funciona para el usuario. Si haces una novela que aburre a todos o una silla que es horriblemente incómoda de sentarse, entonces has hecho un mal trabajo, punto. No es una defensa decir que la novela o la silla está diseñada de acuerdo con los principios teóricos más avanzados.

Y sin embargo, 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 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 necesita el usuario, ¿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 apunta 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 a un grupo de usuarios. No creo que puedas hablar de buen o mal diseño sin 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 hacia abajo al usuario, por muy benévolamente que sea, parece corromper inevitablemente al diseñador. Sospecho que muy pocos proyectos de vivienda en 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 los usaran otras personas.

Si crees que estás diseñando algo para idiotas, es probable que no estés diseñando algo bueno, incluso para los idiotas.

Incluso si estás diseñando algo para los usuarios más sofisticados, aún 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 hagan que la prueba sea más corta. Creo que esto es cierto para las ciencias en general. Las ideas científicas no están diseñadas para ser ergonómicas.

En las artes, las cosas son muy diferentes. El diseño se trata de las personas. El cuerpo humano es una cosa extraña, pero cuando diseñas una silla, es para eso para lo que la diseñas, y no hay forma de evitarlo. Todas las artes tienen que adular los intereses y limitaciones de los humanos. En la pintura, por ejemplo, todas las demás 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.

Nos guste o no, los lenguajes de programación también son para las 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. Este hecho es lo que hace que los lenguajes de programación sean una buena idea en primer lugar; si pudiéramos manejar los detalles, simplemente podríamos programar en lenguaje de máquina.

Recuerda también que los idiomas no son principalmente una forma para programas terminados, sino algo que los programas tienen que desarrollarse en. Cualquiera en las artes podría decirte que podrías querer diferentes medios para los dos situaciones. El mármol, por ejemplo, es un medio agradable y duradero para 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 inicios ramificándose por todas partes. Entonces la prueba de un lenguaje no es simplemente qué tan limpio se ve el programa terminado en él, sino qué tan limpio fue el camino hacia el programa terminado. Una elección de diseño que le da programas terminados elegantes puede no darle un proceso de diseño elegante. Por ejemplo, he escrito algunos macros que definen macros llenos de comillas inversas anidadas que ahora parecen pequeñas joyas, pero escribirlos tomó horas de la más fea prueba y error, y francamente, todavía no estoy del todo seguro de que sean correctos.

A menudo actuamos como si la prueba de un lenguaje fuera qué tan bueno se ven los programas terminados en él. Parece tan convincente cuando ves el mismo programa escrito en dos idiomas, 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 terminar con un lenguaje de programación como el mármol.

Por ejemplo, es un gran logro en el desarrollo de software 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 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 a x. No quieres tener que declarar el tipo de x primero. Puedes discutir 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 declaraciones de tipo obligatorias podría ser conveniente de programar.

En la práctica, para obtener un buen diseño, tienes que acercarte y permanecer 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. Es por eso que nunca se hunde en descripciones autosuficientemente artísticas de paisajes, o filosofía pretenciosa. (La filosofía está allí, pero está entretejida en la historia en lugar de ser pegada como una etiqueta). Si abres una novela "literaria" promedio e imaginas leerla en voz alta a tus amigos como algo que habrías escrito, sentirás con demasiada agudeza qué imposición es ese tipo de cosa 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, por lo que la gente todavía está discutiendo sobre si peor es realmente mejor o no. Pero una de las ideas principales en esa mezcla es que si estás construyendo algo nuevo, debes obtener 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 de una sola vez. Hasta donde sé, esta es una receta para el desastre. Innumerables startups se destruyeron de esta manera durante la burbuja de Internet. Nunca he oído de un caso en el que haya funcionado.

Lo que las personas fuera del mundo del software pueden no darse cuenta es que Worse is Better se encuentra en todo el arte. En el dibujo, por ejemplo, la idea se descubrió durante el Renacimiento. Ahora casi todos los maestros 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 encuentran. En su lugar, debes dibujar algunas 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 de diferentes materiales. Las tipografías que se cortarán en metal se diseñaron inicialmente con un pincel sobre papel. Las estatuas que se fundirán en bronce se modelaron en cera. Los patrones que se bordaron en tapices se dibujaron en papel con tinta lavada. Los edificios que se construirán en 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 podías realmente hacer la obra terminada a partir del prototipo. Podrías hacer un dibujo preliminar si lo deseabas, pero no te adherías a él; podrías resolver todos los detalles e incluso hacer cambios importantes, mientras terminabas la pintura.

También puedes hacer esto en software. Un prototipo no tiene que ser solo un modelo; puedes refinarlo en el producto final. Creo que siempre deberías hacer esto cuando puedas. Te permite aprovechar los nuevos conocimientos 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 eso. Uno de mis primeros maestros 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 hacerlo si quieres, pero si te aburres a mitad del 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 funcional. 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 sin terminar. De hecho, incluso hay un dicho entre los pintores: "Una pintura nunca se termina, simplemente dejas de trabajar en ella". Esta idea será familiar para cualquiera que haya trabajado en software.

El morale es otra razón por la que es difícil diseñar algo para un usuario poco 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é mierda; a esos tontos les encantará".

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

Fíjate en todo este tiempo que he estado hablando del "diseñador". El diseño suele estar bajo el control de una sola persona para que sea 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 famosos casos de colaboración en las artes, pero la mayoría de ellos parecen haber sido casos de enlace 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, a menudo se empleaba a aprendices del norte de Europa para hacer los paisajes en los fondos de las pinturas italianas. Pero estos no son verdaderas colaboraciones. Son más bien ejemplos de la "buena cerca hace 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 sola persona piense en todo. No hay nada más valioso que el consejo de alguien en cuyo juicio confíes. Pero después de que se haya terminado de hablar, la decisión sobre qué hacer tiene que recaer en una sola persona.

¿Por qué es que la investigación puede hacerse en colaboración 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 buen diseño, y de hecho no puede hacerse en colaboración. Muchos de los científicos más famosos parecen haber trabajado solos. Pero no sé lo suficiente como 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.

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

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

Relacionado:

[1]