quarta-feira, 28 de abril de 2010

Fábricas de software

Eu adorei esse texto do Fabio Akita: Fábrica de Software é uma besteira.

Vejam bem, eu não acho que fábricas de software sejam uma besteira. A idéia de se fazer software sob medida para clientes é um excelente modelo de negócios, pois a maioria das empresas não quer investir em um departamento de TI próprio.

O problema, como aponta o Fábio, é a palavra "fábrica." O conceito de linha de produção não se aplica a um trabalho criativo e complexo como o desenvolvimento de software. O modelo de fábrica de software é assim: tem-se um conjunto pequeno de analistas que controla todo o processo criativo e uma horda de micos de realejo que recebem tarefas mastigadas e especificadas detalhadamente e "só" precisam implementá-las. A idéia é reduzir ao máximo os custos, pagando salários altos às poucas cabeças pensantes e baixos aos programadores. Como os salários dos programadores são baixos, as fábricas em geral contratam programadores inexperientes ou aqueles que estão fora do mercado por não conseguirem coisa melhor.

As fábricas em geral usam processos ricos em documentação como o RUP e se orientam pelos modelos de maturidade como CMM e MPS-BR. Elas estão certas em usar esses processos, pois só assim conseguem o grau de controle necessário para garantir que o programador inexperiente vá implementar o que o analista idealizou.

O resultado é que ninguém quer ser programador de fábrica de software, e eu não os culpo. O papel do programador é tal que há poucas oportunidades de crescimento, aperfeiçoamento ou aprendizado. As condições de trabalho são precárias devido ao foco em manter baixos os custos. Os programadores excelentes não querem carregar o piano para os programadores inexperientes, e fogem de lá.

O pior, no entanto, é que o programador é considerado um recurso fungível (essa palavra eu roubei do do excelente livro Slack do Tom DeMarco). O Michaelis define fungível como aquilo que "pode ser substituído por outro da mesma espécie, qualidade e quantidade, como o dinheiro, os cereais, o vinho etc."  Ou seja, se eu tirar uma nota de 20 reais da carteira e te der  em troca de uma nota de 20 reais da sua carteira, não há perda de valor ou qualidade. O dinheiro é um bem fungível - duas notas de mesma denominação tem o mesmo valor.

Ninguém quer ser fungível. É um desrespeito à individualidade de cada um ser tratado como uma peça rapidamente substituível. O pior é que tratar programadores como recursos fungíveis nem funciona, como postula a Lei de Brooks e como já discursaram vários autores, incluindo o Tom DeMarco em Peopleware.

Há alguns anos atrás eu prestei uma consultoria a uma fábrica de software onde o membro mais antigo dentre os 60 programadores estava lá a uma ano e meio, e o tempo médio de permanência de um programador era de 6 meses. Ninguém achava que isso fosse um problema grave, pois havia um fluxo constante de currículos de novos programadores para eles contratarem e substituirem os que saiam. Se na sua empresa se referem a você como "o recurso," corra léguas.

Eu gostei muito da sugestão do Fábio de se trocar o conceito para "atelier de software". Isso me faz pensar em um local onde se misturam artesãos experientes e aprendizes, que trabalham juntos em todas as etapas do processo, dando aos aprendizes a oportunidade de crescerem e se tornarem mestres. Quem sabe isso não dá mais certo?

terça-feira, 27 de abril de 2010

Resultados da pesquisa sobre salários de programadores - parte 3 - experiência

Na última postagem vimos que há uma correlação direta entre escolaridade e salário. Hoje vamos ver que o mesmo não acontece com o tempo de experiência. O gráfico abaixo mostra que os salários estão espalhados por todo o espectro e que ter mais experiência não significa necessariamente ter um salário mais alto.

Por que será? Eu tenho algumas teorias. Primeiro, lembrem-se que a pesquisa era para profissionais que atuam com programação. Acontece que no Brasil é difícil seguir uma carreira longa atuando como programador. Programadores experientes acabam se transformando em "analistas" que não programam, ou então são levados a atuar na área gerencial.

É uma pena. A programação é uma atividade difícil que leva muitos anos para se aprender a fazer bem feito. Quando os programadores estão começando a ficar realmente bons, são obrigados a mudar de carreira pelas "forças de mercado". Eu já entrevistei dezenas de candidatos ao cargo de engenheiro de software e posso afirmar que é raríssimo encontrar um programador no Brasil com mais de 10 anos de experiência de mercado, e quem dirá com 20, 30 ou 40 anos de experiência. Esses profissionais existem em qualquer outra área, mas não na programação.

Olhem o gráfico novamente. A vasta maioria dos pesquisados tem 6 anos ou menos de experiência. É muito pouco para haver uma variação significativa de salário. Dentro dessa faixa de experiência, é mais provável que outras variáveis tenham uma influência muito maior sobre os salários, como a escolaridade, região, tipo de atividade, e assim por diante.

Onde estão os programadores com 20 anos de experiência? Deixem-me fazer uma pesquisa pessoal. No final desse ano completarei 20 anos de formado. Na minha turma formaram-se 25 cientistas da computação. Quantos deles ainda trabalham com programação? Não tenho certeza, pois perdi o contato com muitos deles. De cabeça, só consigo pensar em um: eu. Só que eu não passei esses 20 anos programando, não tenho 20 anos de experiência. Acredito que deva haver pelo menos 2 ou 3 outros na minha turma que ainda programam, mas não mais do que isso. Em outubro haverá minha reunião de turma, e aí saberei ao certo. Prometo contar pra vocês.

E isso tudo quer dizer que então não há esperança para quem quer seguir carreira de programação? Há sim. À medida em que a indústria amadurece, as empresas percebem cada vez mais o valor dos programadores experientes. Na América do Norte já é comum existir planos de carreira puramente técnicos para aqueles que não querem transitar para o ramo gerencial. Aqui também isso é cada vez mais frequente, principalmente em empresas cujo ramo principal de atividade é a informática. Se você gosta de desenvolvimento de software, pode seguir em frente que você só vai ter de parar quando quiser.



quarta-feira, 24 de março de 2010

Resultados da pesquisa sobre salários de programadores - parte 2 - escolaridade

Hoje vamos ver os resultados de escolaridade. O gráfico abaixo mostra o maior grau alcançado por cada participante. Como podemos ver, a grande maioria dos participantes tem graduação em alguma área relacionada à computação. Apenas um dos participantes tinha doutorado e, portanto, não aparece nos resultados. Aliás, isso reforça minha triste suspeita de que há muito poucos doutores no Brasil envolvidos em atividades de programação.

Mais interessante é o gráfico de salários médios. Como podemos ver, o salário médio cresce de acordo com a escolaridade. Parece bom, mas isso nos leva a uma pergunta: quanto vale, por exemplo, um mestrado?

Para responder a essa pergunta, vamos considerar apenas a região Sudeste para reduzirmos os efeitos regionais. A média salarial do graduado no Sudeste é de R$ 3.586,00. Já a média salarial do mestre é de R$ 5.107,00. A diferença é de R$ 1.521,00. Suponhamos que essa diferença se mantenha constante ao longo da carreira. Se o programador obtém o mestrado aos 25 anos e trabalha até os 60 anos, são 35 anos * 12 meses * R$ 1.521,00 = R$ 638.820,00. Ou seja, vale a pena fazer o mestrado, mesmo que você tenha de fazer um empréstimo no banco para pagar.

É claro que não podemos ter certeza que há uma relação causal entre escolaridade e salário - pode ser que haja algum terceiro fator que ao mesmo tempo leva a pessoa a buscar um grau maior de escolaridade e a ter um emprego melhor. Não é garantido que fazer um mestrado ou uma pós vá melhorar seu salário.

Aliás, eu sempre digo isso quando faço em universidades minha palestra sobre o que fazer depois de se formar: um diploma ou outro título te ajuda a conseguir um emprego, mas não te ajuda a ficar nele. Não leva mais do que três meses para um empregador perceber se o diploma é só um pedaço de papel ou se tem valor real.





terça-feira, 23 de março de 2010

Para que serve o teste de software?

No final de janeiro eu fui a Melbourne (na Florida, não na Austrália) participar do Workshop on Teaching Software Testing, onde professores acadêmicos, instrutores de cursos em empresas e testadores praticantes da indústria se reuniram para trocar suas experiências sobre ensino de teste. O tema de discussão este ano era o teste com base no código. Éramos 22 participantes dos Estados Unidos, Canada e eu do Brasil. Seguem alguns pontos que foram abordados nas discussões e que eu achei relevantes.

A maioria dos programadores e principalmente estudantes norte-americanos dos programas de graduação em Engenharia de Software não acham que precisam testar seus programas com rigor - aqui rigor não significa nem formalismo matemático, nem exaustão, uma vez que é impossível, mas sim uma forma sistemática do programador testar seus programas munido de técnicas apropriadas. A maioria dos programadores dá um tiro no próprio pé fazendo alguns poucos testes aleatórios. Por mais que a universidade tente mostrar a necessidade e que o teste seja também papel do desenvolvedor/programador, os alunos só se convencem disso quando vão para o mercado.

As experiências no ensino de desenvolvimento dirigido por testes (TDD) são frustrantes. A maior parte dos alunos não utiliza a metodologia pois TDD não pode ser considerada um técnica por si só. E uma vez que é apenas uma metodologia, é dificil para os professores exigirem dos alunos a aplicação da mesma. Mesmo sabendo que serão penalizados, os alunos não aplicam o TDD e só criam os casos de teste após terem escrito o código. Estou falando de TDD quando o assunto é teste, mas sabemos que as grandes contribuições de TDD estão na evolução de um bom projeto, no entendimento maior do problema em questão antes da codificação. Desta forma, os alunos que imaginam que só precisam criar casos de teste e que tanto faz antes como depois do código perdem o melhor da metodologia. São os profissionais com essa atitude que chegam ao mercado.  Se TDD fosse aplicado desde as primeiras disciplinas de programação, talvez assim os alunos percebessem a
vantagem da abordagem. Algumas universidades americanas vão investir neste caminho.

No passado, teste servia o propósito limitado de detectar erros nos programas. Através da quatidade de erros encontrados no programa era possível derivar dos testes um indicador da qualidade do programa. Esse era o tempo em que os programas eram monolíticos ou compostos de pequenos módulos. Hoje em dia cada componente utilizado é de uma complexidade grande e possui suas próprias características intrínsecas. Princípios de ocultação de informacao e interfaces bem definidas foram aplicados e a engenharia de software se orgulha destes avanços. No entanto, o comportamento de um determinado módulo ou componente precisa ser descoberto pelo programador que usa este módulo ou componente, e a maneira de descobrir este comportamento é através de testes. Muitas vezes a documentação é escassa ou descreve bem o que se espera que o componente faça, mas na verdade o comportamento dele é um pouco diferente. Este propósito do teste de descobrir ou certificar o comportamento dos componentes é completamente diferente do propósito de detectar defeitos. Quais técnicas de teste devem ser usadas neste caso?

Produzir casos de teste relevantes continua sendo o problema mais difícil de se resolver em testes, principalmente no teste considerando o código. Como o Torsten disse anteriormente, se o foco de teste passa a ser a cobertura no sentido que passei por aqui, é melhor projetar os casos de teste antes de escrever o código e com base na sua especificação. Mas será que usaríamos os mesmos casos de teste para testar as três versões de código abaixo da função fatorial? (exemplos de código fornecidos por  Nawwar Kabbani - participante do workshop.)

public intfactorial (intn) {
  if(n == 0)
    return 1;
  else
    return * factorial(n –1);
}


public int factorial (int n) {
  if (n == 0) return 1;
  else if (n == 1) return 1;
  else if (n == 2) return 2;
  else if (n == 3) return 6;
  else if (n == 4) return 24;
  else if (n == 5) return 120;
  else if (n == 6) return 720;
  else if (n == 7) return 5040;
  else if (n == 8) return  40320;
  else if (n == 9) return  362880;
  else if (n == 10) return 3628801; // this one looks odd!
  else if (n == 11) return 39916800;
  else if (n == 12) return 479001600;
  else return -1; // or throw an exception..
}


private static final int FACTORIAL_CACHE[] = new  int[]
{1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880,
362801, 39916800, 479001600};

public int factorial (int n) {
  return FACTORIAL_CACHE[n];
}

Com certeza, vendo os três códigos conseguimos pensar em casos de testes que gostaríamos de fazer. Alguns com base na definição do fatorial, outros com base no código que foi apresentado. No último caso a cobertura não vai ajudar em nada.

Para terminar, eu recomendo fortemente o mini curso do Doug Hoffman que participará do Encontro Brasileiro de Testes de Software (IV EBTS) , ele na minha opiniao é um grande praticante com muitas estórias de sucesso sobre testes de software para contar. Seu objetivo é coletar várias estórias para compor um livro que possa ajudar a comprovar os diversos propósitos de testes e sua necessidade para a sobrevivência dos programadores.

sexta-feira, 19 de março de 2010

Resultados da pesquisa sobre salários de programadores - parte 1 - dados agregados por estado

Custou, mas começou a sair. Foram 247 respostas distintas (na verdade já são 270, mas eram 247 quando fiz o corte, depois eu atualizo com os novos dados). Nossos agradecimentos a todos que responderam.


Hoje vamos ver os dados agregados por estado. Para criar a visualização, usei a fantástica, sensacional ferramenta gratuita Tableau Public. Não tenho palavras pra dizer o quanto essa ferramenta é legal. Ela permite criar visualizações interativas que você pode incluir no seu site.


O mais importante ao investigar os resultados da pesquisa é saber que não se trata de uma amostragem aleatória e, portanto, não se pode tirar conclusões generalizáveis. Como se pode ver pelo gráfico abaixo, predominaram as respostas vindas de Minas Gerais, o lar do Micos, e da Paraíba, graças ao Guilherme Germoglio que espalhou a notícia. Naturalmente, não podemos dizer que esses dois estados concentram a maioria dos programadores do Brasil.


Dentre os que declararam o local onde trabalham, excluí para esse gráfico todos os que trabalham fora do Brasil e os residentes do Piauí e do Pará, pois cada estado contribuiu com uma única resposta.


O gráfico nos mostra alguns dados interessantes: tanto a média salarial quanto o nível de experiência dos programadores do Nordeste está bem abaixo da média dos de outras regiões. Por outro lado, o nível de satisfação médio é bastante uniforme em todos os estados. Nota-se uma discrepância na média salarial do Distrito Federal, muito acima da média nacional.


Experimentem brincar com o gráfico abaixo selecionando, por exemplo, apenas os programadores que tem graduação, ou apenas aqueles com 3 anos ou menos de experiência.



Semana que vem tem mais.

segunda-feira, 8 de março de 2010

Feliz Dia Internacional da Mulher

Hoje é Dia Internacional da Mulher. Eu já fui defensor ávido e batalhador pelo crescimento do número de mulheres na computação, mas um dia fiquei tão frustrado que desisti publicamente. Só que semana passada a Guta me mostrou uma apresentação super legal da Pamela Fox, do Google, chamada I'm a Barbie Girl in a CS World. Ela fala sobre a experiência dela de ser mulher na computação. Vale a pena conferir. Me fez crer que ainda há esperança.

A Guta achou o link para a apresentação no meio de uma discussão que está acontecendo na lista da Sociedade Brasileira de Computação (sbc-l) sobre a nova boneca Barbie que foi lançada, cuja profissão é Engenheira de Computação. Tem gente que achou bom, tem gente que achou ruim. Eu, pessoalmente, achei a boneca de muito bom gosto e vou comprar duas, uma pra cada uma das minhas filhas.

terça-feira, 2 de março de 2010

Pesquisa sobre remuneração de programadores

Olá caros leitores,

A equipe do Micos de Realejo está escrevendo um grande post sobre o estado atual da remuneração na indústria de software. No entanto, estamos sentindo falta de dados concretos e contamos assim com a colaboração dos leitores.

Elaboramos uma pesquisa curta que deve levar cerca de 3 minutos para responder. A pesquisa é destinada apenas àqueles que de alguma forma trabalham com programação.

A pesquisa é totalmente anônima, todas as questões são opcionais e dados individuais não serão divulgados. Divulgaremos apenas resultados agregados.

Por favor divulguem para seus colegas para que possamos obter uma quantidade significativa de dados para análise.

O link para a pesquisa é: http://bit.ly/9FpAPV

Obrigado,
Torsten