Por: Paul Graham

Traducción: Erick Ivaán López Carreón

Enero 2003

(Este artículo se deriva de una platica dada a finales de 2002 en la reunión de NEPLS.)

Los visitantes de este país usualmente se sorprenden de que a los Estadounidenses les guste iniciar la conversación preguntando "A que se dedica?". A mi nunca me ha gustado esta pregunta. Raramente tenía una respuesta adecuada a esta pregunta. Pero creo que finalmente resolví el problema. Ahora, cuando alguien me pregunta a que me dedico, lo miro directamente a los ojos y le digo: estoy diseñando un nuevo dialecto de Lisp. Les recomiendo esta respuesta a cualquiera que no le guste que le pregunten a que se dedica. La conversación cambia inmediatamente hacia otros temas.

No considero que yo mismo este haciendo investigación en lenguajes de programación. Solo estoy diseñando uno, del mismo modo que alguien puede diseñar un edificio o una silla o un nuevo tipo de letra. No estoy tratando de descubrir nada nuevo. Solo quiero hacer un nuevo lenguaje que sea bueno para programar en él. En ciertas formas, 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 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 cima: El mejor diseño sobrepasa a sus predecesores al usar nuevas ideas, y la mejor investigación resuelve problemas que no son solamente nuevos, sino que actualmente vale la pena resolverlos. Así que finalmente nos estamos dirigiendo al mismo destino, solo que enfocándolo desde diferentes direcciones.

De lo que voy a hablar el día de hoy es de como luce su objetivo desde el otro lado. Que es lo que haces diferente cuando tratas a los lenguajes de programación como un problema de diseño en lugar de como un tema de investigación.

La mayor diferencia es que te enfocas mas en el usuario. El diseño comienza por preguntarse para quien es y que necesitan ellos de él? Un buen arquitecto, por ejemplo, no comienza por crear un diseño que después el impone a los usuarios, sino por estudiar a los pretendidos usuarios y descubrir que es lo que ellos necesitan.

Noten que dije "lo que ellos necesitan", no "lo que ellos quieren." No quiero dar la impresión que trabajar como diseñador significa trabajar como una especie de cocinero de comida rápida, haciendo cualquier cosa que el cliente les pida. Esto varía de campo en campo en las artes, pero no creo que exista ningún campo en el cual el mejor trabajo lo haga la gente que hace exactamente lo que los clientes les dicen que hagan.

El cliente siempre tiene la razón en el sentido de que la medida del buen diseño es que tan bien funciona para el usuario. Si haces una novela que aburre a todos, o una silla que es horriblemente incómoda para sentarse en ella, entonces hiciste un mal trabajo, punto. No es defensa decir que la novela o la silla estan diseñadas de acuerdo a los mas avanzados principios teóricos.

Y aun así, hacer algo que funcione para el usuario no significa simplemente hacer lo que el usuario te diga. Los usuarios no saben que opciones existen, y usualmente estan equivocados acerca 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 simplemente lo que el dice que quiere. Se parece mucho a ser como un medico. No puedes tratar solamente los síntomas del paciente. Cuando un paciente te dice sus síntomas, tienes que encontrar que es lo que actualmente padece, y tratar eso.

Este enfoque en el usuario es una especie de axioma del cual se deriva la mayoría de la práctica del buen diseño, y alrededor del cual se centran la mayoría de las cuestiones 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 se dirige hacia algún tipo de mínimo común denominador. Puedes elegir cualquier grupo de usuarios que desees. Por ejemplo, si estas diseñando una herramienta, puedes diseñarla para todos desde principiantes hasta expertos, y lo que es buen diseño para un grupo puede ser malo para otro. El punto es, tienes que elegir algún grupo de usuarios. No creo que puedas incluso hablar acerca de buen o mal diseño excepto en referencia a algún usuario destino.

Es mas probable que logres un buen diseño si el usuario destino incluye al diseñador mismo. Cuando diseñas algo para un grupo que no te incluye, tiende a ser para personas que consideras menos sofisticadas que tu, no más sofisticadas.

Eso es un problema, debido a que mirar hacia abajo al usuario, sin importar cuan benevolentemente, parece inevitablemente corromper al diseñador. Sospecho que muy pocos proyectos habitacionales en USA fueron diseñados por arquitectos que pensaban vivir en ellos. Puedes ver la misma cosa en los 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 otra gente los usara.

Si crees que estas diseñando algo para idiotas, es muy probable que no diseñes algo bueno, ni siquiera para idiotas.

Incluso si estas diseñando algo para los más sofisticados usuarios, creo que, aún estarás diseñando para humanos. En investigación es diferente. En matemáticas no eliges abstracciones debido a que son fáciles de comprender para los humanos; eliges lo que sea que haga la prueba mas corta. Creo que esto es una verdad para las ciencias en general. Las ideas científicas no estan pensadas para ser ergonómicas.

Respecto a las artes, las cosas son muy diferentes. Todo el diseño se refiere a la gente. El cuerpo humano es una cosa extraña, pero cuando estas diseñando una silla, eso es para lo que tu estas diseñando, y no hay de otra. Todas las artes tienen que consentir los intereses y limitaciones de los humanos. En pintura, por ejemplo, todas las otras cosas siendo iguales una pintura con gente en ella será mas interesante que una sin gente. No es un mero accidente de la historia que las grandes pinturas del renacimiento estén llenas de personas. Si no hubiera sido así, la pintura como un medio no tendría el prestigio que tiene.

Nos guste o no, los lenguajes de programación son también para personas, y sospecho que el cerebro humano esta tan lleno de grumos e idiosincrasia como el cuerpo humano. Algunas ideas son fáciles de captar para la gente y algunas no lo son. Por ejemplo, parece que tenemos una capacidad muy limitada para manejar los detalles. Es este hecho el que hace que los lenguajes de programación sean una buena idea en primer lugar; si pudiéramos lidiar con el detalle, simplemente programaríamos en lenguaje máquina.

Recuerden, también, que los lenguajes no son esencialmente programas terminados, sino algo en lo que se desarrollan los programas. Cualquiera dentro de las artes puede decirte que puede que quieras diferentes medios para las dos situaciones. El mármol, por ejemplo, es un excelente, medio duradero para las ideas terminadas, pero uno desesperanzadoramente inflexible para desarrollar nuevas ideas.

Un programa, al igual que una prueba, es una versión recortada de un árbol que en el pasado tuvo falsos comienzos alejándose todos entre sí. Así que para probar un lenguaje no es tan solo lo claro que el programa finalizado luce en él, sino que tan clara fue la ruta para finalizarlo. Una elección de diseño que proporciona elegantes programas finales puede no proporcionar un elegante proceso de diseño. Por ejemplo, he escrito unas cuantas macros define-macro llenas de comillas invertidas anidadas que lucen ahora como pequeñas gemas, pero escribirlas tomo horas de horribles pruebas y errores, y francamente, aún no estoy enteramente seguro de que sean correctas.

Muy seguido actuamos como si la prueba de un lenguaje fuera que tan bien lucen los programas terminados usando este lenguaje. Parece muy convincente cuando ves el mismo programa escrito en dos lenguajes, y una versión es mucho mas corta. Cuando abordas el problema desde el punto de vista de las artes, es menos probable que dependas de este tipo de prueba. No quieres terminar con un lenguaje de programación que sea como el mármol.

Por ejemplo, es una gran ventaja al desarrollar software tener un nivel superior (toplevel) interactivo, lo que en Lisp es llamado un ciclo read-eval-print (leer-evaluar-imprimir). Y cuando tienes uno, esto tiene efectos tangibles en el diseño del lenguaje. Puede no funcionar bien para un lenguaje donde tienes que declarar las variables antes de poder usarlas, por ejemplo. Cuando simplemente estas tecleando expresiones en el toplevel, quisieras ser capaz de se ajustar x a algún valor y entonces comenzar a usar x. No quisieras tener que declarar el tipo de x primero. Puedes debatir cualquiera de las premisas, pero si un lenguaje tiene que tener un toplevel para ser conveniente, y las declaraciones de tipo obligatorias son incompatibles con un toplevel, entonces ningún lenguaje que hace obligatorias las declaraciones de tipo sería adecuado para programar en él.

En la práctica, para lograr un buen diseño tienes que lograr acercarte, y permanecer cerca, de tus usuarios. Tienes que calibrar tus ideas con los usuarios actuales constantemente, especialmente al inicio. Una de las razones por las que las novelas de Jane Austen's son tan buenas es que ella se las lee en voz alta a su familia. Esa es la razón por la cual ella nunca cae dentro de auto indulgentes imitaciones pseudo artísticas de paisajes, o filosofa pretenciosamente. (La filosofía esta ahí, pero esta entrelazado con la historia en lugar de ser pegada en ella como un etiqueta). Si abres una novela “literaria” promedio y te imaginas leyéndola en voz alta a tus amigos como si tu la hubieras escrito, sentirías agudamente que una imposición de este tipo esta sobre el lector.

En el mundo del software, ésta idea es conocida como Peor es Mejor. Actualmente, existen varias ideas mezcladas en el concepto de Peor es Mejor, y es por eso que la gente aun argumenta acerca de si peor es actualmente mejor o no. Pero una de las principales ideas en esa mezcla, es que si estas construyendo algo nuevo, deberías poner un prototipo delante de los usuarios tan pronto como sea posible.

El enfoque alternativo puede ser llamado la estrategia saluda a Mary. En lugar de obtener un prototipo funcional rápidamente y gradualmente refinarlo, tratas de crear el producto completo, finalizado, en un largo pase de anotación. Por lo que se, esta es una receta para el desastre. Incontables empresas emprendedoras se han destruido a si mismas de este modo durante la burbuja de la Internet. Nunca he escuchado de un caso donde esta estrategia funcionara.

De lo que no se da cuenta la gente de fuera del mundo del software es de que Peor es Mejor see encuentra a través de las artes. En Dibujo, por ejemplo, la idea fue descubierta durante el Renacimiento. Ahora, casi todos los maestros de Dibujo te dirá que la manera correcta de obtener un dibujo preciso no es trabajar lentamente alrededor del contorno de un objeto, debido a que los errores se acumularan y al final te encontraras que las líneas no confluyen. En lugar de eso debes dibujar unas cuantas líneas rápidas bruscamente en el lugar correcto, y entonces, gradualmente, refinar este boceto inicial.

En la mayoría de las áreas, los prototipos tradicionalmente se hacen de materiales diferentes. Las fuentes que serán cortadas en metal, originalmente son diseñadas con una brocha en un papel. Las estatuas que serán de bronce fueron modeladas en cera. Los modelos a ser bordados en tapetes fueron dibujados en papel con una tinta lavable. Los edificios que serán construidos de piedra fueron probados con una pequeña maqueta en madera.

Lo que hizo a la pintura de óleo tan excitante, cuando se volvió popular por primera vez en el siglo XV, fue que puedes hacer el trabajo final partiendo del prototipo. Puedes hacer un dibujo preliminar si lo deseas, pero no estas atado a él; puedes trabajar en los detalles e incluso hacer cambios mayores, cuando hayas finalizado la pintura.

Puedes hacer esto también con el software. Un prototipo no tiene que ser solo un modelo; puedes refinarlo hasta obtener el producto final. Creo que deberías hacer esto siempre que puedas. Te permitirá tomar ventaja de las percepciones que vayas obteniendo a lo largo del camino. Y además, incluso mas importante, es que es bueno para la moral.

La moral es clave en el diseño. Estoy sorprendido de que la gente ya no hable acerca de esto. Uno de mis primeros maestros de Dibujo me dijo: si estas aburrido cunado estas dibujando algo, el dibujo lucirá aburrido. Por ejemplo, supongamos que tienes que dibujar un edificio, y decides dibujar cada ladrillo individualmente. Puedes hacerlo si quieres, pero estarás aburrido a medio camino y comenzaras a hacer los ladrillos mecánicamente en lugar de observar cada uno, el dibujo lucirá peor que si meramente hubieras sugerido los ladrillos.

Construir algo, mediante el refinamiento gradual de un prototipo es bueno para la moral debido a que te mantiene interesado. En software, mi regla es: siempre tener código trabajando. Si estas escribiendo algo que seras capaz de probar en una hora, entonces tienes la expectativa de una recompensa inmediata para motivarte. Lo mismo es cierto en las artes, y particularmente en la pintura de óleo. La mayoría de los pintores comienzan con un boceto borroso y gradualmente lo van refinando. Si trabajas de esta manera, entonces, en principio, nunca tendrás que terminar el día con algo que luzca incompleto. Verdaderamente, incluso hay un dicho entre los pintores: “Un pintura nunca esta terminada, solo se deja de trabajar en ella.” Esta idea es familiar para cualquiera que haya trabajado en software.

La moral es otra razón por la cual es difícil diseñar algo para un usuario poco sofisticado. Es difícil permanecer interesado en algo que realmente no te gusta. Para hacer algo bueno, tienes que pensar, “guau, esto es realmente grandioso,” no “que pedazo de mierda; le va a encantar a esos tontos.”

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

Noten que todo este tiempo he estado hablando acerca de “el diseñador.” El diseño usualmente tiene que estar bajo control de una sola persona para ser algo bueno. Y aun así parece posible para varias personas colaborar en un proyecto de investigación. Esto me parece una de las mas interesantes diferencias entre investigación y diseño.

Existen famosos ejemplos de colaboración en las artes, pero la mayoría de ellos parecen haber sido casos de enlace molecular mas que de fusión nuclear. En una opera, es común que una persona escriba el libreto y otra escriba la música. Y durante el Renacimiento, los jornaleros del norte de Europa eran empleados de manera común para hacer los paisajes en los fondos de las pinturas italianas. Pero esas no eran colaboraciones reales. Eran mas como ejemplos de la frase de Robert Frost “buenas cercas hacen buenos vecinos.” Puedes poner juntas instancias de buen diseño, pero dentro de cada proyecto individual, una persona tiene que tener el control.

No estoy diciendo que el buen diseño requiere que una persona piense en todo, No hay nada mas valioso que el consejo de alguien en cuyo juicio confías. Pero después de que platiques con él, la decisión acerca de que hacer tiene que recaer en una persona.

Porque la investigación puede ser hecha por colaboradores y el diseño no? Esta es una pregunta interesante. No conozco la respuesta. Si embargo, si diseño e investigación convergen, la mejor investigación es también buen diseño, y de hecho puede ser realizada por colaboradores. Muchos de los mas famosos científicos parecen haber trabajado solos. Pero no se lo suficiente para saber si existe un patrón aquí. Puede ser simplemente que muchos de los científicos famosos trabajaron cuando la colaboración era menos común.

Cualquiera que sea la historia en la ciencias, la verdadera colaboración parece ser difuminadamente rara en las artes. Diseño por comité es sinónimo de mal diseño. Porqué es esto así? Existe alguna manera de derribar esta limitación?

Estoy inclinado 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 de una sola pieza. El diseño no es solo para humanos, sino para humanos individuales. Si un diseño representa una idea que se cabe en la cabeza de una persona, entonces la idea puede caber también en la cabeza del usuario.