O grande problema no desenvolvimento de software é linguístico
Tags: ptbr, braziliandevs, armadilhas
Published: 2021-06-21 13:14:59

---
title: O grande problema no desenvolvimento de software é linguístico
published: true
description: O grande problema no desenvolvimento de software é linguístico
tags: ptbr, braziliandevs, armadilhas
cover_image: https://www.thoughtco.com/thmb/AJgCBOXOrDV_THLddckAHGy-EBQ=/2042x1149/smart/filters:no_upscale()/Getty_linguistics-175416686-570f1f255f9b581408973018.jpg
---
_Texto escrito em 2013_

<a href="https://devkico.itexto.com.br/wp-content/uploads/2008/11/wittgenstein_swansea_1947.jpg"><img class="size-medium wp-image-173" title="wittgenstein_swansea_1947" src="https://devkico.itexto.com.br/wp-content/uploads/2008/11/wittgenstein_swansea_1947-300x239.jpg" alt="" width="300" height="239"></a>

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 "<a href="http://www.casadocodigo.com.br/products/spring">Vire o Jogo com Spring Framework</a>" esta se dividiu em duas frentes: <a href="https://devkico.itexto.com.br/?p=1131">bibliografia</a> e comportamental. &nbsp;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:
<blockquote>Ah, é um negócio que eu uso pra definir as propriedades dos meus beans.</blockquote>
Repare bem nesta resposta: eu pergunto <strong>o quê é</strong>, e não "<strong>pra que"</strong>. Talvez os desenvolvedores estejam sendo lobotomizados sem se dar conta disto. Acredito que seja decorrência do foco exagerado na <strong>produtividade</strong> ao invés da <strong>qualidade</strong>. Afinal de contas, é muito fácil ser produtivo escrevendo código ruim, mas impossível obter qualidade da mesma forma. Qualidade requer <strong>tempo </strong>para se obter o conhecimento a respeito da essência do problema, ou seja, para entender com <strong>o quê</strong> estamos lidando.

Tenho uma teoria para uma das causas deste problema: <strong>o mercado está usando o idioma errado</strong>. Chamo este idioma de <strong>industrial</strong>, e a melhor maneira de compreendê-lo é a partir do seu conceito mais popular que é o de<strong> "fábrica de software"</strong>.
<h3>O idioma industrial e sua fábrica</h3>
<a href="https://devkico.itexto.com.br/wp-content/uploads/2012/11/fabrica.png"><img class="size-medium wp-image-1239" title="fabrica" src="https://devkico.itexto.com.br/wp-content/uploads/2012/11/fabrica-274x300.png" alt="" width="274" height="300"></a>

O vocabulário do indivíduo é formado a partir<em> </em>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 <em>fábrica de software</em>, <em>programador pedreiro</em>, <em>arquiteto mestre de obras </em>e outras sendo usadas por pessoas que não possuem vivência no processo de criação e desenvolvimento de software.

Chamo <strong>idioma industrial</strong> 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: &nbsp;cascata se mostra como a mais óbvia, <em>produtiva</em> 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 <strong>montagem</strong>.

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 &gt; analista de requisitos, designer &gt; arquiteto de software, operário &gt; 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:
<blockquote>"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"</blockquote>
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 <strong>mesmo</strong> software (o que não sei se faz sentido)). E ainda pior: é um discurso <strong>cruel</strong> 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 <strong>como fazer</strong> do que na <strong>definição</strong> da tarefa.
<h3>Fábrica de máquinas não pensantes</h3>
<a href="https://devkico.itexto.com.br/wp-content/uploads/2012/11/pensar_merda.png"><img class="alignleft size-full wp-image-1244" style="margin: 10px;" title="pensar_merda" src="https://devkico.itexto.com.br/wp-content/uploads/2012/11/pensar_merda.png" alt="" width="154" height="201"></a>Como resultado direto em cima dos desenvolvedores, o que observo é uma ânsia pela entrega rápida, o que fica claro no foco em <strong>como fazer. </strong> 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 <a href="https://devkico.itexto.com.br/?p=1169">componentes</a>, <a href="https://devkico.itexto.com.br/?p=1148">desapego ao valor</a> 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:
<blockquote>O idioma industrial aliena o trabalhador do seu direito de pensar</blockquote>
<h3>A solução</h3>
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 <strong>imaterialidade</strong> do que produzimos, sua essência <strong>intelectual</strong> e <strong>rara repetição do produto</strong>. 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.
<h3>Concluindo</h3>
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. &nbsp;Recentemente tratei do <a href="https://devkico.itexto.com.br/?p=1148">conceito de valor</a> para tentar justificar o quê fazemos.&nbsp;Logo em seguida tentei tratar da "mecanização" que nos foi imposta quando escrevi sobre os <a href="https://devkico.itexto.com.br/?p=1169">excessos da componentização</a>. 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 <strong>bem feito</strong>, primeiro precisamos saber do que estamos falando, certo?