Armadilhas para desenvolvedores (ou, o que o tornará mais um idiota)

Com o passar do tempo, ficam nítidas para mim algumas situações nas quais desenvolvedores  talentosos (ou não) entram e das quais saem completamente idiotas (raríssimas vezes com algum tipo de salvação). Chamo estas situações de “armadilhas para desenvolvedores” e, a partir deste post, pretendo expor algumas das que presenciei ou virei a me deparar a partir de então (sintam-se abertos a me contarem as suas).

A palavra “armadilha” foi selecionada a dedo. Isto porque todas as situações que irei mencionar aqui possuem uma característica em comum: apresentam um ambiente ou objeto aparentemente confortável e desejável que, uma vez penetrado ou obtido, mostra-se incrívelmente cruel.

Armadilha #1: Determinismo linguístico

É o meu pior pesadelo sem sombra de dúvidas. Para aqueles que não o conhecem, o determinismo linguistico consiste na hipótese segundo a qual a nossa percepção do mundo é definida por nossa linguagem. Exemplo clássico: os esquimós. Estes conseguem distinguir n tons diferentes de branco, cada um com seu próprio nome, ao passo que nós, brasileiros, basicamente conseguimos distinguir apenas o branco e o cinza. Em contra-partida, conhecemos n tipos diferentes de bananas (nanica, caturra, serra d’água…), ao passo que um esquimó só consegue distinguir de cara um tipo de banana.

Como isto se aplicaria a um desenvolvedor? Simples: aquele que só utiliza o mesmo ambiente de desenvolvimento/linguagem normalmente tem uma dificuldade monumental em aprender qualquer outro. Exemplo clássico: o pessoal que trabalha com ambientes RAD como Visual Basic ou Delphi (mais específicamente, os amontoadores de componentes (há pessoas absurdamente competentes trabalhando Delphi e VB)). Ao tentarem aprender outra linguagem como Java, por exemplo, a primeira coisa que tentam fazer consiste em aplicar exatamente as mesmas técnicas que utilizavam até então neste novo ambiente. Resultado: fracasso total. É possível diagnosticar alguém que tenha caido nesta armadilha ao ouvir alguma das frases abaixo:

• “Linguagem/Ambiente X é um LIXO!”
  O sujeito está tentando aplicar técnicas específicas de um ambiente/linguagem em outro. Como não irão funcionar, consequentemente, vê a culpa NO ambiente/linguagem, e não em si mesmo.
• “Sou muito mais produtivo na linguagem/ambiente X. Se estivesse trabalhando nele, o trabalho já estaria pronto!”
  O problema se torna nítido. O sujeito basicamente confirma que realmente só consegue trabalhar em um ambiente/linguagem.
• “Linguagens de programação são todas iguais. Só varia a sintaxe…”
  Aham… Se fosse verdade, só existiria UMA linguagem de programação (a que o sujeito conhece, provávelmente)

Um aspecto interessante de quem caiu nesta armadilha consiste em uma certa arrogância. Culpam a linguagem/ambiente por todos os problemas que estão enfrentando e se esquecem de que o mesmo ambiente/linguagem foi utilizado com sucesso incontáveis vezes em projetos do mesmo ou maior porte do que aquele no qual o indivíduo se encontra em dificuldades.

Na realidade, o determinismo linguístico fica exposto ao perceber o modo como o sujeito inicia sua produção no novo ambiente. Muitas vezes nem sequer chega a estudá-lo direito. Simplesmente cata a primeira IDE que encontra e começa a trabalhar exatamente como fazia no ambiente/linguagem com o qual estava habituado.

Armadilha #2: software = banco de dados relacional

O sujeito não acredita que exista desenvolvimento além do CRUD. Como detectar alguém que tenha caido nesta armadilha? Simples: mencione qualquer tipo de estrutura de dados diferente de tabela ou índice. Se disser que conhece, vá além: peça para que lhe descreva o funcionamento (alerta: criará inimigos com isto). Ou, pior ainda, pergunte ao indivíduo se ele consegue programar algo sem um banco de dados relacional por trás.

O que ocorre nesta situação: o sujeito trabalha em um ambiente no qual a esmagadora maioria das demandas consista apenas na criação de aplicações que armazenem e busquem informações presentes em bancos de dados (apenas CRUD). No máximo, um relatório ou outro mais complexo, envolvendo somatórios e agrupamentos. O que se percebe é a armadilha #1, ou seja, o determinismo linguístico. A diferença é que este é O caso mais comum da armadilha E o que também causa os maiores prejuízos.

Como o resultado de uma consulta SQL é imediato, o sujeito acredita que seu trabalho terminou na criação dos formulários de exposição e cadastro. No entanto, a partir do momento em que o problema se tornar mais complexo a coisa muda de figura.

O mais fascinante desta armadilha consiste no fato da vítima conseguir fazer coisas incríveis com SQL, porém falhar miserávelmente quando precisar de qualquer coisa que vá além desta.

Neste caso, no entanto, há uma bomba relógio ativada: está provado que os SGBDs relacionais não escalam bem em ambientes paralelizados (mais sobre isto aqui, aqui e aqui(terceiro link particularmente interessante, por apresentar o CouchDB)). Como o número de processadores por computdor está aumentando, e o clock de cada um destes tende a diminuir e cloud computing está crescendo MUITO, veremos problemas imensos de performance nos próximos anos cuja origem se encontra justamente neste tipo de profissional que acredita no mito de que uma aplicação é composta por um banco de dados relacional apenas.

Este tipo de indivíduo se esquece de algo básico: os dados são o resultado de um processamento, e não o contrário!

Armadilha #3: ambientes de desenvolvimento RAD

O sujeito aprende a programar em um ambiente RAD e se atém a este. O utiliza para criar um CRUD simples, sempre utilizando a mesma linguagem (99% das vezes VB, Delphi e Visual Studio). Resultado: armadilhas #1 e #2 engatilhadas com um agravante: a ilusão de que desenvolvimento de sistemas é uma tarefa simples.

Não tenho nada contra estes ambientes (sendo assim, por favor, não me ataquem), porém tenho contra o seu mal uso. O maior problema aqui ocorre quando se esquece que um ambiente como VB ou Delphi deve ser usado apenas para facilitar a execução de tarefas repetitivas e tediosas, como por exemplo a criação de um formulário, e que estas tarefas repetitivas e tediosas são apenas uma PEQUENA parte do processo de desenvolvimento, e não o seu todo.

O que se observa é basicamente o contrário: o indivíduo passa HORAS (ou DIAS) buscando componentes terceirizados para finalizar as tarefas que não envolvam CRUD, os incorporam em seus “sistemas” porcamente e se esquecem de outros elementos que também deveriam estar presentes no processo, como por exemplo segurança, escalabilidade, usabilidade e, mais importante ainda: código de qualidade, que seja fácil de ser mantido e compreendido.

Quer detectar alguém com este problema? Simples: remova deste indivíduo a sua IDE.

Armadilha #4: português é seu único idioma

Parece impensável, mas a quantidade de “programadores” que ignora completamente o inglês é alarmante. Como consequencia, tem de se virar apenas com o que existe publicado em português. Dado que a qualidade é muito inferior à que é produzida no exterior, o sujeito acaba se tornando limitado com o passar do tempo.

Claro, as coisas estão melhorando aqui no Brasil, porém, por mais que melhorem, difícilmente se igualarão à publicação atualmente produzida em inglês. Mesmo porque até os países no qual o inglês não é o idioma oficial costumam publicar conteúdo para nossa área em… inglês.

Armadilha #5: preguiça de ler

O sujeito acredita que não precisa ler para se tornar um bom profissional. Resultado? Programadores analfabetos. Já escrevi sobre isto aqui, sendo assim, não irei me alongar muito sobre o assunto.

Armadilha #6: medo da mudança

O indivíduo pira a cada mudança que ocorre em seu ambiente de trabalho. Mudou um pouco a especificação? Boom! Crise, o sujeito pensa em pular do último andar do prédio em que trabalha. Chamo este tipo de profissional de “desenvolvedor autista”.

O desenvolvedor autista não consegue ver que a mudança é a principal razão pela qual recebe seu dinheiro todo mês. Que se estas cessarem, seu trabalho automaticamente torna-se desnecessário e, pior ainda, nega o básico da realidade: tudo muda. No século V a.C Heráclito já dizia: panta rei (tudo muda). Se as coisas mudam na natureza, por que não muariam no seu trabalho? Será possível que 2500 anos depois, as pessoas ainda não conseguem aceitar este fato???

A origem do problema consiste na crença de que o desenvolvimento de sistemas é uma ciência exata. Noção esta completamente equivocada, se levarmos em consideração o fato de que nosso trabalho consiste em modelar no ambiente digital um problema que ocorre no mundo físico. Problema este que normalmente é criado por seres humanos que, como todos sabemos (com excessão do desenvolvedor altista), mudam de opinião o tempo inteiro!

Como identificar alguém com este problema? Varia do nível: nos casos extremos, basta mudar a posição do seu mouse.

Conclusão

Estas são as principais armadilhas que já presenciei. Após analisá-las, alguém poderia me fazer alguns questionamentos, como os a seguir:

Por que não foram mencionadas armadilhas de gerenciamento?

Simples: por que se alguém quer gerenciar uma equipe de desenvolvimento, você tem de saber o que está gerenciando, ou seja: tem de pelo menos uma vez na vida ter programado ou pelo menos tentado. Caso não tenha se mostrado um bom programador, ao menos deveria saber como reconhecer um.

Como eu evito estas armadilhas?

Basicamente evitando a primeira, ou seja, reconhecendo a diversidade e o fato de que desenvolvimento de sistemas é uma atividade complexa, que requer estudo constante e que poucos conseguem levá-la a cabo com sucesso, ou seja: diminuindo a arrogância.