I.

Por que é que os programadores e seus empregadores têm diferentes atitudes em relação à qualidade de um projeto?

Pensando em mim mesmo como um programador, às vezes formulava isso dessa forma:

• Os programadores que fazem o trabalho são geralmente os que mais se importam com a “qualidade”. Por quê?
  • Eles têm uma reputação para manter. A baixa qualidade do seu tipo de trabalho é ruim para a reputação entre os seus pares (note que seus pares não são necessariamente seus empregadores).
  • Eles entendem que podem trabalhar no mesmo projeto mais tarde; maior qualidade significa trabalho mais fácil depois, embora às custas de trabalho (mais difícil? em maior quantidade?) agora.
• Os empregadores que estão pagando pelo trabalho se importam muito menos com “qualidade”. Por quê?
  • A reputação do pagador não dependente de como o trabalho é feito, apenas de que o trabalho está feito e de uma forma que possa ser apresentada aos clientes. Observe que os clientes não são principalmente os pares do programador.
  • Eles têm um desejo de pagar o mínimo possível em troca do máximo possível. A “qualidade” geralmente é mais dispendiosa (tanto no tempo, quanto nas finanças) em estágios iniciais, quando os recursos são geralmente mais baixos ou menos seguros.
  • Como um corolário, uma vez que as pessoas que pagam o trabalho não estão fazendo o trabalho, é mais fácil descartar as preocupações com a “qualidade”. Os recursos conservados anteriormente (tanto em tempo quanto em dinheiro) significam maiores recursos disponíveis mais tarde.

Esses pontos são resumidos pelo Redditor JamesTheHaxor, que diz: “A verdade é que ninguém se importa com programadores apaixonados. Podemos avaliar o nível de habilidade de pessoas com base na qualidade do código. A maioria dos clientes não pode. Eles julgam o nível de habilidade de uma pessoa por meio da rapidez com que conseguem fazer algo pelo preço mais barato que funciona de acordo com as especificações. Há muitos codificadores de má qualidade para preencher esse mercado. Eles sempre me prejudicam em sites freelance”.

II

O problema é que o termo “qualidade” significa coisas diferentes para pessoas diferentes. Na situação do programador/empregador, existem duas definições diferentes de “qualidade” em jogo (ou duas coisas diferentes que estão recebendo atenção).

• A “qualidade” do programador se relaciona com o que ele vê, trabalha com regularidade e é responsável pelo tempo (ou seja, o próprio código: o “programa”).
• A “qualidade” do empregador se relaciona com o que ele e os clientes veem, trabalham regularmente e são responsáveis pelo tempo (ou seja, o que é produzido ao executar o código: o “produto”).

A “qualidade do programa” não é a mesma coisa que a “qualidade do produto”. Eles têm diferentes impactos em diferentes momentos do projeto, e têm diferentes níveis de visibilidade para diferentes pessoas envolvidas no projeto. Eles não existem independentemente um do outro, e se alimentam mutuamente; se você alterar um tipo de qualidade, o outro tipo também mudará.

Eu acho que essa desconexão também se aplica a vários ofícios e trocas não relacionados ao software. Você ouve falar sobre carpinteiros, encanadores, pintores, etc, reclamando que eles são prejudicados nos preços por mão-de-obra de baixo custo que não têm o mesmo nível de qualidade. E, no entanto, os clientes que escolhem a opção de menor custo ficam satisfeitos com o nível de qualidade, considerando suas restrições de recursos. O programador-artesão lamenta a baixa qualidade do trabalho, mas o pagador-cliente só quer algo corrigido rapidamente a baixo custo.

Dispensar preocupações com qualidade de qualquer tipo no início pode causar quebras e paradas quando o produto está mais visível ou mais próximo do prazo final, levando a um maior estresse e tensão para fazer o trabalho sob crescente escrutínio público. O programador coloca a culpa da falta de qualidade de código nos problemas, e o empregador lamenta a incapacidade do programador de trabalhar o mais rápido possível no projeto.

O que é interessante para mim é que o programador tenha alguma ideia sobre a qualidade do produto (ele tem que usar o produto de alguma forma ao construí-lo), mas o gerente/empregador/pagador praticamente não tem ideia da qualidade do código (eles provavelmente não estão escrevendo qualquer código). Por isso, é provável que caiba ao programador entender as consequências da qualidade do programa em termos de qualidade do produto.

***

Paul M. Jones faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://paul-m-jones.com/archives/6680