DESIGN E PESQUISA

Janeiro de 2003

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

Visitantes deste país costumam se surpreender 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 direta para ela. Mas acho que finalmente resolvi o problema. Agora, quando alguém me pergunta o que eu faço, olho diretamente nos olhos deles e digo "Estou projetando um novo dialeto de Lisp." Recomendo essa resposta a qualquer pessoa que não goste de ser questionada sobre o que faz. A conversa mudará imediatamente para outros tópicos.

Não me considero pesquisador de linguagens de programação. Estou apenas projetando uma, da mesma forma que alguém pode projetar um prédio ou uma cadeira ou uma nova fonte. Não estou tentando descobrir nada novo. Eu 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. O design não precisa ser novo, mas precisa ser bom. A pesquisa não precisa ser boa, mas precisa 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 realmente valem a pena resolver. Então, em última análise, estamos mirando no mesmo destino, apenas nos aproximando dele por direções diferentes.

O que vou falar hoje é como seu alvo parece de costas. 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ê se concentra mais no usuário. O design começa perguntando: para quem é isso e do que eles precisam? 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 uma espécie de cozinheiro de pedidos rápidos, fazendo o que o cliente lhe diz para fazer. 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 apenas fazem exatamente o que os clientes lhes dizem.

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ê fizer um romance que entedia todo mundo, ou uma cadeira que é horrivelmente desconfortável de sentar, então você fez um mal trabalho, ponto final. Não é uma defesa dizer que o romance ou a cadeira é projetado 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 lhe diz. Os usuários não sabem quais são todas as opções e muitas vezes estão enganados sobre o que realmente querem.

A resposta para o paradoxo, 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 médico. Você não pode simplesmente tratar os sintomas de um paciente. Quando um paciente lhe diz seus sintomas, você tem que descobrir o que está realmente errado com ele e tratar isso.

Esse foco no usuário é uma espécie de axioma do qual a maior parte da prática de um bom design pode ser derivada e em torno do qual a maioria dos designs questões se concentram.

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

Você tem maior probabilidade de obter 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ê, ele tende a ser para pessoas que você considera menos sofisticadas do que você, não mais sofisticadas.

Isso é um problema, porque olhar para baixo para 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 viver neles. Você pode ver a mesma coisa em linguagens de programação. C, Lisp e Smalltalk foram criados para seus próprios designers usarem. Cobol, Ada e Java foram criados para outras pessoas usarem.

Se você acha que está projetando algo para idiotas, as chances são de que você não está projetando algo bom, nem mesmo para idiotas.

Mesmo que você esteja projetando algo para os usuários mais sofisticados, no entanto, você ainda está projetando para humanos. É diferente na pesquisa. Em matemática, você não escolhe abstrações porque elas são fáceis para os humanos entenderem; você escolhe o que torna o prova mais curta. 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. O 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 evitar. Todas as artes têm que agradar aos interesses e limitações dos humanos. Na pintura, por exemplo, todas as outras coisas sendo iguais, uma pintura com pessoas nela será mais interessante do que uma sem. Não é apenas um acidente da história que as grandes pinturas do Renascimento estão todas cheias de pessoas. Se não tivessem sido, a pintura como meio não teria o prestígio que tem.

Goste ou não, as 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, parecemos ter uma capacidade muito limitada de lidar com detalhes. É esse fato que torna as linguagens de programação uma boa ideia em primeiro lugar; se nós pudéssemos lidar com os detalhes, poderíamos simplesmente programar em máquina linguagem.

Lembre-se também de que as linguagens não são primariamente uma forma para programas acabados, mas algo que os programas têm que ser desenvolvidos. Qualquer pessoa nas artes poderia lhe dizer que você pode querer meios diferentes para o duas situações. O mármore, por exemplo, é um meio bonito e durável para ideias acabadas, mas um meio incrivelmente 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 o quão limpo o programa acabado parece nela, mas o quão limpo foi o caminho para o programa acabado. Uma escolha de design que lhe dá programas acabados elegantes pode não lhe dar um processo de design elegante. Por exemplo, escrevi algumas macros de definição de macro cheias de aninhadas backquotes que agora parecem pequenas joias, mas escrevê-las levou horas do mais feio teste e erro, e, francamente, ainda estou não tenho certeza se estão corretas.

Muitas vezes agimos como se o teste de uma linguagem fosse o quão bom os programas acabados 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 do artes, você tem menos probabilidade de depender desse tipo de teste. Você não quer acabar com uma programação linguagem como mármore.

Por exemplo, é uma grande vitória no desenvolvimento de software para ter um toplevel interativo, o que em Lisp é chamado de loop de leitura-avaliação-impressão. E quando você tem um, isso tem efeitos reais no design da linguagem. Não seria funcionar bem para uma linguagem em que 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 aos seus usuários. Você tem que calibrar suas ideias em reais usuários constantemente, especialmente no início. 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 mergulha em auto-indulgentemente artístico descrições de paisagens, ou filosofias pretensiosas. (A filosofia está lá, mas é entrelaçada na história em vez de ser colada nela como um rótulo.) Se você abrir um romance "literário" médio e imaginar lendo-o em voz alta para seus amigos como algo que você escreveu, você sentirá com muita intensidade o quão impositiva esse tipo de coisa é para o leitor.

No mundo do software, essa ideia é conhecida como Worse is Better. Na verdade, existem várias ideias misturadas no conceito de Worse is Better, o que explica por que as pessoas ainda estão discutindo sobre se pior é realmente melhor ou não. Mas uma das principais ideias nessa mistura é que, se você está construindo algo novo, você deve obter 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 gradualmente refinando ele, você tenta criar o produto completo, acabado, em um longo passe de touchdown. Até onde eu sei, este é um 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 Worse is Better é encontrado em todas as artes. No desenho, por exemplo, a ideia foi descoberta durante o Renascimento. Agora quase todos os professores de desenho dirão que a maneira certa de obter um desenho preciso não é trabalhar lentamente ao redor do contorno de um objeto, porque os erros serão acumulados e você descobrirá no final que as linhas não se encontram. Em vez disso, você deve desenhar algumas linhas rápidas no lugar certo, e então gradualmente refinar esse esboço inicial.

Na maioria dos campos, protótipos tradicionalmente eram feitos de materiais diferentes. Fontes a serem cortadas em metal foram inicialmente projetadas com um pincel em 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 aquarela. Edifícios para serem construídos em pedra foram testados em menor escala em madeira.

O que tornou a tinta a óleo tão emocionante, quando tornou-se popular no século XV, foi que você poderia realmente fazer a obra acabada a partir do protótipo. Você poderia fazer um desenho preliminar se quisesse, mas você não estava preso a ele; você poderia trabalhar todos os detalhes, e até fazer mudanças importantes, enquanto 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 no produto final. Acho que você sempre deve fazer isso quando puder. Isso permite que você tire vantagem de novas ideias que você tem ao longo do caminho. Mas talvez ainda mais importante, é bom para o moral.

O moral é fundamental no design. Estou surpreso que as pessoas não falem mais sobre isso. Um dos meus primeiros professores de desenho me disse: se você estiver entediado quando estiver desenhando algo, o desenho ficará entediante. Por exemplo, suponha que você tenha que desenhar um prédio e você decida desenhar cada tijolo individualmente. Você pode fazer isso se quiser, mas se você 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 simplesmente sugerido os tijolos.

Construir algo refinando gradualmente um protótipo é bom para o moral porque o mantém engajado. No software, meu regra é: sempre tenha código funcionando. Se você está escrevendo algo que você 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 gradualmente o refina. Se você trabalhar dessa forma, então em princípio você nunca precisa terminar o dia com algo que realmente parece inacabado. De fato, existe até um ditado entre os pintores: "Uma pintura nunca está terminada, você apenas para de trabalhar nela." Essa ideia será familiar a qualquer pessoa que tenha trabalhado com software.

O moral é outra razão pela qual é difícil projetar algo para um usuário não sofisticado. É difícil manter o interesse em algo que você não gosta. Para fazer algo bom, você tem que estar pensando: "Uau, isso é realmente ótimo", não "Que porcaria; esses tolos vão adorar."

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

Observe que o tempo todo 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 para várias pessoas colaborar em um projeto de pesquisa. Isso parece para mim 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 escreva a música. E durante o Renascimento, aprendizes do norte da Europa eram frequentemente empregados para fazer as paisagens no fundos de pinturas italianas. Mas essas não são verdadeiras colaborações. Eles são mais como exemplos de Robert Frost's "boas cercas fazem bons vizinhos". Você pode colar instâncias de bom design juntas, mas dentro de cada projeto individual, uma pessoa tem que estar no controle.

Não estou dizendo que um bom design exige 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? Esta é uma pergunta interessante. Eu não sei a resposta. Talvez, se o design e a pesquisa convergirem, a melhor pesquisa também é bom design, e na verdade não pode ser feito 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.

Qualquer que seja a história nas ciências, a verdadeira colaboração parece ser incrivelmente rara nas artes. Design por comitê é um sinônimo de mau design. Por que isso é assim? Existe alguma maneira de superar essa limitação?

Estou inclinado a pensar que não - que um bom design exige um ditador. Uma razão é que um bom design tem que ser tudo de uma peça. O 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 do usuário cabeça também.