DISEÑO E INVESTIGACIÓN

Enero 2003

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


Los visitantes a este país a menudo se sorprenden al descubrir que a los estadounidenses les gusta empezar una conversación preguntando "¿qué haces?" Nunca me ha gustado esta pregunta. Pocas veces he tenido una respuesta clara a la misma. Pero creo que finalmente he resuelto el problema. Ahora, cuando alguien me pregunta lo que hago, los miro directo a los ojos y les digo: "Estoy diseñando un nuevo dialecto de Lisp." Le recomiendo esta respuesta a cualquiera que no le guste que le pregunten qué hace. La conversación cambiará de inmediato a otros temas.

No considero que este haciendo investigación sobre lenguajes de programación. Tan sólo estoy diseñando uno, de la misma manera que alguien puede diseñar un edificio o una silla o un nuevo tipo de letra. No estoy tratando de descubrir algo nuevo. Tan sólo quiero hacer un lenguaje que sea bueno para programar. En cierta manera, esta suposición hace la vida mucho más fácil.

La diferencia entre el diseño y la investigación parece ser una pregunta de nuevo contra 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 parte superior: el mejor diseño supera a sus predecesores mediante el uso de nuevas ideas, y la mejor investigación resuelve problemas que no sólo son nuevos, sino que en realidad vale la pena resolver. Así que en última instancia, nuestro objetivo es el mismo destino, sólo que aproximándose desde distintas direcciones.

De lo que hablare hoy es de como luce tu objetivo visto desde la parte posterior. ¿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 con la pregunta ¿para quién es esto y qué es lo que necesita de esto? Un buen arquitecto, por ejemplo, no empieza creando un diseño que impone a los usuarios, sino estudiando a los probables usuarios y averiguando lo que necesitan.

Noten que dije "lo que necesitan," y 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 indique el cliente. En las artes esto varía de un campo a otro, pero no creo que haya ningún campo en el que las mejores obras sean hechas por gente que sólo hace exactamente lo que le indican los clientes.

El cliente siempre tiene la razón en el sentido de que la medida de un buen diseño es lo bien que 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 vale como defensa decir que la novela o la silla está diseñada de acuerdo a los principios teóricos más avanzados.

Y, sin embargo, hacer lo que funciona para el usuario no significa simplemente hacer lo que te pide el usuario. Los usuarios no saben cuales son todas las opciones, y a menudo se confunden acerca de lo que realmente quieren.

La respuesta a la paradoja, creo yo, es que tienes que diseñar para el usuario, pero tienes que diseñar lo que el usuario necesita, no sólo lo que él dice que quiere. Es muy parecido a ser un doctor. No puedes sólo tratar los síntomas del paciente. Cuando un paciente te dice sus síntomas, tienes que averiguar lo que está realmente mal con él, y tratar eso.

Este enfoque en el usuario es una especie de axioma del que se puede derivar la mayor parte de la práctica de un buen diseño, y en torno al cual se centra la mayoría de los temas de diseño.

 

Si un buen diseño debe hacer lo que el usuario necesita, ¿quien es el usuario? Cuando digo que el diseño debe ser para los usuarios, no quiero dar a entender que un buen diseño tiene como objetivo una especie de mínimo común denominador. Puedes escoger cualquier grupo de usuarios que desees. Si estás diseñando una herramienta, por ejemplo, puedes diseñar para cualquier persona, desde principiantes hasta expertos, y lo que es un buen diseño para un grupo puede ser malo para el otro. El punto es, tienes que escoger un grupo de usuarios. Creo que ni siquiera se puede hablar de buen o mal diseño, excepto con referencia a algunos usuarios previstos.

Es más probable conseguir un buen diseño si los usuarios destinatarios incluyen al propio diseñador. Cuando se diseña 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 considerar al usuario, sin importar que sea con benevolencia, parece suficiente para corromper al diseñador. Sospecho que muy pocos proyectos de vivienda en los Estados Unidos fueron diseñados por arquitectos que se esperaba que vivieran en ellos. Puedes ver lo mismo en lenguajes de programación. C, Lisp y Smalltalk fueron creados para ser usados por sus propios diseñadores. Cobol, Ada, y Java, fueron creados para que otras personas los usen.

Si piensas que estas diseñando algo para idiotas, lo más probable es que no estes diseñando algo bueno, incluso para los idiotas.



Sin embargo, incluso si estas diseñando algo para los usuarios más sofisticados, todavía estas diseñando para seres humanos. Es diferente en la investigación. En las matemáticas no eliges abstracciones porque sean fáciles de entender para los humanos; eliges la que hace la prueba más corta. Creo que esto es cierto para las ciencias en general. No se supone que las ideas científicas sean ergonómicas.

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

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

Recuerda, también, que los lenguajes no son principalmente un medio para los programas terminados, sino algo en lo que los programas deben ser desarrollados. Cualquiera en las artes podría decirte que es posible que desees medios diferentes para dos situaciones. El mármol, por ejemplo, es un medio agradable y duradero para las ideas acabadas, pero desesperantemente inflexible para el desarrollo de nuevas ideas.

Un programa, al igual que una prueba, es una versión podada de un árbol que en el pasado tuvo falsos brotes ramificándose por todas partes. Así que la prueba de un lenguaje no es simplemente que tan limpio luce el programa terminado en el mismo, sino que tan limpia fue la ruta al programa terminado. Una elección de diseño que te ofrece elegantes programas acabados puede no darte un proceso de diseño elegante. Por ejemplo, he escrito unas pocas macros-definitorias de macros llenas de comillas invertidas anidadas que lucen ahora como pequeñas joyas, pero escribirlas llevó horas del más feo ensayo y error, y, francamente, todavía no estoy del todo seguro de que sean correctas.

A menudo actuamos como si la prueba de un lenguaje fuera que tan bien lucen los programas terminados en él. Parece muy convincente cuando ves el mismo programa escrito en dos lenguajes, y una versión es mucha más corta. Al abordar 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 similar al mármol.

Por ejemplo, es una gran ventaja desarrollar software que tenga un sistema interactivo de nivel superior, lo que en Lisp se llama un bucle read-eval-print. Y cuando tienes uno, esto tiene efectos reales en el diseño del lenguaje. Por ejemplo, no funcionará bien para un lenguaje en el que tienes que declarar variables antes de utilizarlas. Cuando sólo estas escribiendo expresiones en el nivel superior, deseas poder establecer x a un valor y luego empezar a hacer cosas a x. No quieres tener que declarar primero el tipo de x. Puedes cuestionar 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 hace obligatorias las declaraciones de tipo puede ser conveniente para que se programe en él.



En la práctica, para obtener un buen diseño tienes que estar y permanecer cerca a los usuarios. Tienes que calibrar tus ideas constantemente con los usuarios reales, sobre todo al principio. Una de las razones por las que las novelas de Jane Austen son tan buenas es que las lee en voz alta a su familia. Es por eso que nunca cae en auto-indulgentes descripciones artísticas de paisajes o pretencioso filosofar. (La filosofía está ahí, pero está tejida en la historia en lugar de estar pegada a ella como una etiqueta.) Si se abre una novela “literaria” promedio e imaginas leerla en voz alta a tus amigos como algo que has escrito, sentirás muy profundamente la imposición que representa en el lector este tipo de cosas.

En el mundo del software, esta idea se conoce como Peor es Mejor. En realidad, hay varias ideas mezcladas en el concepto de que Peor es Mejor, por lo que la gente sigue discutiendo sobre si peor es en realidad mejor o no. Pero una de las principales ideas de esa mezcla es que si estas construyendo algo nuevo, debes poner un prototipo delante de los usuarios tan pronto como sea posible.

El enfoque alternativo podría llamarse la estrategia Ave María. En lugar de obtener un prototipo de forma rápida y refinarlo poco a poco, intentas crear el producto completo terminado, como en un largo pase de anotación. Hasta donde sé, esta es una receta para el desastre. Innumerables startups [a] se destruyeron a sí mismas de esta manera durante la burbuja de Internet. [b] Nunca escuche hablar de un caso en el que funcionara.

Lo que la gente fuera del mundo del software no se da 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 mejor manera de conseguir un dibujo preciso, no es trabajar poco a poco alrededor del contorno de un objeto, ya que los errores se acumulan y encontrarás al final que las líneas no coinciden. En su lugar, deberías elaborar unas pocas líneas rápidas más o menos en el lugar correcto, y luego, gradualmente, refinar este boceto inicial.

En la mayoría de los campos, los prototipos han sido tradicionalmente hechos de diferentes materiales. Los tipos de letra que habrían de elaborarse en metal fueron diseñados inicialmente con un pincel sobre el papel. Estatuas que serían fundidas en bronce fueron modeladas en cera. Los patrones para bordar en los tapices fueron dibujados en papel con tinta lavable. Edificios que habrían de construirse a partir de piedra se pusieron a prueba a pequeña escala en madera.

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

También puedes hacer esto en el software. Un prototipo no tiene por qué ser sólo un modelo; se puede refinar en el producto final. Creo que hay que hacerlo siempre que se pueda. Te permite aprovechar las nuevas revelaciones que surgen 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 sobre ella. Uno de mis primeros profesores de dibujo me dijo: si estás aburrido cuando estás dibujando algo, el dibujo lucirá 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 la mitad y empiezas a hacer los ladrillos mecánicamente en lugar de observar cada uno de ellos, el dibujo se verá peor que si sólo hubieras sugerido los ladrillos.

Construir algo refinando gradualmente el prototipo es bueno para la moral, ya que te mantiene comprometido. En el software, mi regla es: ten siempre código funcional. Si estás escribiendo algo que podrás poner a prueba en una hora, entonces tienes la posibilidad de una recompensa inmediata para motivarte. Lo mismo es cierto en las artes, y en particular en la pintura al óleo. La mayoría de los pintores empiezan con un esbozo borroso y poco a poco lo perfeccionan. Si trabajas de esta manera, entonces, en principio, nunca tienes que terminar el día con algo que en realidad luzca sin terminar. De hecho, incluso hay un dicho entre los pintores: "Un cuadro nunca está terminado, simplemente dejas de trabajar en él." Esta idea resultara 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 mantener el interés en algo que no te gusta. Para hacer algo bueno, tienes que estar pensando, "wow, esto es realmente grandioso," y no "que porquería; le encantara a esos tontos."

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



Nota que 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 ser 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 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 en vez 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 fueron empleados con frecuencia para hacer los paisajes en los fondos de las pinturas italianas. Pero estas no son verdaderas colaboraciones. Son más como ejemplos de "las buenas cercas hacen buenos vecinos" de Robert Frost. Puedes poner juntos ejemplos de buen diseño, pero dentro de cada proyecto individual, una persona tiene que estar en control.

No estoy diciendo que un buen diseño requiere 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 acerca de que 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. Tal vez, si el diseño y la investigación convergen, el mejor trabajo de investigación es también un buen diseño, y de hecho no puede ser hecha por los colaboradores. Muchos de los científicos más famosos parecen haber trabajado solos. Pero no conozco los suficientes 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 frecuente.

Cualquiera que sea la historia en las ciencias, la verdadera colaboración parece ser sumamente 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 de un dictador. Una razón es que un buen diseño tiene que ser de una sola pieza. El diseño no es sólo para los humanos, sino para seres humanos individuales. Si un diseño representa una idea que cabe en la cabeza de una persona, entonces la idea cabrá en la cabeza del usuario también.

Traducido de Design and Research por Paul Graham. Traducción: Armando Alvarez.

 

[a] El termino startup define a una empresa de reciente creación orientada a la tecnología. El mismo Paul Graham la define a la perfección en Como Financiar una Startup: "Una empresa tiene que ser más que pequeña y de reciente creación para ser una startup. Hay millones de pequeñas empresas en Estados Unidos, pero sólo unas pocas miles son startups. Para ser una startup, una compañía tiene que ser un negocio de productos, no un negocio de servicios. Lo que no quiere decir que tiene que hacer algo físico, sino que tiene que tener una cosa que vende a mucha gente, en vez de hacer trabajos a medida para clientes individuales. El trabajo sobre encargo no es escalable. Para ser una startup tienes que ser la banda que vende un millón de copias de una canción, no el grupo que gana dinero tocando en bodas y Bar Mitzvahs individuales."

[b] La Burbuja de Internet, o Burbuja punto com, es un término que se refiere a una corriente económica especulativa muy fuerte que se dio entre 1997 y 2001, en la cual las bolsas de valores de las naciones occidentales vieron un rápido aumento de su valor debido al avance de las empresas vinculadas al nuevo sector de Internet y a la llamada Nueva Economía.

El período fue marcado por la fundación (y en muchos casos, espectacular quiebra) de un nuevo grupo de compañías basadas en Internet designadas comúnmente empresas punto com.

Una combinación de un veloz aumento de precios de las acciones, la especulación individual y la gran disponibilidad de capital de riesgo crearon un ambiente exuberante. El estallido de laburbuja.com marcó el principio de una relativamente suave, pero larga recesión en las naciones occidentales. [Fuente: Wikipedia. Ver].