A Escassez Relevante

Um dos blogs que leio regularmente é o Marginal Revolution, do economista Tyler Cowen. No blog e em um dos livros dele, Discover Your Inner Economist, ele diz que todo bom economista ataca um problema perguntando, "qual é a escassez relevante que impede um resultado melhor?"  Essa é uma pergunta profunda e importante para o desenvolvimento de software, mas como esse não é um blog de economistas, deixem-me explicar melhor.

Todo esforço humano é motivado por alguma escassez. Plantamos porque não há comida em abundância para todos na natureza. Construímos casas porque não há abrigos em abundância. Abrimos restaurantes porque para muitos falta tempo, habilidade ou vontade para cozinhar. Guardamos dinheiro em bancos porque falta segurança em nossas casas para deixar nosso dinheiro lá, ou para o carregarmos conosco. Cada solução útil que existe ataca alguma escassez. Essa é a escassez relevante ao problema.

Quando falamos de projeto de software, qualquer gerente pode te falar sobre escassez: falta tempo, falta dinheiro e faltam bons desenvolvedores. Agora, e quando falamos sobre um produto de software? O que é a escassez relevante para um sistema?

Ora, falar sobre a "escassez relevante" é apenas uma forma concreta de se determinar qual é o problema que um sistema resolve (releia A Mesa Errada para entender mais sobre a importância de se resolver o problema certo). Se todo esforço humano é motivado por alguma escassez, então todo sistema de software bem sucedido também deve atacar alguma escassez.

Na maioria dos casos, a escassez que o software ataca é a escassez de tempo. O Microsoft Word existe porque é mais rápido escrever um texto com ele do que com um lápis ou uma máquina de escrever. O Excel existe porque é mais rápido fazer contas com ele do que com uma calculadora. E-mail existe porque é mais rápido se comunicar com ele do que usando os correios. Diminuir o tempo necessário para se executar uma tarefa é um dos grande motivadores por trás dos primórdios da indústria de software.

Outra grande escassez, essa atacada mais recentemente, é a de informação. A Google inteira se baseia nessa escassez, seja ela genérica (google.com) ou específica (google maps). Grande parte da internet ataca esse problema.

Às vezes, no entanto, a escassez relevante não é tão óbvia. Façamos um pequeno exercício. Qual a escassez relevante em cada um dos sistemas abaixo?

• Twitter
• Google Wave
• Orkut

No caso do Twitter, desconfio que a escassez relevante seja a atenção. É preciso ter alguns minutos livres para se concentrar e ler um artigo como esse, mas bastam alguns segundos para se ler várias mensagens de 140 caracteres. O mesmo vale para se escrever: poucos tem a paciência de escrever um texto, mas qualquer pessoa consegue pensar em algo para se dizer em uma frase. O twitter não faz nada que não fosse possível fazer antes dele, mas ataca uma escassez diferente.

Colocar o Google Wave nesse exercício é um truque pra ver se vocês estão prestando atenção. É um produto que não foi bem sucedido, talvez porque, apesar de tecnologicamente avançado, não atacasse nenhuma escassez relevante.

E o orkut? É um produto bem sucedido, mas qual o problema que ele resolve? Com certeza ele existe, mas deixo a solução desse problema como exercício para o leitor. Eu é que não vou me arriscar a responder.

Palestras na UFV

Ontem estive na Universidade Federal de Viçosa para ministrar duas palestras:

• Terminei, e daí? Optando entre a carreira acadêmica e a indústria de software.
• Desenvolvimento de aplicativos web usando Google Web Toolkit e Google App Engine.

Tudo como parte da semana de informática. Foi muito divertido e eu ainda pude conhecer o bonito campus da Universidade e bater um papo com os professores do depto. de Informática.

Muito obrigado ao pessoal da UFV por me receber tão calorosamente!

Custos perdidos

Eu gosto de ler livros populares sobre economia, estilo Freakonomics. Assim vou aprendendo alguns conceitos que acho interessantes. Um dos conceitos de economia que acho mais relevantes não só para o trabalho mas para a vida em geral é o de sunk costs (em portugês, "custos perdidos", "custos irrecuperáveis" ou "custos enterrados").

Custos perdidos são aqueles que você já teve com um projeto qualquer e que não tem como recuperar. O importante sobre custos perdidos é que você não deve levá-los em conta para tomar decisões sobre o futuro. Afinal de contas, o que passou, passou. O que vale é o que se tem hoje e o que vem pela frente.

Por exemplo, suponha que você tenha uma caixinha de açafrão legítimo, a especiaria mais cara do mundo, mais cara que o ouro. Você deve fazer uma paella? Você vai ao supermercado e descobre que vai te custar 100 reais pra comprar os outros ingredientes. E aí, faz a paella ou não? Pois para tomar essa decisão, você só deve considerar o custo dos ingredientes restantes e o valor que você atribui à paella. Não importa se pelo açafrão você pagou 10 reais, 100 reais, 500 reais, ou se você ganhou de presente da sua vó. Mas se eu não fizer a paella, vou desperdiçar o açafrão! Vai sim, mas vai estar 100 reais menos pobre.

E o que isso tem a ver com desenvolvimento de software? Tudo. Projetos de software são cheios de surpresas: atrasam, precisam de mais máquinas do se imaginava, de mais pessoas, de mais dinheiro. À medida em que o projeto caminha, mais precisa fica nossa estimativa, como mostra a figura abaixo:

O que fazer quando percebemos que erramos nossa estimativa inicial e que tudo vai ser mais caro ou demorado do que se esperava? Nessa hora, é preciso decidir se devemos cancelar ou não o projeto. Para tomar essa decisão, não importa o quanto tempo e dinheiro já foram gastos com o projeto. O que importa é o quanto ainda vai ser gasto. Ou seja, o que devemos nos perguntar é, "acho que vou gastar X tempo ou dinheiro para terminar esse projeto. Eu tenho X tempo ou dinheiro? quero investir X nesse projeto?"

Essa é a ação racional a ser tomar.

Infelizmente (ou não), as pessoas não são racionais. Seres humanos têm aversão a perdas, e jogar fora algo que já se conquistou é dificílimo, mesmo que não fazê-lo seja irracional. Um exemplo clássico disso é o do ingresso de cinema. Imagine as seguintes situações:

Situação A: Você compra ingressos para o cinema pela internet, por 20 reais. Só que quando chega ao cinema, descobre que o bolso está furado e que perdeu os ingressos. Você tem 20 reais no outro bolso. Você vai ao cinema?

Situação B: Você vai ao cinema. O ingresso custa 20 reais. Só que quando você enfia a mão no bolso, você descobre que o bolso está furado e que perdeu uma nota de 20 reais. No outro bolso, você tem outra nota de 20 reais. Você vai ao cinema?

Se você é como a maioria das pessoas, você se sente mais confortável em ir ao cinema na situação B do que na situação A, apesar do resultado das duas situações serem idênticos, ou seja, você está 40 reais mais pobre e foi ao cinema, ou 20 reais mais pobre e não foi ao cinema. O fato de comprar de novo ingressos que você já comprou é dificílimo para a maioria. Um ótimo livro que trata desse tipo de comportamento é Previsivelmente Irracional, de Dan Ariely.

Você mesmo deve ser assim. Quantas vezes você continou assistindo a um filme muito ruim só porque já tinha assistido metade? Quantas vezes ficou em um lugar desagradável porque "já vim até aqui mesmo"? Quantas vezes comeu comida ruim só porque sua mãe ensinou que não se deixa comida no prato? Se você não comer, ninguém vai comer o resto do seu prato, então já era - custo perdido. Melhor não comer.

E daí? E daí que, mesmo sabendo que você não deve levar custos perdidos em conta para tomar decisões, você precisa se lembrar que as pessoas levam os custos perdidos em conta. Todos ficam tristes e aborrecidos quando seu tempo e esforço são inúteis. Já dizia meu querido orientador Don Cowan, "não se apaixone pelo seu trabalho, você pode ter de jogá-lo fora." Se já é doloroso jogar fora seu próprio trabalho, imagine se outra pessoa é quem decide jogá-lo fora. A reação natural é de raiva, revolta, desgosto. Se você trabalha em uma equipe e decide cancelar um projeto, lembre-se que é preciso valorizar e compensar o esforço que já foi feito. Então, muito cuidado quando for você o responsável por essa decisão.

Resumindo:

• se for tomar uma decisão para você mesmo, não leve em conta os custos perdidos;
• se for tomar uma decisão para sua equipe, lembre-se que os outros (mas não você, claro) são irracionais e não vão entender bem esse lance de "custos perdidos"

O ambiente de trabalho e a produtividade

Sem querer, o artigo mais polêmico desse blog até hoje foi um em que falei mal de móveis. Um dos fatos que achei mais curiosos sobre a reação dos leitores foi que muitas pessoas parecem não se importar com a qualidade do espaço físico em que trabalham. De fato, existem muitos fatores importantes ao se escolher um emprego - o respeito, a autonomia, os desafios, as possibilidades de crescimento, entre outras. Hoje, no entanto, gostaria de refletir sobre a importância do espaço onde trabalhamos.

Todos nós prezamos pelo conforto dos nossos lares. Gastamos quantidades imensas de tempo e dinheiro para fazer de nossas casas lugares agradáveis de se passar o tempo, bonitas, serenas e confortáveis. No entanto, a maioria de nós passa muito menos horas acordados dentro de nossas casas do que passamos no trabalho. Por que, então, não fazemos o mesmo com o local onde trabalhamos? Por que passar o dia em lugares apertados, barulhentos, estéreis, iluminados de forma desagradável? Eu não entendo.

O tratado mais interessante sobre espaço físico que já li está no livro Peopleware: productive projects and teams, um clássico do Tom DeMarco e Timothy Lister. O livro trata da produtividade de profissionais da área de informática e dedica um dos seus seis capítulos inteiramente aos efeitos do espaço físico na produtividade. Vou resumir aqui algumas das conclusões do livro a ainda incluir outros estudos. Vamos por partes.

1. Espaço de trabalho

O Peopleware cita um estudo muito interessante feito pela IBM em 1978, motivado pela construção de seu novo campus em Santa Teresa, Califórnia. Durante o estudo, observaram o trabalho no dia-a-dia de inúmeros profissionais da IBM e chegaram à conclusão que profissionais dessa área precisam de, no mínimo, 9 m² de espaço individual por trabalhador, sendo que 3 desses 9 m² devem ser de área de trabalho - ou seja, mesas. Valores inferiores a esses levavam à reduções na produtividade devido ao barulho, interrupções e dificuldade em se manejar materiais. Essas reduções levariam a perdas maiores do que o custo de se manter o espaço adicional.

E que custo é esse? Não sei dizer o preço vigente de aluguéis de escritórios pelo Brasil, mas em uma rápida busca descobri que em São Paulo o metro quadrado de salas está por volta de R$ 50,00 por mês. Ou seja, se hoje a empresa tem 4 m² por desenvolvedor, o custo para se passar para os 9 m² recomendados pela IBM seria de R$ 250,00 por mês, por desenvolvedor. O custo de se mobiliar esse espaço com os 3 m² de mesa de boa qualidade é bem menor do que esse se considerarmos a amortização com o tempo. Se a produtividade média aumentar em 10%, é um investimento que vale a pena. Mas será que a produtividade aumentaria em 10%? Vamos continuar.

2. Ruído e interrupções

O trabalho intelectual exige concentração. A maior produtividade do desenvolvedor vem quando ele entra no estado chamado de fluxo, em que está totalmente absorvido pela sua atividade e não vê o tempo passar. Você já teve desses dias, não teve? Aquele dia em que se sentou na frente do computador e quando viu, já eram duas horas da manhã. Esse é o estado de fluxo.

Um indivíduo leva entre 10 e 15 minutos para entrar nesse estado. Isso implica que, a cada interrupção, o estado de fluxo é quebrado e é difícil retomar a atividade anterior. Para se produzir mais, é preciso minimizar as interrupções. Em uma entrevista recente, Jason Fried, fundador da 37signals, declarou que lá se faz de tudo para minimizar interrupções - evita-se usar o telefone quando possível e prefere-se usar e-mail. Também alocam longos blocos de tempo para o trabalho produtivo em que as pessoas evitam interromper quem está trabalhando.

Os estudos citados no Peopleware confirmam essa necessidade. Trabalhadores que consideram seu ambiente silencioso cometem, em média, menos erros que os que o consideram barulhento. Quanto maior a densidade de pessoas, maior o ruído e mais frequentes as interrupções. Como é possível trabalhar quando a todo instante um telefone toca, ou alguém está contando algum caso, ou há uma discussão intensa acontecendo a dois metros de distância?

Ora, quando mais apertado o espaço de trabalho, maior o ruído percebido. Um estudo interessante da Cornell University demonstrou que níveis de ruído altos trazem diversos prejuízos à saúde e ao desempenho, mesmo quando as pessoas expostas ao ruído não acham que o ruído está atrapalhando.

O que as pessoas fazem hoje para escapar do ruído é refugiar-se em seus headphones, ouvindo música alta para fugir das interrupções, o que também não é bom para a concentração.

3. Iluminação

A maioria dos ambientes de trabalho hoje em dia, especialmente os ambientes de empresas de informática, é iluminado em excesso. É provável que nada tenha contribuído mais para a desumanização dos espaços interiores do que o advento da luz fluorescente longa. Por ser de baixo custo, ela permeia os interiores com um espectro desagradável e que ainda pode causar dores de cabeça, fadiga e stress. O fato é que a maioria dos ambientes pode ser iluminado durante o dia apenas com a luz natural que vem das janelas e algumas luzes indiretas.

Eu não entendo porque praticamente se aboliu o uso da luz natural, que é mais saudável e agradável. Se você não acredita em mim, experimente ir ao escritório em um fim de semana, desligar as luzes e abrir todas as persianas. Depois tente trabalhar durante algumas horas e me diga se não se sente melhor. Se você ainda não acredita, pergunte a qualquer arquiteto ou decorador. Você não usa essas luzes fluorescentes compridas na sua casa e há um bom motivo para isso. Não use no trabalho também.

Resumindo

O trabalho produtivo precisa de:

• espaço
• silêncio
• iluminação adequada

O custo para se ter isso não é alto e é mais do que justificado em ganhos de produtividade e na satisfação e saúde dos trabalhadores. Mais do que isso, no entanto, trabalhar em um local agradável é uma necessidade humana. Todos somos atraídos pelo que é bonito, estético, confortável. O grande arquiteto Christopher Alexander (aquele que inspirou a gang dos quatro a criar os padrões de projeto) chama espaços com essas características de orgânicos - espaços que mesclam as necessidades do indivíduo com as necessidades coletivas, que exibem personalidades que harmonizam com a natureza.

Trabalho é vida e todos queremos viver bem. Cuide de seu ambiente de trabalho como sua casa, porque assim ele é.

Se você quer ler mais sobre o assunto, essa página tem um bom apanhado de links.

A Complexidade da Privacidade Online

O artigo de hoje é de autoria do colega Daniel Balparda, que é um entusiasta dos temas de segurança e privacidade em sistemas. Vamos a ele!

-----------------------------------------------
Trabalho diariamente com dados sensíveis de usuários e já trabalhei com segurança de dados, então um fato curioso ocorrido comigo me chamou a atenção e me despertou a vontade de compartilhá-lo.

Wardriving é uma atividade usada normalmente para mapear dados de redes sem fio, mas está mais associada à quebra de privacidade (se tanto!) de quem possui tais redes sem fio abertas, mas não de quem coleta os dados. Consiste em dirigir (ou pedalar ou andar) portando um dispositivo que consiga ler dados de GPS e dados de redes sem fio para que seja feito um mapa associando redes sem fio à sua posição geográfica. Encontrei um exemplo interessante de como uma atividade como esta pode vazar dados privados de forma subliminar.

Os "smartphones" Android, da Google, têm um programinha (Wardrive) que coleta dados de redes e depois faz o upload para um mapa online, onde os dados coletados por usuários no mundo todo são anonimizados e coletados para consulta. Resolvi olhar o mapa na minha região e me deparo com uma linha de pontos de rede, que como os farelos de pão de João e Maria, levam diretamente à minha casa.

A explicação foi trivial depois que eu forcei a memória e me lembrei o que aconteceu. Uma vez, quase um ano atrás, um colega de trabalho foi à minha casa, e resolveu testar seu programa de wardriving no caminho. Como são pouquíssimos dispositivos Android na minha cidade, e pelo visto menos pessoas ainda usando o programa em questão, ficou o rastro deste dia no mapa como os únicos dados da região até hoje. Um ano depois, ainda constavam como os únicos e mostram o caminho exato entre o centro da cidade e a porta da minha casa.

Claro, minha privacidade não está grandemente ameaçada (os dados não são muito precisos e meu endereço pode ser descoberto de 1001 outras formas), mas achei o exemplo bem curioso. Um mapa silenciosamente aponta para a minha casa, em um site obscuro, que eu desconhecia, por mais de ano, e por nenhuma ação ou culpa minha.

Comecei a coletar e fazer upload de algumas outras rotas de "wardrive" na minha região para mascarar este efeito, então em breve o mapa vai mudar. Nada como mascarar dados com mais dados...  ;-)

Estão aparecendo diversas pesquisas indicando que anonimizar verdadeiramente qualquer coisa online é um problema muito maior do que se cria inicialmente. Basta pensar que somos hoje em torno de 6 bilhões de pessoas no mundo. Se considerarmos 2 bilhões de usuários únicos online hoje, isto significa que quaisquer 31 bits significativos de informação seriam suficientes para identificar um usuário hoje. Não é muito! Dois exemplos recentes de pesquisas na área que me vem à cabeça são:

1. O conjunto de todos os dados disponibilizados por um browser ao navegar (meu sistema operacional, browser, versão, resolução, fuso-horário, quais fontes estão instaladas no meu sistema, quais plugins eu instalei, etc) pode ser suficiente para identificar um browser unicamente ou quase unicamente no mundo. Pense um pouco: se você já baixou plugins para seu browser e já configurou fontes extras além das que vêm instaladas no seu sistema operacional, sua configuração provavelmente já é única! Estes dados podem ser coletados e trocados de site em site para rastrear sua presença online. Basta um site ligar sua identidade de browser à sua identidade real que é fim de jogo: eles sabem quando você aparece e sabem quem você é.
   
   
2. Através de links visitados para suas comunidades em redes virtuais é possível triangular e encontrar a identidade de um usuário em redes sociais fazendo apenas perguntas para o browser. O usuário não vê nada. Explicando rapidamente, o browser normalmente troca a cor de links visitados (o mais usual é azul para links não visitados e roxo para links visitados nos últimos meses). Um site maldoso não teria usualmente acesso aos cookies de redes sociais, mas ele pode gerar de forma escondida uma lista de links para, digamos, as 1000 comunidades mais populares do Orkut. Ao servir esta lista (mesmo que escondida) para o usuário o browser irá muito prestativamente colorir os links já visitados com a cor diferente. Ora, a cor exibida de facto pode ser consultada pelo programa e reportada de volta ao site malicioso. Mais uma vez, o conjunto de comunidades populares escolhidas por um usuário dentre 1000 pode muito facilmente ser único. Game over. Você foi identificado.

Para quem não viu, os links acima valem 10 min do seu tempo, creio.

Configurando sua mesa de trabalho

Eu fui forçada a aprender como configurar meu ambiente de trabalho. Claro, isso só aconteceu depois que eu já tinha sofrido minha primeira lesão. O profissional de computação sofre uma pressão grande nos diversos tipos de atividades em que se envolve. Isso gera tensão extra nos músculos que, quando posicionados de forma inadequada por longas horas, podem sofrer impactos irreparáveis em sua coluna, músculos, e articulações.

Só quando eu comecei a sentir dores horríveis no meu braço direito foi que eu percebi que algo estava errado. Eu tinha 10 anos de profissão nessa época. Passava horas trabalhando no computador sem nem perceber. Mas claro, na hora de finalizar o doutorado, quando eu mais precisava da minha saúde 100%, eu comecei a sentir muitas dores.

Nossa pesquisa neste blog sobre o mercado de trabalho não me deixa mentir. Os profissioanis da área que passam longas horas na frente do computador são jovens. E quando a gente é jovem achamos que podemos tudo. Mas juventude a gente só tem uma vez e eu posso dizer que consegui preservar a minha. :)

Li muitos livros sobre LER, ergonomia de cadeiras, mesas, teclados e mouses, sobre ginástica laboral, fui a vários fisioterapeutas, massagistas, fiz yoga, (hoje eu faço Tai Chi Chuan), passei a fazer exercícios específicos para movimentar partes do corpo que mais sentem com estas longas jornadas, parava 5 minutos a cada hora, mas principalmente investi no meu novo ambiente de trabalho com a ergonomia correta.

Algumas coisas que eu recomendo fortemente:

• Leia sobre ergonomia: http://ergo.human.cornell.edu/CUEHinfo.html
  
  
• A escolha da cadeira: leia e pesquise a que for correta para você, suporte no contorno completo da sua lombar é muito importante.
  
  
• Posicione a cadeira na altura adequada: seus pés devem ficar com a planta toda encostando no chão. Seus joelhos devem fazer um ângulo de 90 graus com suas pernas. suas coxas devem estar paralelas ao chão.
  
  
• O teclado deve ficar posicionado apontando ligeiramente para baixo: Isso faz uma diferença enorme no tanto de esforço desnecessário que colocamos no nosso pulso. Eu comprei uma bandeja que me permite ajustar a altura do teclado e também o ângulo dele e provavelmente foi um investimento excelente. Não precisei trocar minha mesa, instalei a bandeja na própria mesa. A bandeja é essa: http://www.fellowes.com/ca/site/products/ProductDetails.aspx?culture=en&Id=8036001
  
  
• Veja esta página para saber a posição ideal para se digitar: http://ergo.human.cornell.edu/AHTutorials/typingposture.html.
  
  
• Eu uso uma trackball ao invés de mouse que facilita muito os movimentos. Neste caso o pulso, que foi minha área de maior problema, fica parado sem precisar fazer o movimento esquerda-direita que danifica os tecidos. A trackball grande preenche o espaço curvo natural da mão sobre o mouse e posso usar qualquer dos dedos para movimentá-la dividindo o estress sobre os músculos. Essa trackball me durou uns 7 anos e me senti completamente aleijada quando precisei usar um mouse por uma semana quando ela estragou. Logo repus o anterior com um outro do mesmo modelo. Ele é fantástico. Esta página tem diversas reviews sobre trackballs: http://www.trackballmouse.org/. Eu uso o Logitech trackman marble mouse.

Pense na melhor configuração da sua mesa de trabalho. Sua saúde e juventude vão agradecer.

Condições de trabalho

Estava agora folheando a revista "BHTI", que fala do mercado de TI em Belo Horizonte, quando me deparei com a reportagem "Turnover: quem dá mais?" que é interessante mas que contém uma foto mais interessante ainda, mostrando o ambiente de trabalho da empresa Sydle.

O artigo está online, assim como a foto, confiram:
http://www.bhtimagazine.com.br/index.php?option=com_flexicontent&view=items&cid=903:carreira&id=169:turnover-quem-da-mais&Itemid=101

Motivado pelo que vi, escrevi a seguinte carta para a seção "espaço do leitor":

A foto da página 17 do número 03/01 mostra o gerente de RH da Sydle, com a legenda indicando que "a empresa desenvolve intenso trabalho na gestão de pessoas".

Ao observar a foto de forma mais analítica, vemos uma pista para o mistério da falta de mão-de-obra especializada no mercado de TI. Dezenas de pessoas em um espaço aberto estéril, espremidas em mesas pequenas, sentadas em cadeiras de baixa qualidade, sem espaço algum para seus pertences pessoais.

Se você fosse um vestibulando, você se sentiria motivado a seguir carreira de TI ao ver nessa foto as condições de trabalho dos profissionais da área? Nem eu.

Vamos ver se publicam.

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?

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.

Powered by Tableau

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.

Powered by Tableau

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.

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.

Powered by Tableau

Semana que vem tem mais.

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.

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

Complexidade

Relendo o excelente artigo Anatomy of a Crash, fiquei impressionado de novo não só com a rapidez com que uma batida é tratada, mas também com a complexidade do sistema todo. O texto narra a reconstrução de uma batida simulada como parte de um estudo em segurança de veículos:

0 milliseconds - An external object touches the driver's door.

1 ms - The car's door pressure sensor detects a pressure wave.

2 ms - An acceleration sensor in the C-pillar behind the rear door also detects a crash event.

2.5 ms - A sensor in the car's centre detects crash vibrations.

5 ms - Car's crash computer checks for insignificant crash events, such as a shopping trolley impact or incidental contact. It is still working out the severity of the crash. Door intrusion structure begins to absorb energy.

6.5 ms - Door pressure sensor registers peak pressures.

7 ms - Crash computer confirms a serious crash and calculates its actions.

8 ms - Computer sends a "fire" signal to side airbag. Meanwhile, B-pillar begins to crumple inwards and energy begins to transfer into cross-car load path beneath the occupant.

8.5 ms - Side airbag system fires.

15 ms - Roof begins to absorb part of the impact. Airbag bursts through seat foam and begins to fill.All over in the blink of an eye

17 ms - Cross-car load path and structure under rear seat reach maximum load.

Airbag covers occupant's chest and begins to push the shoulder away from impact zone.

20 ms - Door and B-pillar begin to push on front seat. Airbag begins to push occupant's chest away from the impact.

27 ms - Impact velocity has halved from 50 km/h to 23.5 km/h. A "pusher block" in the seat moves occupant's pelvis away from impact zone. Airbag starts controlled deflation.

30 ms - The Falcon has absorbed all crash energy. Airbag remains in place. For a brief moment, occupant experiences maximum force equal to 12 times the force of gravity.

45 ms - Occupant and airbag move together with deforming side structure.

50 ms - Crash computer unlocks car's doors. Passenger safety cell begins to rebound, pushing doors away from occupant.

70 ms - Airbag continues to deflate. Occupant moves back towards middle of car.

Engineers classify crash as "complete".

150-300 ms - Occupant becomes aware of collision.

Imagine um site moderno, que tem código rodando no browser e código no servidor (números inventados de cabeça mas não totalmente irreais):

0 ms - usuário digita o endereço de uma página do seu site

1 ms - o código do cliente determina o que fazer com a URL e dispara uma chamada ao servidor solicitando dados

16 ms - front-end do site recebe o pedido, determina que parte do site deve ser executada a partir da URL e dos dados da requisição HTTP

17 ms - serviço responsável por tratar a parte do site que o usuário quer recebe o pedido, decodifica parâmetros e dispara chamadas remotas a dezenas de back-ends

20 ms - cada back-end envolvido no serviço recebe uma requisição e acessa alguma forma de banco de dados para buscar as informações necessárias

25 ms - serviço recebe os dados de volta e calcula resposta a ser enviada de volta para o cliente, empacota tudo em algum objeto e retorna

40 ms - browser recebe resposta HTTP, chama callback do cliente para tratar os dados

42 ms - cliente preenche interface com os dados recebidos, montando a árvore DOM para a próxima interação

45-150ms - enquanto imagens carregam, usuário começa a ler o texto que já está disponível, possivelmente tomando a próxima ação (se o usuário está no IE6, a primeira requisição provavelmente só foi disparada pro servidor agora...)

Essa descrição é propositadamente superficial. Alguns dos detalhes omitidos são autenticação, serialização e desserialização de pedidos e respostas, caching em vários níveis do sistema, sharding e balanceamento de carga, logging, validação de entrada no cliente e no servidor, o modelo ou esquema de armazenamento de dados para acesso eficiente, bordinhas redondas e degradês em todos os browsers, monitoramento, XSS, XSRF, cookies, injeção de dependências, internacionalização, e as pilhas do sistema operacional e de rede de todas as máquinas envolvidas no processo. Além disso, cada front-end e back-end envolvido tem suas próprias camadas de complexidade, ou abstração. Ah, e tem um bug aqui e outro ali.

A grande vantagem pra quem trabalha na engenharia de software sobre outros tipos de engenharia em termos de confiança no sistema é que se tem a oportunidade de testar exatamente o código que vai rodar em produção durante o desenvolvimento. Nós podemos inflar o airbag que vai ser instalado no próximo carro da linha de produção, acender cada fósforo que vai entrar na próxima caixinha. O perigo de confiar totalmente nisso é que a soma da compreensão das partes não é a compreensão do todo.

E quando tudo falhar em produção, teremos aquela grande imagem cheia de detalhes para depurar; analisando várias partes descobriremos que aquele airbag que nós sabíamos que funcionava não foi inflado. Onde no meio de tantas interações ficou faltando o disparo do airbag praquele usuário que teve uma batida a um ângulo de 23ᵒ, trafegando a 45km/h com 2 passageiros numa tarde de sábado de um ano bissexto?

Só não se sente intimidado por um site moderno, ou pelos bugs que podem aparecer nele, quem não sabe como ele funciona.

20 lições importantes

Recentemente a Guta me disse que eu estava muito ranzinza nesse blog e que faltava humildade. Reclamei do Joel, reclamei do artigo sobre manutenção, disse que meu artigo era melhor que o do Stroustrup... ela tem razão e não quero que esse blog seja um lugar para se falar mal dos outros. Assim, começo o ano de 2010 falando muito bem de um artigo que li durante as férias: Top 20 programming lessons I've learned in 20 years. O autor é Jonathan Danylko. Eu concordo com tudo!

Segue abaixo então minha tradução livre do artigo. Aliás, livre até demais: eu mantive as 20 lições intactas, mas os comentários são meus.

1. Decida quanto tempo você quer gastar com um problema antes de começar. Ao invés de ficar pelejando por uma semana com um problema que deveria levar um dia pra resolver, como eu fiz na semana passada, decida antecipadamente quanto tempo você vai dedicar a ele. Pode ser uma semana, um dia, uma hora, 30 minutos, não importa. Se você não conseguir resolver o problema no tempo em que você se permitiu trabalhar nele, procure ajuda ou repense suas prioridades ao invés de tentar ser o super-programador.
2. Uma linguagem é uma linguagem é uma linguagem. Um sábio professor uma vez me disse que o problema que o seu programador mais júnior está tendo com a namorada tem mais impacto no sucesso do seu projeto do que a linguagem de programação que você escolher. Ele tinha razão. Escolha uma linguagem que te dê conforto, e pronto.
3. Não exagere nos design patterns. Pense duas vezes antes de usá-las - se houver uma solução mais simples, use-a. 
4. Faça backups do seu trabalho diariamente.
5. Você não é o melhor programador. Conforme-se com isso. Sempre tem alguém melhor que você.  Aprenda com eles ao invés de tentar ser melhor.
6. Aprenda a aprender mais. Se você não está gastando pelo menos 50% do seu tempo aprendendo, sua produtividade está piorando. Sim, parece um paradoxo, mas não é.
7. Mudanças são constantes. O que você sabe hoje não vai ser tão importante amanhã. Diversifique seus conhecimentos. 
8. Apoie os menos experientes. Ajudar os programadores da sua equipe a se tornarem melhores é o melhor investimento a longo prazo que você pode fazer.
9. Simplifique seu algoritmo. Quando terminar, volte atrás e veja o que você pode fazer para tornar seu código mais simples e fácil de ler. O futuro agradece.
10. Documente seu código. De novo, o futuro agradece. Aliás, quem provavelmente mais agradecerá será você mesmo.
11. Teste, teste, teste.
12. Celebre cada sucesso. Não espere uma data longínqua para se dar os parabéns. Programar é cansativo. Comemore cada passo a frente e cada bug removido, da maneira que preferir. Só não comemore comendo chocolate, como eu faço.
13. Faça revisões de código. No Google cada linha de código que é escrita é revisada por pelo menos um outro programador. Nenhuma outra atividade é tão importante para se garantir a qualidade dos sistemas. Mesmo que você não chegue a esse extremo, peça a seus colegas que revisem as partes importantes e ofereça-se para fazer o mesmo.
14. Estude seu código antigo. Leia código que você escreveu quando ainda não era tudo isso e maravilhe-se com o quanto você aprendeu desde então.
15. Tenha senso de humor. Ha ha.
16. Evite trabalhar com programadores possessivos ou prepotentes. O possessivo é aquele que não permite que ninguém altere ou critique seu código; ele pode arruinar seu projeto. O prepotente é aquele que tem sempre a última palavra; ele vai prejudicar sua auto-estima.
17. Nenhum projeto é simples. Nenhum. Não existe nada de qualidade em computação que possa ser feito "rapidinho, em dois dias".
18. Cuidado com o excesso de confiança. Enquanto não estiver funcionando e aprovado, nunca está 90% completo. Os 10% que faltam em geral levam o mesmo tempo que você gastou com os 90%.
19. Software nunca está pronto. Leia o post Persistir ou jogar tudo fora? 
20. Paciência é uma virtude. Saiba esperar a hora certa de implementar; antes tente entender seu problema. Quando as coisas derem errado, procure entender por que ao invés de sair tentando qualquer coisa.