Fábricas de software – Uma analogia levada longe demais

Analogias costumam ser usadas para tentar entender melhor algo. A idéia é bastante simples: compara-se o objeto ou conceito que não se conhece a outro bem conhecido com o objetivo de aprender alguma coisa ou formar algum argumento. Muito já se descobriu com ajuda das analogias, mas elas também podem ser bem perigosas. Eu poderia repetir tudo aqui, mas o Marcos Pereira saiu na minha frente com o primeiro artigo do seu novo blog que discute várias das mais furadas analogias para desenvolvimento de software (e uma das certeiras). Ao invés disso, este artigo vai se deter em apenas uma delas: a das fábricas.

Fábricas são instalações onde as pessoas se reúnem para produzir um certo tipo de artigo. Fábricas de sapatos fazem sapatos, fábricas de postes fazem postes e fábricas de software fazem software.

Simples assim.

Mas nem tanto…

Fábricas são instalações com estrutura e procedimentos de produção pautados por um certo modelo. Afinal de contas, não são só as fábricas que se encaixam na definição acima. Organizações como oficinas e ateliês também podem perfeitamente produzir artigos de qualidade. A diferença está na organização interna.

Um dos maiores problemas das analogias é que costumam ter limites não muito bem definidos. Toda analogia tem um ponto de quebra a partir do qual não faz mais sentido e nem sempre é fácil identificar até onde podem ser aplicadas. Nas mais rasas este ponto de quebra é alcançado bem rapidamente como neste caso das fábricas.

Ao pensar em fábricas é comum lembrar de linhas de montagem, funcionários altamente especializados e produção em massa. Tudo isso faz muito sentido em boa parte das fábricas, como as de sapatos, automóveis e componentes eletrônicos, mas não tem grande valor para quem produz software.

Software não se encaixa num modelo de produção em massa e manufatura porque não é repetição. Fazer software é projetar, não construir. Ninguém pensa em fazer o mesmo projeto do mesmo sistema duas vezes, mas muita gente pensa em licenciar para dois clientes diferentes. Fábricas são excelentes para reproduzir produtos idênticos ou com pouca variação, mas projetar software — assim como projetar carros, telefones e praticamente qualquer coisa que se possa imaginar — é um processo criativo que não se adapta muito bem à manufatura. Fábricas são bastante eficientes para reproduzir produtos em larga escala. Só que ninguém precisa de uma fábrica para reproduzir software, uma máquina de prensar discos já basta (sim, desenvolvedores web, ainda existe gente que precisa distribuir software em discos).

Muitos programadores felizmente já notaram que especialização extrema e processos de desenvolvimento repletos de fases — e, conseqüentemente, entregas parciais — não fazem muito sentido. Estas abordagens servem muito bem para reproduzir produtos. Só que software não é feito de madeira e cola, nem de aço e solda. Mas de idéias e bytes. Por causa de sua natureza imaterial, reproduzir software é muito simples e barato. Portanto, o problema da reprodução já está resolvido, o que queremos é projetar software com qualidade e de forma economicamente eficaz. Este é o fator primordial que impede esta analogia de ir tão longe.

Muita gente sabe disso, mas misteriosamente ainda gosta de chamar suas organizações de fábricas. Ao contrário do que possa parecer, alguns desses não são completos idiotas e sabem pelo menos alguma coisa do que estão falando. Quando falam em fábricas, eles não estão pensando em programadores operários apertando parafusos, mas em coisas interessantes como linguagens para certos domínios de conhecimento e frameworks especializados. Apesar disso, essas pessoas fazem esforços tremendos para extrapolar a metáfora e chegam a chamar linguagens de fábricas (é verdade, essa eu vi em uma lista de discussão que, infelizmente, não tem arquivos públicos e não pode ser referenciada aqui). Várias dessas idéias fazem todo o sentido do mundo, mas definitivamente não são fábricas.

Provavelmente muitos dos pesquisadores modernos fazem a analogia por razões históricas e não de forma intencional. O problema é que, devido a sua natureza metafórica, a expressão pode ser mal interpretada e, infelizmente, isso não acontece tão raramente quanto gostaríamos. Tem gente que gosta de fingir que acompanha as novidades do meio acadêmico e já viu a expressão “fábrica de software” repetida várias vezes em títulos de artigos científicos. Mas o título deve ser a única linha que eles lêem. Depois de olhar para o nome, acham que podem organizar suas “fábricas” exatamente como manufaturas juntando programadores aos montes para repetir código e fazer trabalho mecânico em geral. Afinal, parece ser a última moda entres esses cientistas inteligentes e deu certo para as fábricas de sapato na China, não deu?

O resultado são fábricas de software funcionando (ou tentando funcionar) igualzinho a fábricas de sapato. Os programadores que dão o azar de ser tratados como máquinas de costura esperneiam de um lado dizendo que esta é a pior idéia desde a bola quadrada e os pesquisadores esperneiam do outro dizendo que o conceito deles de fábrica na verdade é uma boa idéia que não tem nada a ver com aquilo. Enquanto isso os leitores de títulos continuam a construir mais fábricas segundo seu próprio conceito para perpetuar a confusão.

Boa parte disso tudo simplesmente por causa de uma analogia que foi levada longe demais.

9 Responses to “Fábricas de software – Uma analogia levada longe demais”


  1. 1 Eduardo Miranda

    Muito bom o seu texto Thiago, parabéns.

    Tenho escrito um pouco sobre estes assuntos no meu blog, analogias, processo de desenvolvimento, lean software development. Mas gostaria de compartilhar o post que fiz sobre uma infeliz matéria publicada na Exame que fala sobre as “fábricas da informação”. O assunto é bastante ligado ao que você explica aqui, mas com um agravante: Este modelo de fábrica começa a ser seguido por grande consultorias que desejam exportar software, que têm ao seu lado o governo, interessado no incremento no volume de exportação.

    Vale a pena a leitura:
    http://www.eduardomiranda.net/blogs/dotnet/archive/2007/07/10/remando-contra-a-mare.aspx

  2. 2 Thiago Arraes

    E ae, Thiago. Acho que temos algumas coisas em comum. hahahahaha

    abraços!

  3. 3 Alessandro

    Mesmo o processo de desenho de um carro ou de um telefone, é diferente do projeto de um software, haja vista, que nesse há regras (leis, postulados) que proporcionam um processo determinístico, enquanto neste, não há, ele é fundamentado em um processo não determinístico.

    Com isso, o carro depois de projetado, pode ser construído no modelo de fábrica, linha de produção (pipeline), no qual o trabalho dos envolvidos no processo de produção é independente, quem coloca o motor não precisa saber nada sobre o trabalho daquele que realiza a pintura.

    Eu entendo que quando as pessoas utilizam o termo fábrica de software, elas estão se referindo a um processo determinístico, ou seja, um processo de manufatura, explícito, na segmentação das especialidades (analistas de requisitos, analistas de negócio, projetistas, arquiteto, programador, testador, etc.), o apartheid dos profissionais, não apenas a idéia de fábrica do século XIX.

    “So the approach for software engineering methodologies looks like this: we want a predictable schedule that can use people with lower skills. To do this we must separate design from construction. Therefore we need to figure out how to do the design for software so that the construction can be straightforward once the planning is done.” (FOWLER, The New Methodology, 2005)

  4. 4 fooues

    Essa história de Fábrica de Software / Código .. é péssima! não dá pra desenvolver software como macaquinhos !!!

  5. 5 Guilherme Garnier

    Excelente, o post descreve muito bem a visão que muitas pessoas tem do desenvolvimento de software. São aqueles que vêem pessoas como recursos:

    http://gc.blog.br/2009/07/12/pessoas-nao-sao-recursos/

  1. 1 Motor Curiosidade « On the Next Startup
  2. 2 Fábricas de… software? « Matheus Tardivo
  3. 3 Você não é uma vaca leiteira at Mergulhando no Caos
  4. 4 Não existe segredo: desenvolvedores e designers precisam colaborar entre si | Rafael Ponte

Leave a Reply