BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Software, estética e artesanato: Como o Java, Lisp e o Agile moldam e refletem nossa cultura

Software, estética e artesanato: Como o Java, Lisp e o Agile moldam e refletem nossa cultura

Favoritos

Pontos Principais

  • A indústria de software usa várias metáforas da arquitetura e construção civil, como "arquitetos" e "engenheiros", mas raramente discute sobre a estética do software;

  • A estética não se preocupa apenas com a aparência das coisas e como elas nos agradam: pode mostrar também alguns aspectos fundamentais da sociedade e como são expressos, assim como John Ruskin fez com estilos arquitetônicos.

  • Assim como prédios, as ferramentas e metodologias usadas dizem muito sobre as pessoas que as usam e como elas vivem.

  • Podemos ampliar nossos debates sobre as vantagens e desvantagens das ferramentas e metodologias considerando a posição delas em relação ao trabalhador que as utiliza.

  • Quando considerado dessa maneira, os debates sobre linguagens de programação, Agile e experiência do usuário podem ser vistos de uma perspectiva diferente, onde o engenheiro e o usuário são colocados no centro.

A indústria de software está cheia de metáforas emprestadas dos setores de arquitetura e construção civil; nos chamamos de arquitetos e engenheiros, temos planejamentos e entregáveis, discutimos sobre metodologias de desenvolvimento, governança de projetos, cronograma, materiais de trabalho vs peças de trabalho, entre outros.

Embora exista uma grande quantidade de material sobre a estética da arquitetura, a estética do software raramente é discutida. Não estou falando sobre o design de sites ou aplicativos para dispositivos móveis, sobre os quais já existe várias discussões. Neste artigo, quero apresentar as teorias arquitetônicas do pensador vitoriano John Ruskin e aplicá-las ao software, a fim de mostrar as filosofias implícitas que aceitamos sem pensar, e a partir desse ponto de partida, questioná-las em relação às linguagens que usamos e ao movimento Agile.

Primeiro, vamos tentar entender a diferença entre dois conceitos básicos de arquitetura. Pode parecer simples, mas fica complicado bem rápido.

Gótico vs. Clássico - Uma rápida introdução

Se te pedissem para descrever os dois edifícios retratados abaixo em duas palavras, você poderia muito bem usar respectivamente as palavras "Clássico" e "Gótico".

Falando por cima, os edifícios clássicos parecem "elegantes", "ordenados" e "simples".

Enquanto os edifícios góticos parecem "ornados", "cheios" e "complicados".

A partir disso, não parece difícil chegar a uma definição formal da arquitetura clássica e gótica, certo?

Acontece que é surpreendentemente difícil. Por exemplo, poderíamos argumentar que a arquitetura clássica é simétrica e a gótica assimétrica. Porém, não é difícil encontrar exemplares de construções clássicas assimétricas, e muitos edifícios góticos simétricos. Podemos então dizer que arcos suspensos são uma característica central da arquitetura gótica, mas a Catedral de São Paulo em Londres tem arcobotantes, e esse edifício é universalmente visto como clássico (mais especificamente, barroco inglês) e assim por diante.

O fato é que não é preciso olhar para os detalhes para identificar se algo é gótico. É aqui que entra John Ruskin.

John Ruskin

John Ruskin foi um pensador influente da era vitoriana. Hoje, poucos sabem sobre ele, mas seus textos sobre arte foram muito populares na época. Além disso, foi influenciador de Tolstoy, Proust, Gandhi, do Labour Party e até do estado de bem-estar social.

Ao longo de seu trabalho em História da Arte, Ruskin argumentou que as formas externas da arquitetura não eram o que as tornavam góticas ou clássicas. Ele argumentou que as diferentes formas surgiram das sociedades que as criaram, e a qualidade da sociedade deveria ser a base sobre a qual a estética deveria ser julgada.

 

Gótico

Clássico

Orgânico

"Ideal"

Responsivo

Platônico

Diacrônico (muda com o tempo)

Sincrônico (uma "fotografia" fixa)

Individualista

Coletivo

Escala Humana

Escala Corporativa

Essa conversa sobre arquitetura, "orgânica" vs "ideal" e "responsiva" vs "platônica" pode circular entre os leitores que trabalham com tecnologia, pois está próxima da metáfora central do livro de Eric Raymond, A Catedral e o Bazar.

No livro, Raymond contrasta o modelo "top-down" (clássico) do design de uma catedral com o modelo "bottom-up" (gótico) do design de um bazar, usando-os como metáforas para tipos diferentes de desenvolvimento de software. Ele comenta principalmente sobre controles centralizados de contribuições e releases em comparação ao modelo distribuído de contribuição e releases estilo Linux. Aqui, gostaria de estender isso a qualquer tipo de tecnologia, física ou virtual, aberta ou fechada.

É interessante que Raymond chame o bazar de "revolucionário", já que Ruskin usou essa palavra para descrever qual tipo de estilo arquitetônico (ou "ornamento") preferia. Ele dividiu o ornamento em três categorias:
 

  1. Servil, na qual a execução ou força do trabalhador é inferior e está inteiramente sujeita ao das autoridades superiores;
  2. Constitucional, em que o poder executivo inferior é, até certo ponto, emancipado e independente, tendo vontade própria, ainda confessando sua inferioridade e sendo obediente aos seus superiores;
  3. Revolucionário, no qual não é admitido qualquer inferioridade.

Para Ruskin não importava se o objeto final era bonito de se ver ou se o deixava satisfeito. O que importava era a liberdade que o artesão tinha para fazê-lo. Quanto mais liberdade tinha, menor era o poder da autoridade superior, e mais humana era a sociedade que a produziu.

A análise e as percepções de Ruskin eram tão profundas quanto influentes. Não é coincidência, por exemplo, que os estados totalitários do século XX amem a arquitetura clássica (e sua herdeira natural, a arquitetura modernista). Nesses estados, todas as contribuições individuais precisavam ser subordinadas ao todo, refletindo a subordinação de todos os indivíduos à causa maior, e a arquitetura refletia isso. Estados mais democráticos tendiam a se afastar do extremo classicismo da Alemanha nazista ou da Rússia Stalinista. A diretiva recente do governo Trump sobre o estilo arquitetônico é um eco interessante dos gostos desses regimes.

Linguagens de programação

O que isso tem a ver com software? Assim como na arquitetura, não faltam debates sobre qual é a "melhor" linguagem de programação. Mas acho que nunca ouvi um debate sobre linguagens que fosse centralizado no tipo de cultura que a linguagem incentiva ou possibilita.

Vamos usar uma linguagem bem conhecida, tipo o Java. O Java é relativamente restritivo e em algumas situações, é teimoso em relação a como deve ser empregado. Seu design original pretendia incentivar os engenheiros a adiar soluções para problemas postergando isso para outras classes de objetos. Toda essa filosofia da linguagem não foi projetada para incentivar a criatividade ou expressão individual. Quando penso em algum projeto Java grande, penso em equipes trabalhando com especificações centralizadas que fornecem o código que execute conforme a especificação. O Java foi projetado desde o início para favorecer a simplicidade, algo afirmado na própria especificação da linguagem: "[O Java] foi projetado para ser simples o suficiente para que muitos programadores possam obter fluência na linguagem ... Ele se destina a ser uma linguagem de produção, não uma linguagem de pesquisa e assim, como sugeriu C. A. R. Hoare em seu clássico artigo sobre design de linguagem, o design tem evitado a inclusão de recursos novos e não testados".

Por outro lado, o Perl, uma linguagem pouco popular, tem como princípio central a ideia de haver "mais de uma maneira de fazer isso", uma filosofia que incentiva e celebra ativamente a criatividade individual. Isso não resulta em código legível, por isso, é comum dizer que o Perl é uma linguagem "write-only".

Além disso, mais adiante nesta ideia, temos linguagens como Lisp e TCL, que concedem liberdade e poder ao colaborador individual para fazer coisas bem insanas caso desejem, como um código auto-modificável ou a redefinição de componentes fundamentais da própria linguagem.

No entanto, o Java venceu essas outras linguagens mais criativas. Por quê? Porque, enquanto a liberdade aos "artesãos de software" possibilita a criação de grandes e belas maravilhas de engenharia, isso tem um custo elevado quando tentamos reunir grandes grupos distintos de engenheiros para colaborarem como equipes. Todas as outras coisas são iguais, a maioria dos engenheiros provavelmente gostaria de assumir um projeto Java em expansão ao invés de um projeto Perl, graças à ênfase do Java em simplicidade. Em outras palavras, beleza e sofisticação em software não são propícias à produção industrial. É mais barato e fácil usar ferramentas mais restritivas e criar soluções menos bonitas para os problemas.

Não é minha intenção argumentar que Perl é uma maravilha e Java é horrível. Quero apenas mostrar que as preferências não são ocasionais e refletem em um conjunto mais profundo de crenças sobre as quais deveríamos pensar, analisar e estar conscientes delas.

Acho interessante que, dada a sua idade e ampla adoção, o Java não é um líder aparente entre as linguagens de programação usadas no GitHub, ao passo que projetos Python, Javascript e Go são mais abundantes. Não posso deixar de pensar que, no nosso tempo livre, queremos trabalhar em uma linguagem que nos dê liberdade criativa (embora o Go seja semelhante ao Java em suas restrições, ainda possui muitas "telas brancas e infinidades de cores" para podermos brincar). Por outro lado, o Lisp mal se vê no GitHub. Podemos ter muita liberdade, e os bazares geralmente são uma bagunça, sem um tipo de design central. As pessoas geralmente acham o Lisp bastante complicado.

O classicismo na arquitetura persistiu por razões semelhantes. Na Grã-Bretanha, sua uniformidade e regras bem definidas permitiram aos arquitetos que seguiram os pioneiros Inigo Jones e Christopher Wren, criar versões mais baratas de seu trabalho, que pareciam boas o suficiente para estar na moda.

Existem livros de arquitetura clássica semelhantes aos de padrões de design para desenvolvimento de software. O Vitruvius Britannicus, publicado em 1715, deu aos arquitetos exemplos fáceis de seguir para a construção de casas grandiosas na Grã-Bretanha (e mais tarde, nos EUA) que seguem as mesmas fórmulas de estilo.

Este estilo foi chamado de palladianismo, e se tornou onipresente porque era bastante difícil de ser bagunçado, tanto quanto se soubesse o básico: manter as coisas simétricas, muitas linhas retas, e paredes com características monótonas. Esse estilo é o Java, não o Perl, incorporado em um edifício: relativamente fácil de construir e agradável o suficiente para ser visto, mas não é rico e nem diversificado.

Os construtores não se divertiram o construindo. Podemos imaginar pedreiros colocando molduras atrás de molduras, enquanto um escultor solitário conseguiu colocar algumas de suas criações no topo do edifício, onde poucos podem apreciá-las.

Os vitorianos fizeram um truque semelhante com sua versão da arquitetura gótica. Ao copiar os padrões da decoração gótica de maneira uniforme e barata, eles enfureceram Ruskin, que sentiu que eles haviam perdido o objetivo do gótico, confundindo os traços decorativos superficiais com os fundamentos da beleza. Eu cresci indo a igrejas que eram parecidas com essa do leste de Londres:

Estes são edifícios essencialmente clássicos, com algumas janelas em arco pontudo e tijolos coloridos, ao invés de colunas e mármores, na tentativa de torná-los "góticos". Não há muita saída para a criatividade do "artesão individual" ali.

Agile e gótico

Tudo isso me traz ao Agile. Como a preferência de Ruskin pelo gótico, a intenção original declarada do Agile foi fundamentada nos primeiros princípios:

Estamos descobrindo as melhores maneiras de desenvolver software, não só fazendo, mas também ajudando outras pessoas a fazê-lo.

Através deste trabalho, começamos a prezar:

  • Indivíduos e interações acima de processos e ferramentas;
  • Software que funciona acima de uma documentação compreensiva;
  • Colaboração do cliente acima de negociação do contrato;
  • Resposta às mudanças acima de seguir um plano.

Ou seja, enquanto houver valor nos itens à direita, valorizamos mais os itens à esquerda. (Acesse o Manifesto ágil.)

Esses princípios seguem de perto o pensamento de Ruskin sobre um bom trabalho proveniente de bases orgânicas e humanas:

  • 2 - "Abraçar a mudança" está mais perto de aceitar mudanças orgânicas do que de aderir a um ideal.
  • 4 - O processo criativo de construção exige uma colaboração estreita com o patrão: os requisitos também são orgânicos.
  • 5 - Enfatizar a importância da contribuição do indivíduo para o produto como um todo.
  • 8, 11, 12 - Enfatizar a importância dos relacionamentos pessoais para o produto como um todo.

Muitos desses princípios estão relacionados a coisas que não podem ser facilmente automatizadas, definidas, industrializadas ou esquematizadas. Essa é uma filosofia que incentiva post-its, ou um grande pedaço branco de papel, ou apenas algo dito enquanto tomamos uma cerveja, se é isso que é necessário para encontrar o caminho certo a seguir. Está mais próximo da maneira "bottom-top", gótica, "bazar", revolucionária, e colaborativa de trabalhar, com poucas regras e supervisão, do que do totalitarismo "top-down" do classicismo, "catedral", estilo de obediência industrial. Como você responde àquela conversa favorita da hora do café: Quão ágil é o seu time? Ao invés disso, sugiro a seguinte pergunta: Quão livre é a equipe para tomar qualquer decisão que considere necessária para realizar o trabalho?

Agora, liberdade e empresa não andam de mãos dadas. É por isso que acabamos em um Agile corporativo:

A todo e qualquer momento, as demandas corporativas, regulatórias e legais das empresas devem atender à mitigação da capacidade do indivíduo de fazer uma contribuição imperfeita para o todo. Então pare de tentar, caramba! Acabamos subvertendo o todo, como disse o fundador do Agile, Dave Thomas.

Um dos pontos que quero destacar aqui é que não há nada de errado em não ser ágil se o que desejamos alcançar é algo que pode ser feito seguindo um plano, ou que precisamos de comando e controle para entregar os produtos. Se a satisfação, a criatividade ou a capacidade de inovação individual não são uma preocupação primordial, basta aceitar isso e garantir que o projeto geral seja algo que as pessoas possam entender, como a arquitetura palladiana. Pare de tentar ser ágil apenas por ser.

Seja honesto agora: quantas pessoas podem realmente entender isso?

Sabor, humanidade e fragmentos de imperfeição

Acredito que este é um prédio bonito, mesmo sendo tão clássico e "ideal" quanto possível:

Tempietto de Bramante

Acho isso porque, embora nada em seu design possa ser movido sem arruiná-lo, e, sem dúvida, ninguém que trabalhou nele pôde expressar sua própria opinião ali, a escala do edifício ainda é humana: foi projetado para pessoas para entrarem e contemplarem o legado de outros seres humanos.

Compare com o Museu Britânico:

O Museu Britânico: um prédio que diz, "Temos suas coisas e não as devolveremos".

Este é um edifício que sempre detestei. Parece projetado para nos fazer sentir pequeno e imperfeito em comparação com sua escala maciça e desumana. Também é chato. Coluna, coluna, coluna, coluna, a toda a volta. A escultura na parte superior pode ser interessante, mas não parece ter sido projetada para olharmos de perto.

Eu não poderia dizer melhor do que Ruskin:

"A principal admirabilidade das escolas de arquitetura gótica, assim que recebem os resultados do trabalho de mentes inferiores e fragmentos cheios de imperfeições, traem essa imperfeição a cada toque e elevam indulgentemente um todo imponente e impenetrável."

Não seriam a sociedade e o software melhores se, ao invés de seguirmos cegamente os livros de padrões e as metodologias de desenvolvimento de cultos de cargos que funcionaram para outras pessoas em outro lugar qualquer, aplicássemos de maneira criativa ー e imperfeita ー, nosso intelecto e experiência ao nosso local e situações únicas, criando soluções bonitas que não apenas "agregam valor", mas nos dão prazer? Afinal, se somos alguma coisa, somos "fragmentos de imperfeição."

Sobre o autor

Ian Miell trabalha na Container Solutions, ajudando as empresas a se adaptarem a um mundo nativo da nuvem. Anteriormente, trabalhou para bancos construindo e executando clusters Kubernetes e, antes disso, construiu e manteve o backend de sistemas de apostas online. Escreve sobre seus interesses no zwischenzugs.com.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT