Diseño e Investigación

Enero de 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 iniciar una conversación preguntando "¿a qué te dedicas?" Nunca me ha gustado esta pregunta. Raramente he tenido una respuesta concisa. 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 cambiará inmediatamente a otros temas.

No me considero que esté investigando 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 las cosas.

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. Así que, en última instancia, apuntamos al mismo destino, solo que lo abordamos 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 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é necesita 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.

Nótese 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 a la orden, 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 lo hagan las personas que simplemente hacen exactamente lo que los clientes les dicen.

El cliente siempre tiene la razón en el sentido de que la medida de un buen diseño es qué tan bien funciona para el usuario. Si escribes 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 una defensa decir que la novela o la silla están diseñadas según 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 conocen 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 cuenta sus síntomas, tienes que averiguar qué le pasa realmente 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 giran la mayoría de los problemas de diseño.

Si un 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 cualquier persona, 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 un grupo de usuarios. No creo que se pueda hablar de buen o mal diseño excepto en referencia a algún usuario previsto.

Es muy 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 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 benevolente que sea, 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 los usaran otras personas.

Si crees que estás diseñando algo para idiotas, lo más probable es 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, todavía lo 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 acortan la demostración. 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 algo extraño, pero cuando estás diseñando una silla, eso es para lo que estás diseñando, y no hay forma de evitarlo. Todas las artes tienen que complacer los intereses y limitaciones de los humanos. En la pintura, por ejemplo, si todo lo demás es igual, una pintura con gente será más interesante que una sin gente. No es meramente un accidente de la historia que las grandes pinturas del Renacimiento estén llenas de gente. 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ásico como el cuerpo humano. Algunas ideas son fáciles de captar para las personas y otras no. Por ejemplo, parece que tenemos una capacidad muy limitada para tratar 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 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 deben 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 terriblemente inflexible para desarrollar nuevas ideas.

Un programa, como una demostración, es una versión podada de un árbol que en el pasado ha tenido inicios falsos ramificándose por todas partes. Así que 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 te da programas terminados elegantes puede no darte un proceso de diseño elegante. Por ejemplo, he escrito algunas macros que definen macros llenas de comillas invertidas anidadas que ahora parecen pequeñas joyas, pero escribirlas llevó horas del ensayo y error más feo, y francamente, todavía no estoy completamente seguro de que sean correctas.

A menudo actuamos como si la prueba de un lenguaje fuera lo bueno que 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 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 leer-evaluar-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 simplemente estás escribiendo expresiones en el nivel superior, quieres poder asignar un valor a x y luego empezar a hacer cosas con x. No quieres tener que declarar primero el tipo de x. 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 obligatorias las declaraciones de tipo 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 de paisajes autoindulgentes o en filosofías pretenciosas. (La filosofía está ahí, pero está tejida en la historia en lugar de pegada 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 demasiado agudamente qué imposición es ese tipo de cosas para 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, razón por la cual la gente todavía discute si 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 de la "Hail Mary" (jugada desesperada). En lugar de sacar un prototipo rápidamente y refinarlo gradualmente, intentas crear el producto completo y terminado en un único y largo pase de touchdown. Hasta donde yo sé, esta es una receta para el desastre. Innumerables startups se destruyeron 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 no darse cuenta es que Peor es Mejor 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 al final descubrirás que las líneas no se unen. En cambio, deberías hacer unas cuantas 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 materiales diferentes. Las tipografías que se cortarían en metal se diseñaban inicialmente con un pincel sobre papel. Las estatuas que se fundirían en bronce se modelaban en cera. Los patrones que se bordarían en tapices se dibujaban en papel con aguada. Los edificios que se construirían de piedra se probaban a menor escala en madera.

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

Puedes hacer esto también en software. Un prototipo no tiene por qué ser solo un modelo; puedes refinarlo hasta convertirlo en el producto terminado. Creo que siempre deberías hacer esto cuando puedas. Te permite aprovechar las nuevas ideas que tengas 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 ella. Uno de mis primeros profesores de dibujo me dijo: si te aburres al dibujar 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 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: ten siempre código funcional. Si estás escribiendo algo que podrás probar en una hora, entonces tienes la perspectiva de una recompensa inmediata que te motive. Lo mismo ocurre 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 parezca inacabado. De hecho, hay incluso un dicho entre los pintores: "Una pintura nunca está terminada, simplemente 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 poco sofisticado. Es difícil mantenerse interesado en algo que a uno mismo no le gusta. Para hacer algo bueno, tienes que pensar: "vaya, esto es realmente genial", no "qué mierda; a esos tontos les encantará".

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

Nótese que todo este tiempo he estado hablando de "el 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 instancias famosas de colaboración en las artes, pero la mayoría de ellas parecen haber sido casos de unión molecular en lugar 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 jornaleros del norte de Europa a menudo eran empleados para hacer los paisajes en los fondos de las pinturas italianas. Pero estas no son colaboraciones verdaderas. Son más como ejemplos de las "buenas vallas hacen buenos vecinos" de Robert Frost. Puedes juntar instancias de buen diseño, pero dentro de cada proyecto individual, una persona tiene que tener el control.

No digo que el buen diseño requiera que una persona piense en todo. No hay nada más valioso que el consejo de alguien en cuyo juicio confías. Pero después de que se ha hablado, la decisión sobre qué hacer debe recaer en una persona.

¿Por qué 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 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.

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

Me inclino 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 unidad. 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.

Relacionado: