Design et Recherche

Janvier 2003

(Cet article est tiré d'une conférence plénière donnée lors de la réunion d'automne 2002 de NEPLS.)

Les visiteurs de ce pays sont souvent surpris de constater que les Américains aiment commencer une conversation en demandant « que faites-vous ? » Je n'ai jamais aimé cette question. J'y ai rarement eu une réponse claire. Mais je pense avoir enfin résolu le problème. Maintenant, quand quelqu'un me demande ce que je fais, je le regarde droit dans les yeux et je dis : « Je suis en train de concevoir un nouveau dialecte de Lisp. » Je recommande cette réponse à quiconque n'aime pas qu'on lui demande ce qu'il fait. La conversation se tournera immédiatement vers d'autres sujets.

Je ne me considère pas comme faisant de la recherche sur les langages de programmation. Je suis juste en train d'en concevoir un, de la même manière que quelqu'un pourrait concevoir un bâtiment, une chaise ou une nouvelle police de caractères. Je n'essaie pas de découvrir quoi que ce soit de nouveau. Je veux juste créer un langage qui sera agréable à programmer. D'une certaine manière, cette hypothèse simplifie grandement les choses.

La différence entre le design et la recherche semble être une question de nouveauté versus qualité. Le design n'a pas besoin d'être nouveau, mais il doit être bon. La recherche n'a pas besoin d'être bonne, mais elle doit être nouvelle. Je pense que ces deux chemins convergent au sommet : le meilleur design surpasse ses prédécesseurs en utilisant de nouvelles idées, et la meilleure recherche résout des problèmes qui sont non seulement nouveaux, mais réellement dignes d'être résolus. En fin de compte, nous visons la même destination, mais nous l'abordons depuis des directions différentes.

Ce dont je vais parler aujourd'hui, c'est de ce à quoi ressemble votre cible vue de dos. Que faites-vous différemment lorsque vous traitez les langages de programmation comme un problème de design plutôt que comme un sujet de recherche ?

La plus grande différence est que vous vous concentrez davantage sur l'utilisateur. Le design commence par se demander : à qui cela s'adresse-t-il et de quoi l'utilisateur a-t-il besoin ? Un bon architecte, par exemple, ne commence pas par créer un design qu'il impose ensuite aux utilisateurs, mais en étudiant les utilisateurs visés et en déterminant ce dont ils ont besoin.

Notez que j'ai dit « ce dont ils ont besoin », et non « ce qu'ils veulent ». Je ne veux pas donner l'impression que travailler en tant que designer signifie travailler comme une sorte de cuisinier rapide, préparant tout ce que le client vous demande. Cela varie d'un domaine à l'autre dans les arts, mais je ne pense pas qu'il y ait un domaine dans lequel le meilleur travail est réalisé par ceux qui se contentent de faire exactement ce que les clients leur disent.

Le client a toujours raison dans le sens où la mesure d'un bon design est sa performance pour l'utilisateur. Si vous écrivez un roman qui ennuie tout le monde, ou une chaise horriblement inconfortable, alors vous avez fait du mauvais travail, point final. Ce n'est pas une défense de dire que le roman ou la chaise est conçu selon les principes théoriques les plus avancés.

Et pourtant, faire ce qui fonctionne pour l'utilisateur ne signifie pas simplement faire ce que l'utilisateur vous dit de faire. Les utilisateurs ne connaissent pas toutes les options, et se trompent souvent sur ce qu'ils veulent réellement.

La réponse au paradoxe, je pense, est que vous devez concevoir pour l'utilisateur, mais vous devez concevoir ce dont l'utilisateur a besoin, et non simplement ce qu'il dit vouloir. C'est un peu comme être médecin. Vous ne pouvez pas vous contenter de traiter les symptômes d'un patient. Lorsqu'un patient vous décrit ses symptômes, vous devez déterminer ce qui ne va pas réellement chez lui, et traiter cela.

Cette focalisation sur l'utilisateur est une sorte d'axiome dont découle la plupart des pratiques du bon design, et autour duquel la plupart des questions de design s'articulent.

Si un bon design doit répondre aux besoins de l'utilisateur, qui est l'utilisateur ? Quand je dis que le design doit être pour les utilisateurs, je ne veux pas dire qu'un bon design vise une sorte de plus petit dénominateur commun. Vous pouvez choisir n'importe quel groupe d'utilisateurs que vous voulez. Si vous concevez un outil, par exemple, vous pouvez le concevoir pour n'importe qui, des débutants aux experts, et ce qui est un bon design pour un groupe pourrait être mauvais pour un autre. Le fait est que vous devez choisir un groupe d'utilisateurs. Je ne pense pas que l'on puisse même parler de bon ou de mauvais design sans référence à un utilisateur visé.

Vous avez plus de chances d'obtenir un bon design si les utilisateurs visés incluent le designer lui-même. Lorsque vous concevez quelque chose pour un groupe qui ne vous inclut pas, cela tend à être pour des personnes que vous considérez moins sophistiquées que vous, et non plus sophistiquées.

C'est un problème, car regarder l'utilisateur de haut, aussi bienveillant que cela puisse paraître, semble inévitablement corrompre le designer. Je soupçonne que très peu de projets de logements sociaux aux États-Unis ont été conçus par des architectes qui s'attendaient à y vivre. On peut observer la même chose dans les langages de programmation. C, Lisp et Smalltalk ont été créés pour être utilisés par leurs propres designers. Cobol, Ada et Java ont été créés pour être utilisés par d'autres personnes.

Si vous pensez concevoir quelque chose pour des idiots, il y a de fortes chances que vous ne conceviez rien de bon, même pour des idiots.

Même si vous concevez quelque chose pour les utilisateurs les plus sophistiqués, vous concevez toujours pour des humains. C'est différent dans la recherche. En mathématiques, vous ne choisissez pas des abstractions parce qu'elles sont faciles à comprendre pour les humains ; vous choisissez celles qui rendent la preuve plus courte. Je pense que c'est vrai pour les sciences en général. Les idées scientifiques ne sont pas censées être ergonomiques.

Dans les arts, les choses sont très différentes. Le design est entièrement centré sur les gens. Le corps humain est une chose étrange, mais lorsque vous concevez une chaise, c'est pour cela que vous la concevez, et il n'y a pas moyen de contourner cela. Tous les arts doivent s'adapter aux intérêts et aux limitations des humains. En peinture, par exemple, toutes choses égales par ailleurs, une peinture avec des personnes sera plus intéressante qu'une sans. Ce n'est pas un simple accident de l'histoire si les grandes peintures de la Renaissance sont toutes remplies de personnes. Si elles ne l'avaient pas été, la peinture en tant que médium n'aurait pas le prestige qu'elle a.

Qu'on le veuille ou non, les langages de programmation sont aussi pour les gens, et je soupçonne que le cerveau humain est tout aussi irrégulier et idiosyncratique que le corps humain. Certaines idées sont faciles à saisir pour les gens et d'autres non. Par exemple, nous semblons avoir une capacité très limitée à gérer les détails. C'est ce fait qui rend les langages de programmation une bonne idée en premier lieu ; si nous pouvions gérer les détails, nous pourrions simplement programmer en langage machine.

N'oubliez pas non plus que les langages ne sont pas principalement une forme pour les programmes finis, mais quelque chose dans lequel les programmes doivent être développés. N'importe qui dans les arts pourrait vous dire que vous pourriez vouloir des médiums différents pour les deux situations. Le marbre, par exemple, est un médium agréable et durable pour les idées finies, mais désespérément inflexible pour développer de nouvelles idées.

Un programme, comme une preuve, est une version élaguée d'un arbre qui, par le passé, a eu des faux départs se ramifiant partout. Ainsi, le test d'un langage n'est pas simplement l'apparence nette du programme fini, mais la propreté du chemin menant au programme fini. Un choix de design qui vous donne des programmes finis élégants peut ne pas vous donner un processus de design élégant. Par exemple, j'ai écrit quelques macros définissant des macros pleines de guillemets inversés imbriqués qui ressemblent maintenant à de petits bijoux, mais les écrire a pris des heures d'essais et erreurs des plus laids, et franchement, je ne suis toujours pas entièrement sûr qu'elles soient correctes.

Nous agissons souvent comme si le test d'un langage était l'apparence des programmes finis. Cela semble si convaincant lorsque vous voyez le même programme écrit dans deux langages, et qu'une version est beaucoup plus courte. Lorsque vous abordez le problème sous l'angle des arts, vous êtes moins susceptible de dépendre de ce genre de test. Vous ne voulez pas vous retrouver avec un langage de programmation comme le marbre.

Par exemple, c'est un énorme avantage dans le développement de logiciels d'avoir un toplevel interactif, ce qu'en Lisp on appelle une boucle read-eval-print. Et quand vous en avez un, cela a des effets réels sur le design du langage. Cela ne fonctionnerait pas bien pour un langage où vous devez déclarer les variables avant de les utiliser, par exemple. Lorsque vous tapez simplement des expressions dans le toplevel, vous voulez pouvoir affecter une valeur à x et ensuite commencer à faire des choses avec x. Vous ne voulez pas avoir à déclarer le type de x d'abord. Vous pouvez contester l'une ou l'autre des prémisses, mais si un langage doit avoir un toplevel pour être pratique, et que les déclarations de type obligatoires sont incompatibles avec un toplevel, alors aucun langage qui rend les déclarations de type obligatoires ne pourrait être pratique à programmer.

En pratique, pour obtenir un bon design, vous devez vous rapprocher, et rester proche, de vos utilisateurs. Vous devez constamment calibrer vos idées sur des utilisateurs réels, surtout au début. L'une des raisons pour lesquelles les romans de Jane Austen sont si bons est qu'elle les lisait à voix haute à sa famille. C'est pourquoi elle ne sombre jamais dans des descriptions de paysages artistiquement auto-indulgentes, ou des philosophisations prétentieuses. (La philosophie est là, mais elle est tissée dans l'histoire au lieu d'y être collée comme une étiquette.) Si vous ouvrez un roman « littéraire » moyen et imaginez le lire à voix haute à vos amis comme quelque chose que vous auriez écrit, vous ressentirez trop vivement à quel point ce genre de chose est une imposition pour le lecteur.

Dans le monde du logiciel, cette idée est connue sous le nom de Worse is Better. En fait, plusieurs idées sont mélangées dans le concept de Worse is Better, c'est pourquoi les gens se disputent encore pour savoir si le pire est réellement meilleur ou non. Mais l'une des idées principales de ce mélange est que si vous construisez quelque chose de nouveau, vous devriez présenter un prototype aux utilisateurs dès que possible.

L'approche alternative pourrait être appelée la stratégie du Hail Mary. Au lieu de sortir rapidement un prototype et de le raffiner progressivement, vous essayez de créer le produit complet et fini en une seule longue passe de touchdown. Autant que je sache, c'est une recette pour le désastre. D'innombrables startups se sont détruites de cette manière pendant la bulle Internet. Je n'ai jamais entendu parler d'un cas où cela a fonctionné.

Ce que les gens en dehors du monde du logiciel ne réalisent peut-être pas, c'est que le Worse is Better se retrouve dans tous les arts. En dessin, par exemple, l'idée a été découverte pendant la Renaissance. Aujourd'hui, presque tous les professeurs de dessin vous diront que la bonne façon d'obtenir un dessin précis n'est pas de travailler lentement autour du contour d'un objet, car les erreurs s'accumuleront et vous constaterez à la fin que les lignes ne se rejoignent pas. Au lieu de cela, vous devriez tracer quelques lignes rapides à peu près au bon endroit, puis affiner progressivement cette esquisse initiale.

Dans la plupart des domaines, les prototypes ont traditionnellement été fabriqués à partir de matériaux différents. Les caractères à graver dans le métal étaient initialement conçus au pinceau sur papier. Les statues à couler en bronze étaient modelées en cire. Les motifs à broder sur les tapisseries étaient dessinés sur papier à l'encre de Chine. Les bâtiments à construire en pierre étaient testés à plus petite échelle en bois.

Ce qui a rendu la peinture à l'huile si excitante, lorsqu'elle est devenue populaire au XVe siècle, c'est que l'on pouvait réellement réaliser l'œuvre finie à partir du prototype. On pouvait faire un dessin préliminaire si on le souhaitait, mais on n'y était pas contraint ; on pouvait travailler tous les détails, et même apporter des changements majeurs, au fur et à mesure que l'on terminait la peinture.

Vous pouvez faire cela aussi en logiciel. Un prototype n'a pas besoin d'être juste un modèle ; vous pouvez le raffiner pour en faire le produit fini. Je pense que vous devriez toujours faire cela quand vous le pouvez. Cela vous permet de tirer parti des nouvelles idées que vous avez en cours de route. Mais peut-être plus important encore, c'est bon pour le moral.

Le moral est essentiel en design. Je suis surpris que les gens n'en parlent pas davantage. L'un de mes premiers professeurs de dessin m'a dit : si vous vous ennuyez en dessinant quelque chose, le dessin aura l'air ennuyeux. Par exemple, supposez que vous deviez dessiner un bâtiment, et que vous décidiez de dessiner chaque brique individuellement. Vous pouvez le faire si vous voulez, mais si vous vous ennuyez à mi-chemin et commencez à faire les briques mécaniquement au lieu d'observer chacune d'elles, le dessin aura l'air pire que si vous aviez simplement suggéré les briques.

Construire quelque chose en raffinant progressivement un prototype est bon pour le moral car cela vous maintient engagé. En logiciel, ma règle est : ayez toujours du code fonctionnel. Si vous écrivez quelque chose que vous pourrez tester en une heure, alors vous avez la perspective d'une récompense immédiate pour vous motiver. Il en va de même dans les arts, et particulièrement en peinture à l'huile. La plupart des peintres commencent par une esquisse floue et la raffinent progressivement. Si vous travaillez de cette manière, alors en principe vous n'avez jamais à terminer la journée avec quelque chose qui semble réellement inachevé. En effet, il y a même un dicton parmi les peintres : « Un tableau n'est jamais fini, on arrête juste de travailler dessus. » Cette idée sera familière à quiconque a travaillé sur des logiciels.

Le moral est une autre raison pour laquelle il est difficile de concevoir quelque chose pour un utilisateur non sophistiqué. Il est difficile de rester intéressé par quelque chose que vous n'aimez pas vous-même. Pour faire quelque chose de bien, vous devez penser : « wow, c'est vraiment génial », et non « quelle merde ; ces idiots vont adorer. »

Le design signifie créer des choses pour les humains. Mais il n'y a pas que l'utilisateur qui est humain. Le designer l'est aussi.

Remarquez que pendant tout ce temps, j'ai parlé « du designer ». Le design doit généralement être sous le contrôle d'une seule personne pour être bon. Et pourtant, il semble possible que plusieurs personnes collaborent sur un projet de recherche. Cela me semble être l'une des différences les plus intéressantes entre la recherche et le design.

Il y a eu des exemples célèbres de collaboration dans les arts, mais la plupart d'entre eux semblent avoir été des cas de liaison moléculaire plutôt que de fusion nucléaire. Dans un opéra, il est courant qu'une personne écrive le livret et une autre la musique. Et pendant la Renaissance, des compagnons d'Europe du Nord étaient souvent employés pour réaliser les paysages en arrière-plan des peintures italiennes. Mais ce ne sont pas de véritables collaborations. Ce sont plutôt des exemples du « good fences make good neighbors » de Robert Frost. Vous pouvez assembler des exemples de bon design, mais au sein de chaque projet individuel, une seule personne doit être aux commandes.

Je ne dis pas qu'un bon design exige qu'une seule personne pense à tout. Il n'y a rien de plus précieux que le conseil de quelqu'un dont vous faites confiance au jugement. Mais une fois les discussions terminées, la décision sur ce qu'il faut faire doit revenir à une seule personne.

Pourquoi la recherche peut-elle être menée par des collaborateurs et le design non ? C'est une question intéressante. Je ne connais pas la réponse. Peut-être que si le design et la recherche convergent, la meilleure recherche est aussi un bon design, et ne peut en fait pas être réalisée par des collaborateurs. Beaucoup des scientifiques les plus célèbres semblent avoir travaillé seuls. Mais je n'en sais pas assez pour dire s'il y a un schéma ici. Il se pourrait simplement que de nombreux scientifiques célèbres aient travaillé à une époque où la collaboration était moins courante.

Quelle que soit l'histoire dans les sciences, la véritable collaboration semble être d'une rareté extrême dans les arts. Le design par comité est un synonyme de mauvais design. Pourquoi en est-il ainsi ? Y a-t-il un moyen de dépasser cette limitation ?

Je suis enclin à penser que non – qu'un bon design exige un dictateur. L'une des raisons est qu'un bon design doit être d'un seul tenant. Le design n'est pas seulement pour les humains, mais pour des humains individuels. Si un design représente une idée qui tient dans la tête d'une personne, alors l'idée tiendra aussi dans la tête de l'utilisateur.

Articles liés :