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 muitas vezes ficam surpresos 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 simples para ela. Mas acho que finalmente resolvi o problema. Agora, quando alguém me pergunta o que eu faço, olho-os diretamente nos olhos e digo "Estou projetando um novo dialeto de Lisp". Recomendo essa resposta a qualquer um que não goste de ser perguntado o que faz. A conversa se voltará imediatamente para outros tópicos.

Não me considero estar fazendo pesquisa sobre linguagens de programação. Estou apenas projetando uma, da mesma forma que alguém poderia projetar um edifício, uma cadeira ou uma nova fonte. Não estou tentando descobrir nada de novo. Eu só quero criar uma linguagem que seja boa de 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 antecessores usando novas ideias, e a melhor pesquisa resolve problemas que não são apenas novos, mas realmente vale a pena resolver. Então, no final, estamos visando o mesmo destino, apenas abordando-o de diferentes direções.

O que vou falar hoje é sobre como seu alvo parece por trás. O que você faz de maneira diferente quando trata as 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 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 uma espécie de cozinheiro de plantão, fazendo o que o cliente mandar. Isso varia de campo para campo nas artes, mas não acho que haja nenhum campo em que o melhor trabalho seja feito pelas pessoas que simplesmente fazem exatamente o que os clientes mandam.

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

E, no entanto, fazer o que funciona para o usuário não significa simplesmente fazer o que o usuário manda. Os usuários não sabem quais são todas as opções e muitas vezes se enganam sobre o que realmente querem.

A resposta para o paradoxo, acho eu, é que você tem que projetar para o usuário, mas 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 disso.

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

Se o 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 o 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, pode projetá-la para qualquer um, desde iniciantes até especialistas, e o que é bom design para um grupo pode ser ruim para outro. O ponto é que você tem que escolher algum grupo de usuários. Não acho que você possa nem mesmo falar sobre design bom ou ruim, exceto com referência a algum usuário pretendido.

Você provavelmente 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 o inclui, tende a ser para pessoas que você considera menos sofisticadas do que você, e não mais sofisticadas.

Esse é 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 de habitação 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 criados para que seus próprios designers os usassem. Cobol, Ada e Java foram criados para que outras pessoas os usassem.

Se você acha que está projetando algo para idiotas, a probabilidade é de que você não esteja projetando algo bom, nem mesmo para idiotas.

Mesmo que você esteja projetando algo para os usuários mais sofisticados, ainda assim você está projetando para seres humanos. É diferente na pesquisa. Em matemática, você não escolhe abstrações porque são fáceis de entender para os seres humanos; você escolhe aquelas que tornam a prova mais curta. Acho que isso é verdade para as ciências em geral. As ideias científicas não se destinam a ser ergonômicas.

No campo das artes, as coisas são muito diferentes. O design é tudo sobre as 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 se render aos interesses e limitações dos seres 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 é meramente um acidente da história que as grandes pinturas do Renascimento estejam todas cheias de pessoas. Se não fosse assim, a pintura como meio não teria o prestígio que tem.

Gostemos ou não, as linguagens de programação também são para as 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 principalmente 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 mármore, por exemplo, é um meio agradável e durável para ideias finalizadas, mas uma opção terrivelmente 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 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 foi o caminho para o programa finalizado. 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 macros cheias de aspas aninhadas que agora parecem pequenas joias, mas escrevê-las levou horas do mais feio teste e erro, e francamente, ainda não tenho certeza de que 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 na direção das artes, você é menos propenso a depender desse tipo de teste. Você não quer acabar com uma linguagem de programação como o mármore.

Por exemplo, é um enorme ganho no desenvolvimento de software ter um toplevel interativo, o que em Lisp é chamado de um loop de leitura-avaliação-impressão. E quando você tem um, isso tem efeitos reais no design da linguagem. Não funcionaria 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 poder definir x para algum valor e então começar a fazer coisas com x. Você não quer ter que declarar o tipo de x primeiro. Você pode discordar de qualquer um dos pressupostos, mas se uma linguagem precisa 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 torne as declarações de tipo obrigatórias poderia ser conveniente de programar.

Na prática, para obter um bom design, você precisa se aproximar e permanecer próximo aos seus usuários. Você precisa calibrar suas ideias em usuários reais 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 afunda em descrições artisticamente indulgentes de paisagens ou em filosofias pretenciosas. (A filosofia está lá, mas está tecida na história em vez de ser colada nela como um rótulo.) Se você abrir um romance "literário" médio e imaginar lê-lo em voz alta para seus amigos como algo que você escreveu, você sentirá com muita clareza o que é uma imposição desse tipo de coisa sobre 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, por isso as pessoas ainda estão discutindo se o pior é realmente melhor ou não. Mas uma das principais ideias nessa mistura é que, se você estiver construindo algo novo, deve colocar um protótipo diante 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 acabado em um único passe longo. Até onde eu sei, isso é uma receita para o desastre. Inúmeras startups se destruíram dessa maneira durante a bolha da Internet. Nunca ouvi falar de um caso em que isso tenha funcionado.

O que as pessoas fora do mundo do software podem não perceber é que o 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 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, em seguida, refinar gradualmente esse esboço inicial.

Na maioria dos campos, os protótipos tradicionalmente foram feitos de diferentes materiais. As fontes a serem cortadas em metal foram inicialmente projetadas com um pincel no papel. As estátuas a serem fundidas em bronze foram modeladas em cera. Os padrões a serem bordados em tapeçarias foram desenhados em papel com tinta lavada. Os edifícios a serem construídos em pedra foram 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 final a partir do protótipo. Você podia fazer um desenho preliminar se quisesse, mas não ficava preso a ele; você podia resolver todos os detalhes e até fazer mudanças importantes à medida que terminava a pintura.

Você pode fazer isso no 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ê aproveite os novos insights que você tem ao longo do caminho. Mas talvez ainda mais importante, é bom para a moral.

A 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ê se aborrecer ao desenhar algo, o desenho parecerá entediante. 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 você se aborrecer pela metade 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 a moral porque mantém você engajado. No software, minha regra é: sempre ter código funcional. Se você estiver 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 desfocado e o refina gradualmente. Se você trabalhar dessa maneira, em princípio você 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 com software.

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

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

Observe todo esse tempo em que tenho falado sobre "o designer". O design geralmente precisa estar sob o controle de uma única pessoa para ser bom. E, no entanto, parece ser possível que várias pessoas colaborem em um projeto de pesquisa. Essa parece ser 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 da Europa do Norte eram frequentemente empregados para fazer as paisagens nos fundos de pinturas italianas. Mas esses não são verdadeiras colaborações. Eles são mais como exemplos da "boa cerca faz bons vizinhos" de Robert Frost. Você pode juntar instâncias de bom design, 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 quem 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. Eu 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 tenham trabalhado quando a colaboração era menos comum.

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

Eu tenho a tendência de pensar que não há - que um bom design requer um ditador. Uma razão é que um bom design precisa ser todo de uma peça. O design não é apenas para os seres humanos, mas para indivíduos. Se um design representa uma ideia que cabe na cabeça de uma pessoa, então a ideia também caberá na cabeça do usuário.