{ End Bracket }
Orgulho de ser um desenvolvedor
Adam Barr
Quando eu estava para me formar na universidade, lembro-me de uma conversa com um colega de ciência da computação que ia trabalhar em um banco de investimentos. Ele me explicou que se envolveria com criação de software, mas que não se ocuparia com a função mundana de realmente escrevê-lo. Esse trabalho seria relegado a um codificador que, evidentemente, era um ser inferior. Em outras palavras, eu. Vindo de um ambiente universitário em que a capacidade de criar código era o status definitivo, me senti vagamente insultado.
Entretanto, ele tinha razão. Naquela época, eu era apenas um codificador (e não que ele fosse muito melhor). Hoje, como no título do livro de Mike Gunderloy, Coder to Developer (De codificador a desenvolvedor), eu evoluí de um simples codificador e agora me considero um desenvolvedor. Eu sei muito mais do que simplesmente escrever um código que consiga ser compilado; posso produzir um software rápido, confiável, bem testado, seguro, fácil de manter, globalizável e assim por diante na lista de atributos de um código de alta qualidade. A indústria de software em geral está amadurecendo, de um exército de codificadores para um exército de desenvolvedores.
Agora, se você perguntar aos desenvolvedores sobre a próxima etapa nas suas carreiras, talvez eles digam que querem ser arquitetos. A palavra conjura visões de titânio e de vidro fosco e relega o mero desenvolvedor, por comparação, à função de um trabalhador da construção civil. Então, será que eu me sinto bem em passar para a próxima etapa teórica e me tornar um arquiteto? Minha resposta é não.
Não pretendo insultar os arquitetos: o desenvolvimento de software precisa de pessoas que modelem a interação entre componentes de um sistema e que tenham em mente a visão geral. No entanto, eu me orgulho de ser um desenvolvedor e espero que todos os outros desenvolvedores possam sentir o mesmo orgulho.
E se você invejar a liberdade de projeto de arquitetos como Frank Gehry ou Rem Koolhaas? Minha resposta seria que a disciplina engenharia de software ainda é muito imatura para subir nessa escada conceitual. Os arquitetos podem projetar edifícios como o museu Guggenheim de Bilbao e a biblioteca pública de Seattle porque têm o apoio de séculos de conhecimento sobre a engenharia civil. A indústria do software não pode se dar ao luxo de ter todo mundo operando no mesmo nível; a maioria de nós ainda está tentando construir uma casa térrea que não caia quando você fechar a porta da frente.
Quando a Microsoft examina a causa de seus bugs, identifica um número significativo de bugs que não são de projeto – o tipo que seria encontrado quando um arquiteto revisa um documento de projeto, mas que também não são de codificação – quando o código-fonte não faz o que o programador pretendia. Essa classe intermediária ocorre quando o código-fonte faz o que o programador pretendia, embora haja um erro na intenção: problemas como passar os sinalizadores errados para um método ou o entendimento incorreto do significado de um parâmetro de configuração. Esse não é o campo dos arquitetos. É algo que nós, desenvolvedores, temos de fazer corretamente por conta própria.
Fred Brooks fez uma alusão a esse assunto em seu famoso ensaio "No Silver Bullet" (Nenhuma bala de prata), em que escreveu que "a essência de uma entidade de software é a criação de conceitos entremeados: conjuntos de dados, relacionamentos entre itens de dados, algoritmos e chamadas de funções". Mais adiante, ele acrescenta: "acredito que a parte mais difícil da criação de software é a especificação, o projeto e o teste dessa construção conceitual, e não o trabalho de representá-la e de testar a fidelidade da representação". Ele não está falando sobre o que os arquitetos fazem, mas sobre a função dos desenvolvedores. Com efeito, ele está dizendo que ser um codificador pode não ser tão difícil, mas ser um desenvolvedor certamente é. Devemos reconhecer o mérito do que fazemos.
Eu sei que essa não é a parte gloriosa do trabalho de programação. Pode ser emocionante arquitetar perfeitamente diversos componentes de uma forma que eles encapsulem organizadamente a variação e permitam uma extensão futura. Os programadores gostam da precisão e existe a beleza de termos todas as partes encaixadas perfeitamente. Mas há uma grande parte da produção de software que envolve o trabalho de um artesão habilidoso: execução das revisões de código, escrita de testes de unidade e limpeza de comentários. Os clientes podem não reconhecer diretamente como o nosso trabalho pesado garante sua privacidade ou protege seu sistema contra ataques, mas nós sabemos o valor que oferecemos. E há áreas como a otimização de desempenho e o gerenciamento da energia que são verdadeiras obras de arte: não é uma arquitetura de alto nível, mas trabalho de fechamento, simplesmente quando aplicamos nossas habilidades e a nossa experiência ao problema que temos em mãos.
Tenho orgulho de dizer que sou um desenvolvedor e não um arquiteto. Talvez, algum dia, resolveremos todos os problemas de engenharia de software e então todos poderemos nos tornar arquitetos. Enquanto isso, ainda há alguns programas bem-feitos que precisamos terminar.
Adam Barr trabalhou na Microsoft por 13 anos. Ele foi desenvolvedor, gerente de programa e, atualmente, é engenheiro de conhecimento da equipe Engineering Excellence, trabalhando como consultor interno e instrutor para apoiar o processo de engenharia de desenvolvimento.