DESIGN E PESQUISA

Janeiro de 2003

(Este artigo é derivado de uma palestra principal na reunião do NEPLS no outono de 2002.)

Os visitantes deste país geralmente se surpreendem ao descobrir que os americanos gostam de começar uma conversa perguntando "o que você faz?" Eu nunca gostei dessa pergunta. Raramente tive uma resposta clara para ela. Mas acho que finalmente resolvi o problema. Agora, quando alguém me pergunta o que eu faço, olho direto nos olhos e digo "Estou projetando um novo dialeto de Lisp ". Recomendo essa resposta a qualquer um que não goste de ser perguntado sobre o que faz. A conversa mudará imediatamente para outros tópicos.

Não me considero fazendo pesquisa sobre linguagens de programação. Estou apenas projetando uma, da mesma forma que alguém pode projetar um prédio, uma cadeira ou uma nova fonte. Não estou tentando descobrir nada novo. Só quero fazer uma linguagem que seja boa para programar. De certa forma, essa suposição torna a vida muito mais fácil.

A diferença entre design e pesquisa parece ser uma questão de novo versus bom. Design não precisa ser novo, mas tem que ser bom. Pesquisa não precisa ser boa, mas tem que ser nova. Acho que esses dois caminhos convergem no topo: o melhor design supera seus predecessores usando novas ideias, e a melhor pesquisa resolve problemas que não são apenas novos, mas que realmente valem a pena resolver. Então, no final das contas, estamos mirando no mesmo destino, apenas abordando-o de direções diferentes.

O que vou falar hoje é sobre como seu alvo se parece visto de trás. O que você faz de diferente quando trata linguagens de programação como um problema de design em vez de um tópico de pesquisa?

A maior diferença é que você foca mais no usuário. O design começa perguntando para quem é isso e o que eles precisam disso? Um bom arquiteto, por exemplo, não começa criando um design que ele então impõe aos usuários, mas estudando os usuários pretendidos e descobrindo o que eles precisam.

Observe que eu disse "o que eles precisam", não "o que eles querem". Não quero dar a impressão de que trabalhar como designer significa trabalhar como um tipo de cozinheiro de fast food, fazendo o que o cliente manda. Isso varia de campo para campo nas artes, mas não acho que haja nenhum campo em que o melhor trabalho seja feito por pessoas que fazem exatamente o que os clientes mandam.

O cliente está sempre certo no sentido de que a medida de um bom design é o quão bem ele funciona para o usuário. Se você faz um romance que entedia todo mundo, ou uma cadeira que é terrivelmente desconfortável para sentar, então você fez um trabalho ruim, ponto final. Não é defesa dizer que o romance ou a cadeira são projetados de acordo com os princípios teóricos mais avançados.

E ainda assim, fazer o que funciona para o usuário não significa simplesmente fazer o que o usuário diz para você fazer. Os usuários não sabem quais são todas as escolhas e frequentemente estão enganados sobre o que realmente querem.

A resposta para o paradoxo, eu acho, é que você tem que projetar para o usuário, mas você tem que projetar o que o usuário precisa, não simplesmente o que ele diz que quer. É muito parecido com ser um médico. Você não pode simplesmente tratar os sintomas de um paciente. Quando um paciente lhe conta seus sintomas, você tem que descobrir o que realmente está errado com ele, e tratar isso.

Esse foco no usuário é um tipo de axioma do qual a maior parte da prática de um bom design pode ser derivada e em torno do qual a maioria das questões de design se concentra.

Se um bom design deve fazer o que o usuário precisa, quem é o usuário? Quando digo que o design deve ser para os usuários, não quero dizer que um bom design visa algum tipo de menor denominador comum. Você pode escolher qualquer grupo de usuários que quiser. Se você está projetando uma ferramenta, por exemplo, você pode projetá-la para qualquer um, de iniciantes a especialistas, e o que é um bom design para um grupo pode ser ruim para outro. O ponto é que você tem que escolher algum grupo de usuários. Eu não acho que você pode sequer falar sobre um bom ou mau design, exceto com referência a algum usuário pretendido.

É mais provável que você obtenha um bom design se os usuários pretendidos incluírem o próprio designer. Quando você projeta algo para um grupo que não inclui você, tende a ser para pessoas que você considera menos sofisticadas do que você, não mais sofisticadas.

Isso é um problema, porque menosprezar o usuário, por mais benevolente que seja, parece inevitavelmente corromper o designer. Suspeito que muito poucos projetos habitacionais nos EUA foram projetados por arquitetos que esperavam morar neles. Você pode ver a mesma coisa em linguagens de programação. C, Lisp e Smalltalk foram criadas para seus próprios designers usarem. Cobol, Ada e Java foram criadas para outras pessoas usarem.

Se você acha que está projetando algo para idiotas, é provável que não esteja projetando algo bom, mesmo para idiotas.

Mesmo se você estiver projetando algo para os usuários mais sofisticados, você ainda está projetando para humanos. É diferente em pesquisa. Em matemática, você não escolhe abstrações porque elas são fáceis para humanos entenderem; você escolhe qualquer uma que torne a prova mais curta. Eu acho que isso é verdade para as ciências em geral. Ideias científicas não são feitas para serem ergonômicas.

Nas artes, as coisas são muito diferentes. Design é tudo sobre pessoas. O corpo humano é uma coisa estranha, mas quando você está projetando uma cadeira, é para isso que você está projetando, e não há como contornar isso. Todas as artes têm que atender aos interesses e limitações dos humanos. Na pintura, por exemplo, todas as outras coisas sendo iguais, uma pintura com pessoas será mais interessante do que uma sem. Não é meramente um acidente da história que as grandes pinturas do Renascimento sejam todas cheias de pessoas. Se não fossem, a pintura como meio não teria o prestígio que tem.

Goste ou não, linguagens de programação também são para pessoas, e suspeito que o cérebro humano seja tão irregular e idiossincrático quanto o corpo humano. Algumas ideias são fáceis para as pessoas entenderem e outras não. Por exemplo, parece que temos uma capacidade muito limitada para lidar com detalhes. É esse fato que torna as linguagens de programação uma boa ideia em primeiro lugar; se pudéssemos lidar com os detalhes, poderíamos simplesmente programar em linguagem de máquina.

Lembre-se também de que as linguagens não são primariamente uma forma para programas finalizados, mas algo em que os programas têm que ser desenvolvidos. Qualquer pessoa nas artes poderia lhe dizer que você pode querer diferentes meios para as duas situações. O Marble, por exemplo, é um meio bom e durável para ideias finalizadas, mas irremediavelmente inflexível para desenvolver novas ideias.

Um programa, como uma prova, é uma versão podada de uma árvore que no passado teve falsos começos ramificando-se por toda parte. Então o teste de uma linguagem não é simplesmente quão limpo o programa finalizado parece nela, mas quão limpo o caminho para o programa finalizado era. Uma escolha de design que lhe dá programas finalizados elegantes pode não lhe dar um processo de design elegante. Por exemplo, eu escrevi algumas macros definidoras de macro cheias de crases aninhadas que agora parecem pequenas joias, mas escrevê-las levou horas da mais feia tentativa e erro, e francamente, ainda não tenho certeza se elas estão corretas.

Muitas vezes agimos como se o teste de uma linguagem fosse quão bons os programas finalizados parecem nela. Parece tão convincente quando você vê o mesmo programa escrito em duas linguagens, e uma versão é muito mais curta. Quando você aborda o problema da direção das artes, é menos provável que você dependa desse tipo de teste. Você não quer acabar com uma linguagem de programação como o Marble.

Por exemplo, é uma grande vitória no desenvolvimento de software ter um toplevel interativo, o que em Lisp é chamado de loop read-eval-print. E quando você tem um, isso tem efeitos reais no design da linguagem. Não funcionaria bem para uma linguagem onde você tem que declarar variáveis antes de usá-las, por exemplo. Quando você está apenas digitando expressões no toplevel, você quer ser capaz de definir x para algum valor e então começar a fazer coisas para x. Você não quer ter que declarar o tipo de x primeiro. Você pode contestar qualquer uma das premissas, mas se uma linguagem tem que ter um toplevel para ser conveniente, e declarações de tipo obrigatórias são incompatíveis com um toplevel, então nenhuma linguagem que torna as declarações de tipo obrigatórias poderia ser conveniente para programar.

Na prática, para obter um bom design, você tem que se aproximar, e permanecer próximo, dos seus usuários. Você tem que calibrar suas ideias em usuários reais constantemente, especialmente no começo. Uma das razões pelas quais os romances de Jane Austen são tão bons é que ela os lia em voz alta para sua família. É por isso que ela nunca se afunda em descrições artísticas autoindulgentes de paisagens, ou em filosofias pretensiosas. (A filosofia está lá, mas está entrelaçada na história em vez de ser colada nela como um rótulo.) Se você abrir um romance "literário" comum e imaginar lê-lo em voz alta para seus amigos como algo que você escreveu, você sentirá muito profundamente a imposição que esse tipo de coisa é sobre o leitor.

No mundo do software, essa ideia é conhecida como Pior é Melhor. Na verdade, há várias ideias misturadas no conceito de Pior é Melhor, e é por isso que as pessoas ainda discutem se pior é realmente melhor ou não. Mas uma das principais ideias nessa mistura é que, se você está construindo algo novo, deve colocar um protótipo na frente dos usuários o mais rápido possível.

A abordagem alternativa pode ser chamada de estratégia Hail Mary. Em vez de obter um protótipo rapidamente e refiná-lo gradualmente, você tenta criar o produto completo e finalizado em um longo passe de touchdown. Até onde eu sei, esta é uma receita para o desastre. Inúmeras startups se destruíram dessa forma durante a bolha da Internet. Nunca ouvi falar de um caso em que funcionou.

O que as pessoas de fora do mundo do software podem não perceber é que o Pior é Melhor é encontrado em todas as artes. No desenho, por exemplo, a ideia foi descoberta durante o Renascimento. Agora, quase todo professor de desenho dirá que a maneira certa de obter um desenho preciso não é trabalhar lentamente ao redor do contorno de um objeto, porque os erros se acumularão e você descobrirá no final que as linhas não se encontram. Em vez disso, você deve desenhar algumas linhas rápidas aproximadamente no lugar certo e, então, refinar gradualmente esse esboço inicial.

Na maioria dos campos, os protótipos tradicionalmente eram feitos de materiais diferentes. Tipos de letra a serem cortados em metal eram inicialmente projetados com um pincel sobre papel. Estátuas a serem fundidas em bronze eram modeladas em cera. Padrões a serem bordados em tapeçarias eram desenhados em papel com tinta. Edifícios a serem construídos de pedra eram testados em uma escala menor em madeira.

O que tornou a tinta a óleo tão emocionante, quando se tornou popular no século XV, foi que você podia realmente fazer o trabalho finalizado a partir do protótipo. Você podia fazer um desenho preliminar se quisesse, mas não era obrigado a ele; você podia trabalhar em todos os detalhes e até mesmo fazer grandes mudanças, conforme terminava a pintura.

Você pode fazer isso em software também. Um protótipo não precisa ser apenas um modelo; você pode refiná-lo para o produto final. Acho que você deve sempre fazer isso quando puder. Isso permite que você aproveite novos insights que você tem ao longo do caminho. Mas talvez ainda mais importante, é bom para o moral.

Moral é a chave no design. Estou surpreso que as pessoas não falem mais sobre isso. Um dos meus primeiros professores de desenho me disse: se você está entediado quando está desenhando algo, o desenho parecerá chato. Por exemplo, suponha que você tenha que desenhar um prédio e decida desenhar cada tijolo individualmente. Você pode fazer isso se quiser, mas se ficar entediado no meio do caminho e começar a fazer os tijolos mecanicamente em vez de observar cada um, o desenho ficará pior do que se você tivesse apenas sugerido os tijolos.

Construir algo refinando gradualmente um protótipo é bom para o moral porque mantém você engajado. Em software, minha regra é: sempre tenha um código funcional. Se você está escrevendo algo que poderá testar em uma hora, então você tem a perspectiva de uma recompensa imediata para motivá-lo. O mesmo é verdade nas artes, e particularmente na pintura a óleo. A maioria dos pintores começa com um esboço borrado e o refina gradualmente. Se você trabalha dessa forma, então, em princípio, nunca precisa terminar o dia com algo que realmente pareça inacabado. De fato, há até um ditado entre os pintores: "Uma pintura nunca está terminada, você simplesmente para de trabalhar nela." Essa ideia será familiar para qualquer um que tenha trabalhado em software.

Moral é outra razão pela qual é difícil projetar algo para um usuário não sofisticado. É difícil permanecer interessado em algo que você não gosta. Para fazer algo bom, você tem que pensar, "uau, isso é realmente ótimo", não "que merda; aqueles idiotas vão adorar".

Design significa fazer coisas para humanos. Mas não é só o usuário que é humano. O designer também é humano.

Observe que todo esse tempo eu tenho falado sobre "o designer". O design geralmente tem que estar sob o controle de uma única pessoa para ser bom. E ainda assim parece ser possível que várias pessoas colaborem em um projeto de pesquisa. Isso me parece uma das diferenças mais interessantes entre pesquisa e design.

Houve casos famosos de colaboração nas artes, mas a maioria deles parece ter sido casos de ligação molecular em vez de fusão nuclear. Em uma ópera, é comum que uma pessoa escreva o libreto e outra a música. E durante o Renascimento, jornaleiros do norte da Europa eram frequentemente contratados para fazer as paisagens nos fundos das pinturas italianas. Mas essas não são colaborações verdadeiras. Elas são mais como exemplos de "boas cercas fazem bons vizinhos" de Robert Frost. Você pode juntar exemplos de bom design, mas dentro de cada projeto individual, uma pessoa tem que estar no controle.

Não estou dizendo que um bom design requer que uma pessoa pense em tudo. Não há nada mais valioso do que o conselho de alguém em cujo julgamento você confia. Mas depois que a conversa termina, a decisão sobre o que fazer tem que ficar com uma pessoa.

Por que a pesquisa pode ser feita por colaboradores e o design não? Essa é uma pergunta interessante. Não sei a resposta. Talvez, se o design e a pesquisa convergirem, a melhor pesquisa também seja um bom design e, de fato, não possa ser feita por colaboradores. Muitos dos cientistas mais famosos parecem ter trabalhado sozinhos. Mas não sei o suficiente para dizer se há um padrão aqui. Pode ser simplesmente que muitos cientistas famosos trabalharam quando a colaboração era menos comum.

Seja qual for a história nas ciências, a colaboração verdadeira parece ser extremamente rara nas artes. Design por comitê é sinônimo de design ruim. Por que isso acontece? Existe alguma maneira de superar essa limitação?

Estou inclinado a pensar que não há-- que um bom design requer um ditador. Uma razão é que um bom design tem que ser todo de uma peça. Design não é apenas para humanos, mas para humanos individuais. Se um design representa uma ideia que se encaixa na cabeça de uma pessoa, então a ideia se encaixará na cabeça do usuário também.