Pode parecer estranho, mas desenvolver aplicativos é uma arte. É difícil, de verdade, fazer as pessoas entenderem isso.
Programação precisa de conceitos? Ótimo, música e pintura também. Também é necessário aprender a pensar da forma que a ferramenta que você usa para desenvolver (ou tocar, em caso de música) pede. Provavelmente, o improviso que você faria em um violão não será o mesmo de um violino, ou de um piano – da mesma forma, o código que se escreve em uma linguagem não segue os mesmos padrões de outras linguagens, e tentar negar isso é absurdo no mínimo.
Para os que programam mesmo, sempre há aquele amigo que quando lê um código, praticamente em qualquer linguagem, aponta na hora aonde está o erro. Ele está simplesmente adivinhando? Há uma máxima que a maioria das pessoas de desenvolvimento de sistemas esquece: “O código é muito mais lido do que escrito”. Da mesma forma, há uma citação atribuída à Donald Knuth, professor de renome da universidade de Stanford que diz: “Code is written for humans to read and only incidentally for computers to execute”. Continuando com o compacto, ao mesmo tempo em que um desenhista precisa ver muitos desenhos, visitar galerias de arte, ver as tendências, o programador deve também estar atento a essas coisas. Há um framework muito legal que as pessoas estão falando? Leia o código dele. Faça um pequeno projeto. Aprenda uma nova linguagem, nem que seja Haskell, Lisp, Smalltalk, ou outras linguagens que quase não tem repercursão comercial. No mínimo, você terá feito algo inútil. No máximo, você estudará uma linguagem nova e tentará aproveitar conceitos interessantes dela em outros projetos.
Agora, a estagnação é o maior perigo em artistas – não reconhecer mais que o que você está fazendo é ultrapassado, que a tendência mudou, que seu trabalho não gera mais aquele entusiasmo nas pessoas, etc. Porque, apesar de tudo, um software pronto gera entusiasmo: a vantagem de não ter mais que fazer as coisas manualmente, de agora ver o trabalho simplificado, de até mesmo começar a pensar em formas melhores de se fazer algo. E um programador, um analista de sistemas, deve agir como um músico: imagine um músico que começa a tocar músicas eruditas desconhecidas, dissonantes, numa balada de adolescentes… não que adolescentes não possam gostar do som, ou qualquer coisa, mas simplesmente não é o que se espera do músico naquele ambiente. Da mesma forma, o desenvolvimento de aplicativos parece seguir essa linha elitizada: aparentemente, não importa o que o usuário do sistema deseja – perde-se muito tempo discutindo “melhores práticas”, “forma de fazer”, “telas”, “design”, enquanto o futuro usuário está com um problema real e precisa de uma solução real – e muitas vezes, não tem muito tempo para esperar. O resultado disso é aquilo que todos nós conhecemos, como planilhas de excel e sistemas em Access feitos por pessoas sem nenhum conhecimento do assunto, e consequentemente dados completamente desorganizados ou incompletos. Assim como, se um músico se recusar a tocar músicas que as pessoas gostam, ele será convidado a deixar o lugar, e vão chamar o “sobrinho do amigo do vizinho da namorada do dono”, que aprendeu a tocar violão vendo tutoriais na internet, para tocar no lugar. O resultado será uma música de qualidade muito inferior, claro, porém que as pessoas vão escutar e se identificar com isso.
Esse é o ponto chave da coisa: As pessoas precisam se identificar com o sistema que está sendo desenvolvido. De nada adianta você montar um super-sistema, usando todas as melhores práticas, rápido, que integra com o mundo e automatiza uma centena de processos, se o usuário que o usará não se identifica. Talvez o sistema tenha telas muito estranhas? Talvez o sistema não faça as coisas do jeito que o usuário fazia? O que importa é, não adianta pensar em automatização de processos enquanto os processos não estão num sistema. Sistemas de computador são coisas incrementais – eles nascem com funcionalidades básicas e ganham melhores funcionalidades. É para isso que existem números de versão – sistemas grandes não nasceram com todas as funcionalidades que eles possuem, e de fato, muitas das funcionalidades nem sequer tinham sido pensadas. Isso parece óbvio, mas não é: todos querem lançar um sistema com TUDO, logo na primeira versão. Ou será que um músico escreve, direto da cabeça, a melodia e a harmonia de uma música, inteira? Será que numa tacada só ele escreve tudo, ou ele faz primeiro a primeira parte, depois a segunda, aí re-escreve algo da primeira parte, depois re-escreve algo da segunda…
É difícil pensar em software assim? Claro que é. Mas o problema do desenvolvimento de software é que, quanto mais tempo se passa, mais o software torna-se algo “técnico”, “específico”, e mais se afasta da verdadeira essência – ajudar pessoas. Mais e mais ficamos “elitizados”, fechamos “técnicas de desenvolvimento”, optamos pelo que achamos que é certo ao invés do que o usuário acha que é certo, e tudo isso para quê? Eu não vejo, hoje em dia, softwares melhores do que os de antes – continuamos usando processadores de texto que, de uma versão para outra, desformatam tudo. Continuamos brigando para imprimir uma simples página da internet, porque o navegador redimensionou a página e não nos avisou. Tiram-se os menus de certos aplicativos, mas continuamos procurando a esmo a funcionalidade que queremos, agora em botões, abas, ou telas. Java continua a mesma coisa de quando foi criada, Python possui a filosofia “programadores não podem ter livre-arbítrio”, companhias como o GemStone criam um novo Ruby “mais rápido”, mas que é pago e não contribuem com patches para deixar a implementação oficial mais rápida, etc etc… e as pessoas discutem se Ruby, Python, Java, C# é melhor quando deveriam discutir outras coisas – eu, pelo menos, não vejo músicos discutindo se pianos tem som mais bonito, se violões são mais “legais”, etc… vejo eles discutirem que tipos de acordes deveriam usar em determinada música.
E é isso que deveríamos fazer: discutir qual é a melhor forma de resolver um problema. E de fato, resolver o problema, não apenas empurrar uma solução que não soluciona nada, porque ela “é melhor”.
Provocações: http://xexeo.wordpress.com/2009/10/24/estamos-ficando-ultrapassados/ (blog de um professor da UFRJ)
Mastering the art of application development: http://www.mefeedia.com/watch/24603213 (Palestra de Obie Fernandez, no Rails Summit de 2009)
1 Comment
gxexeo · 2010-05-28 at 19:41
Muito bom texto, porém discordo que seja uma arte, a não ser no sentido muito antigo arte=técnica. A questão básica é que ao fazer software estamos limitados por um conjunto de restrições e devemos seguir essas restrições (da melhor forma possível). Na arte, ao contrário, seguir restrições é a receita da mediocridade.
Mas a metáfora é boa. Em inglês existe a palavra “craft”, traduzida para “artesanato”, que atende, talvez melhor, o que você quer: algo útil e belo.
Porém, talvez o maior problema seja não reconhecer a beleza da engenheira. Um viaduto é chamado de “obra de arte” pelos engenheiros, e muitas vezes é indiferenciável de uma obra de arte. É clara, para um engenheiro, a diferença entre uma boa solução e uma má solução, mesmo que ambas tenham seguido todas as técnicas recomendáveis.