O Porco Assado e a Engenharia de Software (ES)

Estava escutando um podcast da empresa improveit, que trabalha com consultoria em XP (baixe o zip aqui) e achei muito interessante o conteúdo da palestra…

O Porco Assado 

Certo dia um caçador voltava da floresta com um porco vistoso e gordo o qual seu povo  costumava comer cru. Ao percber que a floresta estava pegando fogo, largou o animal e fugiu. Após o fogo passar, voltou e percebeu que o porco havia queimado. Como estava com muita fome, resolveu comer o porco queimado mesmo, e surpreendeu-se com o sabor agradável, muito melhor que porco cru.

Logo difundiu a idéia para seu povo. Assim, cada vez que queriam comer um porco, largavam-no em uma floresta e colocam fogo na mesma. Após passar o fogo, iam saborear a carne de porco. Com o passar do tempo, surgiram inúmeras empresas de consultoria de como atear fogo em florestas, como fazer o porco ficar próximo a regiões que queimavam mais (porco bem passado) ou menos (porco mal passado), e até certificações em queimar  porco em florestas.

Certo dia um estagiário de uma das empresas sugeriu que o porco fosse posto sob uma fogueira, pois queimaria de forma proporcional, e quem fizesse poderia controlar o fogo melhor. Foi demitido, pois ousou desafiar uma metodologia que estava dando certo, pois porco assado no floresta era um sucesso!

Mas o que essa estória tem a ver com engenharia de software?

Ora, assim como o estagiário propôs uma nova metodologia para  assar o porco (diga-se de passagem muito melhor), porque não podemos propor uma nova forma de desenvolver software? No meu ponto de vista, a ES possui muitos pontos a reconsiderar, e é inaceitável tomá-la como perfeita, consolidada. Dentre as questões a serem repensadas, destacam-se:

• “Engenharia” foi uma metáfora usada em uma conferência da OTAN para se referir ao desenvolvimento de software, é comparada a engenharia civil, mas é muito diferente: a natureza física da Eng. Civil não pode ser comparada a natureza digital da Eng. de Software. Um prédio construído 1 metro fora do esperado não pode ser arrastado para o lado, já um software evolui constantemente. O conceito de gravidade não se aplica ao software, então porque começar o desenvolvimento com uma “base sólida, com pilares fortes” se existem formas de programação que modularizam o sistema (por exemplo Orientação a Objetos)?
• Na cadeia de desenvolvimento de software, o programador é o ser inferior, justo ele que é especialista, que conhece os detalhes do sistema. Ele é preso a um paradigma, a uma série de métricas, e acaba por frustrar-se, faz um trabalho intelectual como se fosse manual (se você aceita comparar as engenharias, sim, o programador é o pedreiro) ;
• Certificações? Quem criou tem referências e moral para isso? Ou procura obter vantagens ($) com fins comerciais, mesmo sendo inconpatível com a realidade da maioria das empresas? Aí as empresas seguem práticas, implementam processos, mudam tudo, apenas para serem certificados…
• Alguém traça uma métrica. Obrigatoriamente essa métrica influenciará no comportamento do que está sendo medido.
• Em 30 anos a indústria de software mudou muito. Mais que qualquer outra. Como comparar a construção de um software (produto altamente intelectual) com um chão de fábrica?

Para mim o grande erro é essa comparação de software com produto (uma casa, um carro). Deve-se comparar um software com o passo anterior do produto, ou seja, as horas que especialistas gastaram para projetar, testar, e desenvolver os protótipos, maquetes, etc. Ai percebemos que é muito mais fácil duplicar um CD com um software do que produzir um carro. Nesse momento o valor agregado no CD desaparece, enquanto no carro este se valoriza.

Por isso, faça com que seu cliente veja seu trabalho, quebre os paradigmas, caso contrário o pensamento de Einstein continuará a se aplicar na ES:

“O barco veleja corretamente, mas no caminho errado”