Texto escrito em 2013
Conforme o tempo passa me convenço que a esmagadora maioria (possívelmente todos) dos problemas relacionados ao desenvolvimento de sistemas tem sua origem na má compreensão da linguagem.
Quando iniciei a pesquisa que resultaria no meu livro "Vire o Jogo com Spring Framework" esta se dividiu em duas frentes: bibliografia e comportamental. Na segunda vi que a maior parte das pessoas usavam em seu dia a dia os conceitos nos quais o Spring se baseia, como inversão de controle, injeção de dependências, AOP e todo o resto, porém sem ter a menor idéia da razão real pela qual o fazem e o que estes conceitos significavam de fato. Ao questionar estas pessoas a respeito do que era injeção de dependências, por exemplo, a resposta que eu obtia era sempre mais ou menos esta:
Ah, é um negócio que eu uso pra definir as propriedades dos meus beans.
Repare bem nesta resposta: eu pergunto o quê é, e não "pra que". Talvez os desenvolvedores estejam sendo lobotomizados sem se dar conta disto. Acredito que seja decorrência do foco exagerado na produtividade ao invés da qualidade. Afinal de contas, é muito fácil ser produtivo escrevendo código ruim, mas impossível obter qualidade da mesma forma. Qualidade requer tempo para se obter o conhecimento a respeito da essência do problema, ou seja, para entender com o quê estamos lidando.
Tenho uma teoria para uma das causas deste problema: o mercado está usando o idioma errado. Chamo este idioma de industrial, e a melhor maneira de compreendê-lo é a partir do seu conceito mais popular que é o de "fábrica de software".
O idioma industrial e sua fábrica
O vocabulário do indivíduo é formado a partir da sua experiência de vida: o que lemos, nossas conversas, ambiente em que estamos. A linguagem usada por cada um corresponde na prática à sua percepção do mundo. Quando nos deparamos com algo novo nosso primeiro instinto é o de escolher uma analogia entre aquele objeto e nossa linguagem "pessoal". Sendo assim, nada mais natural que vejamos analogias como fábrica de software, programador pedreiro, arquiteto mestre de obras e outras sendo usadas por pessoas que não possuem vivência no processo de criação e desenvolvimento de software.
Chamo idioma industrial este conjunto de metáforas que se instalou em nosso meio que relaciona o ofício de desenvolvimento de sistemas a atividades que geram bens materiais como indústrias, construção civíl, etc. Na minha pesquisa infelizmente não encontrei uma origem histórica precisa deste idioma, porém tudo sempre leva a administradores ou investidores que possuem em comum apenas a pouca experiência na área.
A analogia em um primeiro momento para o leigo se mostra irresistível: vê-se alguns papéis, o analista de requisitos, o arquiteto, o desenvolvedor, testador, etc. A impressão criada é a de que o trabalho de um necessáriamente gera a saída para o próximo: cascata se mostra como a mais óbvia, produtiva e aplicável. O interessante é que não se pensa nas consequências desta analogia: quando pensamos em fábrica, junto a este conceito vêm a idéia de linha de montagem.
Montar componentes para gerar um produto final é um processo quase mecânico (ao menos me parece), mas que torna possível fazer um paralelo direto com o mercado atual. Na linha de montagem há um designer inicial que projeta o produto e seleciona os componentes. Logo em seguida há o operário que seleciona os componentes, os integra, testa e passa para o próximo passo, que é a entrega para o cliente. Há também o pessoal do marketing que alimenta o designer com a visão do que o mercado quer. Reparou a relação? Se não, aqui vai ela explícita: marketing > analista de requisitos, designer > arquiteto de software, operário > programador.
Como principal consequência desta metáfora ruim é que junto a esta vêm um conceito de produtividade que normalmente se manifesta em frases como a abaixo:
"A produtividade média da nossa equipe é de X horas por ponto de função usando tecnologia Y baseando-se no nosso registro histórico"
O problema é que na linha de montagem sempre se monta a mesma coisa, enquanto na fábrica de software cada caso é único. A partir do momento em que se aceita este fato fica nítido que todo planejamento baseado nestes princípios está fadado ao erro na esmagadora maioria das vezes (claro, a não ser que você esteja desenvolvendo sempre o mesmo software (o que não sei se faz sentido)). E ainda pior: é um discurso cruel com o desenvolvedor, pois dado que o objetivo de todo negócio é crescer sempre, qual seria o momento em que este atingiria sua produtividade máxima? Talvez isto explique o por quê do foco estar sendo mais no como fazer do que na definição da tarefa.
Fábrica de máquinas não pensantes
Como resultado direto em cima dos desenvolvedores, o que observo é uma ânsia pela entrega rápida, o que fica claro no foco em como fazer. Talvez por isto a busca por exemplos em grupos de discussão ao invés das definições de conceitos seja tão mais popular. E como o trabalhador novato já entra em um ambiente no qual prevalece o idioma industrial, este acaba por aceitá-lo como verdade por ser a sua experiência inicial como profissional. A partir deste momento o foco em leituras rápidas em busca de soluções imediatas se instaura e podemos até ter um profissional extremamente produtivo, mas aí eu me pergunto: será que gera qualidade?
Vêmos então uma ênfase brutal na criação de componentes, desapego ao valor por parte do trabalhador, que agora se vê alienado do seu direito de pensar. Sim, de pensar: por que a partir do momento em que métricas como a que expus acima são aplicadas, o tempo que este possuí para entender o problema é racionado. Sim: a consequência direta do idioma industrial é esta:
O idioma industrial aliena o trabalhador do seu direito de pensar
A solução
O leitor que chegou neste ponto do texto deve estar pensando que para mim o tempo de desenvolvimento de software é infinito e que prazos não devam ser levados em consideração. Nada disto! Afinal de contas, desenvolvemos software para alguém que tem uma necessidade a ser cumprida em um determinado espaço de tempo e custo. A grande questão é que ao usarmos metáforas inadequadas como a que descrevi acima acabamos por gerar estimativas erradas e, com isto, traçar um planejamento que não seja tenha a ver com a realidade do nosso ofício.
Sinceramente, não sei quais seriam as melhores metáforas a serem aplicadas ao nosso trabalho. Mas sei de alguns atributos que deveriam estar relacionados: a imaterialidade do que produzimos, sua essência intelectual e rara repetição do produto. Talvez algo relacionado a artesanato ou literatura chegasse mais perto da realidade. Deixo esta decisão a cargo do leitor.
Acredito que a solução seja começarmos a pensar de maneira mais profunda nos conceitos que usamos em nosso dia a dia. O que é de fato desenvolvimento de software? Arquitetura? Gerência? O que estas palavras e tantas outras de fato significam e como eu, e o ambiente a minha volta as compreendemos? Este pra mim é o primeiro passo fundamental pra que possamos trocar o idioma corrente.
Concluindo
Cozinho esta idéia na cabeça já faz alguns anos. O leitor assíduo deste blog talvez agora perceba que o fui preparando para este post. Muito tempo atrás eu comecei a escrever sobre o problema do determinismo linguístico. Recentemente tratei do conceito de valor para tentar justificar o quê fazemos. Logo em seguida tentei tratar da "mecanização" que nos foi imposta quando escrevi sobre os excessos da componentização. Há ainda um elo faltante nesta conclusão que seria tratar o conceito de qualidade, que ainda vou tratar em um post futuro com certeza (já estou inclusive trabalhando nisto).
Talvez o leitor tenha uma fábrica de software. Por favor, entenda que não estou a lhe agredir neste post, mas sim expondo um problema linguístico de nossa área que talvez, ao ser tratado, lhe ajude a obter um lucro maior com o seu negócio. Afinal de contas, para fazer algo bem feito, primeiro precisamos saber do que estamos falando, certo?
Top comments (0)