computer-stupidDesculpem pelo longo período sem posts, mas é que estava de férias e aproveitei pra me “desligar” um pouco do computador e esfriar a cabeça.

Hoje quero falar sobre um assunto que sempre gera conflito, como podem observar o título do post.

Mas isto é verdade? Bem, vou deixar aqui “minha” opinião, espero que leiam e reflitam sobre ela e caso não concorde deixe seu comentário baseado em fundamentos. Vamos lá.

De alguns anos pra cá andei observando que muitos programadores sentem “pavor” de certos códigos mesmo que, estes códigos tenham sido desenvolvidos por ele. Mas porque isso acontece?

O que pude observar é que em projetos de software basicamente temos os seguintes requisitos base: Custo, Escopo e o Prazo. Geralmente para que o projeto dê certo, devemos analisar junto ao cliente quais são os dois pontos mais importantes para ele. Observem que eu disse “dois pontos” e não “três pontos”, isso porque devemos fixar dois desses três pontos para que nosso projeto possa fluir da melhor forma possível. Sendo assim, o cliente pode optar por um projeto que terá uma duração de 2 meses (prazo) com um custo máximo digamos de cem mil (custo) deixando assim uma flexibilidade para o Escopo. Ou ainda definir o prazo e o escopo deixando o custo flexível e até mesmo fixando o custo e o escopo, deixando um prazo mais flexível. Isso iria variar de projeto para projeto e de cliente para cliente.

Esta seria a melhor forma de se trabalhar. Porém a realidade é outra. O que se tem nos dias de hoje é que o cliente fixa os três pontos, além de definir em um curto prazo um escopo quase impossível de ser concluído. Isso faz com que percamos as compensações no três itens base, custo, prazo e escopo.

Com base nesse cenário é que começam a surgir os problemas.

Como o escopo é fixo e os recursos também, é no prazo que sofremos, pois estaremos sempre atrasados, obrigando-nos a fazer horas extras, perder fins de semana e por ai vai.

Mas isso ainda não é tudo, o que pesa mais é a cobrança que o desenvolvedor sofre. É uma carga muito pesada para ele carregar. E é justamente nesse ponto que entra uma questão muito importante, “você sabe o que acontece quando você pressiona um desenvolvedor por prazo?”. Bem, posso citar varias coisas mas a principal delas é a QUALIDADE do serviço. Ela é reduzida drasticamente e isso é um fato. Imagino que se os gerentes de projeto tivessem essa informação eles iriam pensar duas vezes antes de se dobrarem sobre os ombros de um desenvolvedor e fazer aquelas famosas perguntas:

– “dá pra andar um pouco mais rápido? “
– “já terminou?”
– “dá pra entregar dia tal?” (essa é de doer!)

O pior disso tudo é que o programador, na maioria das vezes se vê obrigado a aceitar essa pressão e, para que isso aconteça, ele acaba cortando qualidade para atender o prazo. E tem mais, ele não conta que está cortando qualidade (para ficar dentro do prazo estipulado), e o gerente de projeto fica em uma situação ainda pior. Mas há também vezes em que o desenvolvedor sequer percebe que está cortando a qualidade.

É justamente nesse ponto que temos os chamados “códigos mal feitos”, códigos que dão pavor de serem alterados, pois qualquer alteração pode vir a se tornar uma dor de cabeça ainda maior. É onde também, na maioria das vezes ocorre o que chamamos de POG (Programação Orientada a Gambiarra), o desenvolvedor está tão concentrado no prazo que se vê obrigado a fazer de tudo para que o sistema funcione.

O que vem depois disso é ainda pior, o cliente recebe um software mau feito que gera inúmeros erros e na visão dele, o desenvolvedor é visto como um cara que só faz porcaria e que é um incompetente.

Este é um típico caso que já presenciei em várias empresas, esta não é uma realidade fictícia, isso é realmente o que ocorre. O problema é que não fazemos nada para mudar esta situação então deixo aqui aberta uma discussão sobre o assunto e espero que possamos chegar a um consenso para que nossa profissão possa ser vista como primordial e não como um bando de incompetentes.