DISEÑO E INVESTIGACIÓN

Enero de 2003

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

Los visitantes de este país se sorprenden a menudo al descubrir que a los estadounidenses les gusta empezar una conversación preguntando "¿qué haces?". 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 le digo "estoy diseñando un nuevo dialecto de Lisp ". Recomiendo esta respuesta a cualquiera a quien no le guste que le pregunten qué hace. La conversación derivará inmediatamente a otros temas.

No me considero alguien que esté investigando sobre lenguajes de programación. Sólo 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. Sólo quiero crear un lenguaje en el que sea bueno programar. En cierto modo, esta suposición hace la vida mucho más fácil.

La diferencia entre diseño e investigación parece ser una cuestión de lo nuevo frente a lo bueno. El diseño no tiene por qué ser nuevo, pero tiene que ser bueno. La investigación no tiene por qué 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 vale la pena resolver. Así que, en última instancia, estamos apuntando al mismo destino, solo que lo abordamos desde diferentes direcciones.

De lo que voy a hablar hoy es de cómo se ve el 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 por preguntar a quién va dirigido y qué necesita. Un buen arquitecto, por ejemplo, no empieza creando un diseño que luego impone a los usuarios, sino estudiando a los usuarios previstos y averiguando qué necesitan.

Fíjense 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 platos 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 lo hagan las personas que 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 lo bien que funciona para el usuario. Si creas una novela que aburre a todo el mundo, o una silla en la que resulta terriblemente incómodo sentarse, entonces has hecho un mal trabajo, punto. No sirve de defensa decir que la novela o la silla están diseñadas según los principios teóricos más avanzados.

Sin embargo, hacer lo que funciona para el usuario no significa simplemente hacer lo que el usuario le dice que haga. 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 hay que diseñar para el usuario, pero hay que diseñar lo que el usuario necesita, no simplemente lo que dice que quiere. Es muy parecido a ser médico: no se pueden tratar los síntomas de un paciente. Cuando un paciente te cuenta 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 puede derivar la mayor parte de la práctica del buen diseño y alrededor del cual se centran la mayoría de las cuestiones 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 decir que el buen diseño apunte a algún tipo de mínimo común denominador. Puedes elegir cualquier grupo de usuarios que quieras. 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 puede ser malo para otro. La cuestión es que tienes que elegir un grupo de usuarios. No creo que se pueda hablar siquiera 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 entre los usuarios previstos se encuentra el propio diseñador. Cuando diseñas algo para un grupo que no te incluye, suele ser para personas que consideras menos sofisticadas que tú, no más sofisticadas.

Esto es un problema, porque mirar al usuario por encima del hombro, por más benévolo 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. Se puede 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.

Sin embargo, incluso si estás diseñando algo para los usuarios más sofisticados, sigues diseñando para humanos. En la investigación es diferente. En matemáticas no se eligen abstracciones porque sean fáciles de entender para los humanos, se elige la que haga que la prueba sea más breve. Creo que esto es cierto para las ciencias en general. Las ideas científicas no están pensadas para ser ergonómicas.

En el arte, las cosas son muy diferentes. El diseño gira en torno a las personas. El cuerpo humano es algo extraño, pero cuando se diseña una silla, es para eso para lo que se diseña y no hay forma de evitarlo. Todas las artes tienen que complacer los intereses y las limitaciones de los seres humanos. En la pintura, por ejemplo, en igualdad de condiciones, un cuadro con personas será más interesante que uno sin ellas. No es un simple accidente histórico que los grandes cuadros del Renacimiento estén todos llenos de personas. Si no fuera así, 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ásico 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 manejar 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 en lenguaje de máquina.

Recuerde también que los lenguajes no son, en primer lugar, un formato para programas terminados, sino algo en lo que los programas deben desarrollarse. Cualquier persona que trabaje en el ámbito artístico podría decirle que, para ambas situaciones, es posible que necesite medios diferentes. El mármol, por ejemplo, es un medio agradable y duradero para las ideas terminadas, pero irremediablemente 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 que se han ido ramificando por todas partes. Por lo tanto, 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 le brinda programas terminados elegantes puede no brindarle 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 de la peor prueba y error, y francamente, todavía no estoy completamente seguro de que sean correctas.

A menudo actuamos como si la prueba de un lenguaje fuera el aspecto que tienen los programas terminados en él. Parece muy 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 perspectiva de las artes, es menos probable que dependas de este tipo de prueba. No quieres terminar con un lenguaje de programación como Marble.

Por ejemplo, es una gran victoria 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 en el que tienes que declarar 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 comenzar 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 lograr un buen diseño hay que acercarse a los usuarios y mantenerse cerca de ellos. Hay que calibrar constantemente las ideas sobre los usuarios reales, especialmente al principio. Una de las razones por las que las novelas de Jane Austen son tan buenas es que ella se las leía en voz alta a su familia. Por eso nunca cae en descripciones artísticas y autocomplacientes de paisajes ni en filosofías pretenciosas. (La filosofía está ahí, pero está entretejida en la historia en lugar de estar pegada a ella como una etiqueta). Si abres una novela "literaria" promedio e imaginas leyéndola en voz alta a tus amigos como algo que hubieras escrito tú, sentirás muy profundamente la imposición que supone ese tipo de cosas para el lector.

En el mundo del software, esta idea se conoce como "lo peor es mejor". En realidad, hay varias ideas mezcladas en el concepto de "lo peor es mejor", 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 creando algo nuevo, debes poner un prototipo frente a los usuarios lo antes posible.

El enfoque alternativo podría llamarse la estrategia del Ave María. En lugar de sacar un prototipo rápidamente y refinarlo gradualmente, se intenta crear el producto completo y terminado en una sola pasada. Hasta donde yo sé, 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 ajena al mundo del software puede no saber es que el principio de que lo peor es lo mejor está presente 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 conseguir un dibujo preciso no es ir avanzando lentamente por el contorno de un objeto, porque los errores se acumularán y al final descubrirás que las líneas no se unen. En lugar de eso, debes dibujar unas cuantas líneas rápidas en el lugar más o menos correcto y luego refinar gradualmente este boceto inicial.

En la mayoría de los campos, los prototipos se han fabricado tradicionalmente con diferentes materiales. Los tipos de letra que se iban a cortar en metal se diseñaban inicialmente con un pincel sobre papel. Las estatuas que se iban a fundir en bronce se modelaban en cera. Los patrones que se iban a bordar en tapices se dibujaban sobre papel con aguada de tinta. Los edificios que se iban a construir en piedra se probaban a menor escala en madera.

Lo que hizo que la pintura al óleo fuera tan interesante cuando se hizo popular en el siglo XV fue que uno podía hacer la obra terminada a partir del prototipo. Si quería, podía hacer un dibujo preliminar, pero no estaba obligado a hacerlo; podía trabajar en todos los detalles e incluso hacer cambios importantes a medida que terminaba la pintura.

También se puede hacer esto en el software. Un prototipo no tiene por qué ser simplemente un modelo; se puede perfeccionar hasta obtener el producto final. Creo que siempre se debe hacer esto cuando se puede. Permite aprovechar los nuevos conocimientos que se obtienen a lo largo del proceso. Pero quizás aún más importante es que 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 parecerá 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 a partir de un prototipo que se va perfeccionando poco a poco es bueno para la moral, porque te mantiene motivado. En el ámbito del software, mi regla es: siempre hay que tener un código que funcione. Si estás escribiendo algo que podrás probar en una hora, entonces tienes la perspectiva de una recompensa inmediata que te motivará. Lo mismo ocurre en las artes, y en particular en la pintura al óleo. La mayoría de los pintores empiezan con un boceto borroso y lo van perfeccionando poco a poco. Si trabajas de esta manera, en principio nunca tendrás que terminar el día con algo que parezca inacabado. De hecho, hay un dicho entre los pintores: "Un cuadro nunca está terminado, simplemente dejas de trabajar en él". Esta idea le resultará familiar a cualquiera que haya trabajado en software.

La moral es otra razón por la que resulta difícil diseñar algo para un usuario poco sofisticado. Es difícil mantener el interés en algo que a uno mismo no le gusta. Para hacer algo bueno, hay que pensar: "Vaya, esto es realmente genial", no: "Qué porquería; a esos tontos les encantará".

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

Observen que durante todo este tiempo he estado hablando del "diseñador". El diseño, por lo general, tiene que 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. Esta me parece una de las diferencias más interesantes entre investigación y diseño.

Ha habido ejemplos famosos de colaboración en las artes, pero la mayoría de ellos parecen haber sido casos de unión molecular más que de fusión nuclear. En una ópera es habitual que una persona escriba el libreto y otra la música. Y durante el Renacimiento, se solía contratar a artesanos del norte de Europa para que pintaran los paisajes de fondo de las pinturas italianas. Pero no se trata de verdaderas colaboraciones. Son más bien ejemplos del dicho de Robert Frost: "las buenas cercas hacen buenos vecinos". Se pueden juntar ejemplos de buen diseño, pero dentro de cada proyecto individual, una persona tiene que estar al mando.

No digo 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 criterio confías. Pero una vez que se termina de hablar, la decisión sobre qué hacer debe recaer en una sola persona.

¿Por qué la investigación puede ser realizada por colaboradores y el diseño no? Es una pregunta interesante, pero no sé la respuesta. Tal vez, si el diseño y la investigación convergen, la mejor investigación también sea un buen diseño y, de hecho, no pueda 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 existe un patrón en este caso. 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 colaboración verdadera parece ser cada vez más rara en las artes. El diseño por comité es sinónimo de mal diseño. ¿Por qué? ¿Hay alguna manera de superar esta limitación?

Me inclino a pensar que no existe tal cosa: que el buen diseño requiere un dictador. Una de las razones es que el buen diseño tiene que ser integral. El diseño no es sólo para los humanos, sino para los 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.