Micos de Realejo

Personal trainers para programadores

2011-09-29T11:15:00.000-03:00

Hoje li um artigo fantástico no New Yorker sobre um cirurgião que contratou outro cirurgião para observá-lo enquanto fazia cirurgias e sugerir melhorias. Me fez pensar se não poderíamos fazer o mesmo com o desenvolvimento de software: ser observado no ato da programação para encontrar formas de aprimorarmos nossas técnicas.

Quando a Guta e eu estávamos em Waterloo, trabalhamos em um centro da universidade chamado TRACE (Teaching Resources and Continuing Education, que hoje se chama CTE). O objetivo desse centro era promover workshops e outros tipos de atividade para melhorar a qualidade do ensino. Uma das coisas que a gente fazia era observar professores em sala de aula. Qualquer professor podia requisitar esse serviço. Um de nós assistia a uma aula inteira do professor e submetia um relatório avaliando o seu desempenho. O professor podia até ser filmado se quisesse.

Nós éramos treinados para observar as coisas certas. O relatório tinha de mencionar tanto o que o professor fez certo quanto os pontos nos quais ele podia melhorar. Eram itens como "do fundo da sala não conseguíamos ouvir as perguntas que os colegas da frente faziam; seria bom você repetir a pergunta para a classe inteira," ou "você passou 15 minutos apenas escrevendo no quadro e discursando sobre o tema e a turma ficou dispersa; tente envolver a turma a cada 2 ou 3 minutos com alguma pergunta para prender a sua atenção."

Por que não fazer o mesmo com programadores? Imagine programar durante algumas horas com alguém te observando. Seu personal trainer poderia fazer observações como:

método: "você gastou 20 minutos resolvendo um bug que teria sido encontrado com um teste de unidade simples; tente escrever os testes antes do código, ou no mínimo depois de terminar cada classe, ao invés de deixar para testar só quando o programa está pronto para executar"
ferramentas: "você muda de janela com frequencia para usar o talk do gmail, e acaba se distraindo com emails novos que chegaram; existe um plugin do gtalk para o Eclipse, por que não usá-lo?"
design: "sua classe me parece ter duas responsabilidades distintas; não seria bom dividí-la em duas?"
ergonomia: "sua postura é boa inicialmente mas à medida em que o tempo passa sua vista parece ficar cansada e você se inclina para ficar cada vez mais próximo da tela; use um cronômetro de software para lembrá-lo de fazer um pequeno intervalo a cada 30 minutos, assim você voltará à postura adequada".

Esses são só alguns exemplos. Há muitas outras possibilidades. Um personal trainer não precisa ser um excelente programador, precisa apenar saber os pontos aos quais deve estar atento. Nós não éramos professores melhores do que os que observávamos, mas lemos bastante sobre técnicas de ensino e tínhamos um checklist de itens a observar, boa parte deles tirado do excelente livro Tools for Teaching.

Muitos de nós fazemos revisões de código, que já é uma forma de ter seu trabalho avaliado por outros programadores. No entanto, o revisor só tem a oportunidade de avaliar o produto final do seu trabalho. O personal trainer vai além, observando-o enquanto trabalha e sugerindo idéias para tornar o seu trabalho melhor e mais eficiente.

E aí, alguém quer tentar?

Desvendando a burocracia

2011-09-27T08:34:00.001-03:00

Outro dia estava conversando com um colega de outra equipe, uma equipe recém-formada na empresa, que me assegurou que iam conduzir a equipe "como uma startup". Que iam ser ágeis, lançar iterações frequentes, e que não iam ficar amarrados às burocracias da empresa. Eu achei a iniciativa louvável mas fiquei com a pulga atrás da orelha. Será que dá mesmo para conduzir uma equipe como uma startup dentro de uma empresa grande?

Quando pensamos em startups versus grandes empresas, vem a imagem de um bando de magrelas esfomeados, vestindo camisetas com dizeres engraçados, trabalhando como loucos e lançando produtos inovadores e sensacionais, contra um exército de gordos engravatados preenchendo formulários. É um fato da vida que à medida em que empresas crescem, elas se tornam menos flexíveis. Os acordos informais que funcionavam tão bem quando eram três magrelas já não funcionam com trezentos, e as coisas precisam se tornar formais. O que era bom senso é cada vez mais tornado regra na forma de políticas internas. É a ossificação dos processos.

Daí os desenvolvedores mais antigos se reunem no café para lamentar como tudo piorou desde os velhos tempos. Só que se esquecem que a agilidade de uma startup vem com um preço: a dívida. Mais especificamente, a divida técnica, que é aquela que você adquire quando faz as coisas rápido ao invés de fazer direito.

Sim, dá pra lançar uma nova rede social para corredores de kart em duas semanas. Uma startup precisa mostrar resultados o mais rapido possível, pois precisam começar a pagar as contas atrasadas do provedor de internet. Assim, não se preocupam que um dia o sistema terá de ser traduzido em quarenta línguas, que terá de comportar milhares de usuários, que poderão ser processados por algum cliente mal-amado, que o código terá de ser lido e mantido pelas dezenas de novos funcionários que farão fila na porta quando o sucesso chegar. Todas essas preocupações ficam para depois em troca da rapidez - essa é a dívida técnica. Quando chega a hora de pagar a dívida, ela precisa ser paga com juros, pois o sistema já está em execução e as mudanças precisam ser profundas pois não foram contempladas no design inicial.

Uma empresa grande não precisa fazer esses "empréstimos". Pode se dar ao luxo de contemplar todas as facetas do sistema enquanto ele está sendo desenvolvido. Por isso há tantos processos, checklists e burocracia aparente. Seu sistema precisa ser vistoriado e aprovado por especialistas em segurança, analisado para determinar o consumo de recursos e a escalabilidade, testado para medir a usabilidade, revisado por advogados para evitar desastres, e tantas outras coisas que tomam seu tempo, dão trabalho e parecem querer impedí-lo de lançar seu lindo produto. O que está acontecendo é que você está evitando contrair uma dívida que pagará com juros depois. Você até pode rodar sua equipe como uma startup dentro de uma grande empresa, mas não deve.

Os processos aparentemente burocráticos não existem para piorar a agilidade de ninguém, mas sim para garantir que o que precisa ser feito é feito. Só que nem todos os processos são assim: na sua empresa certamente existe alguma regra que, na sua opinião, só piora a sua vida. Será que a burocracia é inevitável e que não há o que fazer a não ser continuar a ler Dilbert e a se identificar com ele? Não.

Toda vez que você avistar uma placa proibindo ou prevenindo, pense que ela com certeza foi motivada por algum evento real:

Coitado do pinguim. Da mesma forma, muitas das políticas implantadas nas empresas existem porque alguém, algum dia, fez algo que não deveria e a empresa não quer que esse algo se repita, então cria uma regra nova. Só que os tempos mudam e essas regras continuam lá. O que você pode fazer é olhar para cada regra burocrática da sua empresa e pensar, por que será que implementaram isso? será que o que era verdade naquela ocasião continua sendo verdade? será que hoje não há outra forma de se evitar o problema? será que o custo em tempo perdido devido à regra não é maior do que os danos causados pelo problema que ela existe para evitar? Responda a essas perguntas, junte os dados, proponha alternativas, leve para os responsáveis, e seja um super-herói para os seus colegas.

Palestra do Prof. John Hopcroft hoje na UFMG

2011-04-15T10:58:00.001-03:00

Hoje às 14:30h acontecerá na UFMG uma palestra do Prof. John Hopcroft, professor da Cornell University e ganhador do Turing Award, o prêmio de maior prestígio na Ciência da Computação. A palestra se chama "Computer Science Theory to Support Research in the Information Age".

O evento será transmitido ao vivo através desse endereço:

http://video.rnp.br/portal/InfosEvento.do?_EntityIdentifierEvento=rnp3K79UoeaZKXXUForNMUGx9PLWzTXS0CHyNkw79b4dp4.&

Espero que o servidor tenha capacidade suficiente para aguentar todos os leitores do Micos de Realejo!

Complexidade inerente

2011-04-14T10:22:00.000-03:00

Outro dia eu aprendi o termo physics envy - inveja da física - o desejo de se poder reduzir qualquer problema a três leis fundamentais. Me identifiquei imediatamente com isso. Toda vez que me deparo com um programa complicado eu me sinto incomodado e quero achar uma solução mais simples do que aquela.

Às vezes essa solução não existe. O domínio do problema em si pode ser complexo e resistir a todas as tentativas de simplificação. Um bom exemplo é o corpo humano. Faltam décadas, talvez séculos, para que a medicina consiga entender razoavelmente bem como funciona um ser humano. O número de variáveis envolvidas e de interdependências entre elas é descomunal.

Como a medicina lida, hoje, com essa complexidade? Ignorando a complexidade e encontrando variáveis com grande influência sobre o objetivo buscado. Por exemplo, vamos supor que um médico queira reduzir a chance de seus pacientes sofrerem de doenças cardiovasculares. A verdade é que sabe-se muito pouco sobre essas doenças: por que algumas pessoas as tem e outras não, quando elas acontecem, o que as causa. É uma combinação complexa de genética, estilo de vida e psicologia. Ao invés de desistir frente à complexidade, o jeito é procurar variáveis significativas. Por exemplo, percebe-se que a taxa de colesterol parece ter uma relação forte com a incidência dessas doenças. Portanto, uma forma de atacar o problema é fazendo diminuir essa taxa. Não entendemos bem se fazer essa redução artificialmente impacta outras variáveis importantes, mas parece que fazê-lo traz um resultado positivo, então isso é feito. A complexidade do problema é reduzida a poucas variáveis. Ele não é resolvido - afinal de contas, as pessoas continuam tendo doenças cardiovasculares - mas ele é atenuado.

O que isso tem a ver com software? Tudo. Muitas vezes temos de desenvolver sistemas para resolver problemas em domínios que, como o corpo humano, parecem inerentemente complexos. Outras vezes essa complexidade chega de fininho na forma de problemas cuja solução começou simples e elegante, mas com o tempo os requisitos mudam e aparecem os remendos daqui e dali. Mesmo que feitos com todo o cuidado e critério, eles aumentam a complexidade do sistema. Um dia essa complexidade fica tão imensa que ninguém mais consegue entender bem a solução.

O que fazer para reduzir a complexidade dos sistemas? Bom, de modo geral, uma solução ótima para um problema é tão complexa quanto o problema. No entanto, o segredo é fazer como a medicina: procurar um conjunto pequeno de variáveis que possa levar a uma solução sub-ótima, porém muito mais simples. De modo geral, acrescentar variáveis aumenta a complexidade da solução linearmente, mas melhora a qualidade da solução apenas logaritmicamente.

O importante, então, é encontrar o menor conjunto de variáveis que juntas darão um resultado aceitável. Em um sistema que evoluiu e sofreu degradação, isso envolve dar um passo atrás e pensar novamente em qual é o problema que o sistema tenta resolver. Pode ser que variáveis que não eram importantes quando o sistema foi concebido agora sejam, e que algumas das variáveis originais tenham perdido a importância.

Assim, quando você sentir que seu sistema está ficando complicado demais, pare um pouco e pense: qual é o preço de simplificarmos o problema? Estamos dispostos a paga-lo?

Eu tenho inveja dos físicos e pago qualquer preço pra simplificar minha vida.

Diretrizes curriculares

2011-03-27T22:21:00.000-03:00

O Conselho Nacional de Educação (CNE) colocou em consulta pública à sociedade (sim! todos podem opinar) as diretrizes curriculares dos cursos de graduação da área de computação. São eles: Ciência da Computação, Sistemas de Informação, Engenharia de Computação, Engenharia de Software e Licenciatura em Computação. O documento que está disponível para consulta no site http://formularios.mec.gov.br/consulta-diretrizes-curriculares
foi produzido por uma comissão em inúmeras discussões entre professores do Brasil, através dos grupos de trabalho da comissão de educação da Sociedade Brasileira de Computação (SBC) e encontros nos diversos eventos da área de computação. Acredito que este documento representa hoje um avanço na direção de estabelecermos diretrizes para os currículos da área. Acredito principalmente que a inclusão da ES como curso de graduação abrirá as portas para a criação de mais cursos e currículos de qualidade, culminando com a formação de recursos humanos capacitados. Existem hoje 5 cursos de graduacao em ES no país. Todos possuem curriculos bem diferentes. Existem varios cursos de SI que possuem uma ênfase em ES. As diretrizes estabelecidas definem as habilidades e competências esperadas para os diferentes tipos de profissionais egressos.

Portanto, use sua experiência profissional para contribuir com as diretrizes elaboradas. Apresente suas sugestões bem fundamentadas com justificativas. A data limite é 31/03/2011.

É melhor ter um mapa

2011-03-24T10:10:00.000-03:00

Conhecimento tácito é tudo aquilo que está na cabeça das pessoas mas não está escrito em lugar algum, ou que é difícil de colocar em palavras. É como receita pra fazer arroz, não tem nenhuma que explica tudo que você precisa saber. Se você tentar seguir, ele sai todo empapado.

Isso é uma das grandes pragas de qualquer projeto de software. Pense bem: toda empresa tem alguém que, se for embora hoje, deixa pra trás um punhado de coisas que ninguém mais sabe. Daí pra descobrir tudo é uma eternidade e muita dor de cabeça. Faça o seguinte exercício mental. Seu projeto está aí, seguindo em frente tranquilamente. Imagine que você quebrou as mãos e alguém entrou agora em seu projeto para te substituir. O que essa pessoa vai ler? Por onde vai começar? Quanto tempo ela vai levar para saber tudo que você sabe sobre o seu projeto?

A solução, é claro, é documentação. Nunca trabalhei em um projeto que eu considerasse bem documentado. Talvez em uma empresa que siga processos rígidos, com certificação CMMI ou equivalentes, a coisa seja diferente, mas nunca trabalhei em uma empresa assim. Se tem uma coisa que nunca é suficiente, é documentação.

Meu amigo Ademir gosta de dizer que não confia em documentação, só em código. Eu discordo. Aprender lendo código é difícil, cansativo e doloroso. É preciso algo que te mostre uma visão do todo, que explique como as várias partes se compõe. Entrar em um projeto novo é explorar um território desconhecido. Para não se perder tempo demais vagando sem rumo, é preciso um mapa.

A desconfiança do Ademir não é sem fundamento. Em última instância, a verdade está no código. É muito fácil deixar documentos ficarem desatualizados em relação ao código. Como dizem os exploradores, se o mapa e o terreno forem diferentes, acredite no terreno. O código é o terreno. Mesmo assim, mesmo sendo meio errado e impreciso, é melhor ter um mapa.

A maioria das pessoas não gosta de escrever documentação porque é difícil. Muitas das coisas que sabemos são difíceis de explicar de forma clara, difíceis de colocar em palavras, mas é preciso tentar. Não basta escrever código claro e bem escrito. Todo mundo precisa de um mapa.

De volta

2011-03-17T22:23:00.000-03:00

Depois de meses fora do ar, eis que o "Micos" ressurge das cinzas. Pouco antes do meu desaparecimento, eu mudei de projeto. Meu trabalho atual é bem diferente de tudo que já tinha feito antes, o que quer dizer que tenho um punhado de experiências novas para compartilhar com vocês.

O site também está com um novo look e até um mascote, que ainda não foi batizado. Se alguém tiver alguma sugestão de nome apropriado, me conte :-)

Não, não fui eu quem desenhou, não tenho essa capacidade. Na verdade eu encomendei de um artista usando o fiverr.com, onde pessoas prestam serviços por 5 dólares. Tem também uma versão brasileira, o www.dezreal.com.br.

A Escassez Relevante

2010-08-30T15:05:00.000-03:00

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

2010-08-27T15:04:00.000-03:00

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

2010-08-19T09:22:00.000-03:00

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

2010-08-17T15:34:00.000-03:00

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

2010-06-21T11:01:00.000-03:00

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:

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ê é.
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

2010-05-20T01:25:00.008-03:00

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

2010-05-14T16:19:00.000-03:00

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

2010-04-28T09:57:00.001-03:00

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

2010-04-27T09:19:00.000-03:00

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.

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

2010-03-24T22:44:00.002-03:00

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.

Para que serve o teste de software?

2010-03-23T08:57:00.003-03:00

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

2010-03-19T16:11:00.002-03:00

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.

Feliz Dia Internacional da Mulher

2010-03-08T09:04:00.000-03:00

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

2010-03-02T13:34:00.000-03:00

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

2010-02-24T10:16:00.003-03:00

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

2010-02-02T13:58:00.000-02:00

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.

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.
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.
Não exagere nos design patterns. Pense duas vezes antes de usá-las - se houver uma solução mais simples, use-a.
Faça backups do seu trabalho diariamente.
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.
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 é.
Mudanças são constantes. O que você sabe hoje não vai ser tão importante amanhã. Diversifique seus conhecimentos.
Apoie os menos experientes. Ajudar os programadores da sua equipe a se tornarem melhores é o melhor investimento a longo prazo que você pode fazer.
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.
Documente seu código. De novo, o futuro agradece. Aliás, quem provavelmente mais agradecerá será você mesmo.
Teste, teste, teste.
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.
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.
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.
Tenha senso de humor. Ha ha.
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.
Nenhum projeto é simples. Nenhum. Não existe nada de qualidade em computação que possa ser feito "rapidinho, em dois dias".
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%.
Software nunca está pronto. Leia o post Persistir ou jogar tudo fora?
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.

Bjarne Stroustrup também lê o "Micos"

2009-12-23T09:10:00.000-02:00

Lembram-se dos posts recentes sobre o desencontro entre universidade e indústria? Pois parece que o criador do C++, Bjarne Stroustrup, também leu e resolveu escrever a sua versão, que aparece na Communications of the ACM de Janeiro 2010. O artigo se chama "What should we teach new software developers? Why?" (obrigado Guilherme pelo share no Reader).

Se você se interessa pelo tema, leia o artigo agora ou durante o feriado. É bem legal e mais bem escrito que os meus, apesar dos meus serem mais precisos e menos genéricos em suas colocações, modéstia a parte.

Um bom Natal para todos!

Papai Noel, me dê usuários no Natal

2009-12-17T13:19:00.001-02:00

Sim, Dezembro é um mês lento para os miquinhos que só conseguem sonhar com sonecas debaixo de coqueiros em praias tropicais. Enquanto isso não acontece, vamos falar sobre aqueles que são ao mesmo tempo a bênção e a maldição de todo sistema: os usuários.

Ter usuários é uma benção. Se você não tem usuários, todo seu esforço foi em vão, inútil, jogado fora. Todo sistema quer ter usuários pra provar pra si mesmo que merece existir. Não ter usuários resulta em aposentadoria precoce.

Ao mesmo tempo, ter usuários é uma maldição terrível. A partir do instante em que o primeiro deles clica o primeiro botão no seu sistema novinho em folha e recém-lançado, seus problemas começam. Os problemas são:

1. Dados

Enquanto não há dados de ninguém no seu sistema além das coisas engraçadinhas que você colocou lá nos seus testes, você pode mudar e desmudar o que quiser. Quando aparece a primeira informação de verdade, você passa a ter problemas. Não é mais possível fazer aquelas pequenas ou grandes mudanças sem pensar no efeito das mudanças sobre os dados que estão lá. Infelizmente o efeito é muitas vezes devastador: além de mudar seu sistema, você precisa transformar os dados existentes em dados que tem as propriedades novas que você quer. Tudo isso, é claro, enquanto seus usuários não param de jogar dados que você não quer pra dentro do seu banco de dados.

A solução: ao projetar seu sistema, antecipe as dificuldades de migração de dados e crie mecanismos para fazê-la facilmente. Por exemplo, garanta que sua camada de modelo é capaz de duplicar toda escrita em dois canais diferentes e ler de ambos também. Assim, você conseguirá fazer uma transição suave durante a qual tudo é escrito nas duas bases de dados. Quando isso estiver funcionando, você pode desligar a escrita na base antiga e ir copiando os dados para a base nova, enquanto o sistema continua funcionando e lendo das duas bases.

2. Comportamentos

Seus usuários vão se esforçar pra aprender a usar seu sistema. Como não desistiram, presumo que seu sistema seja bom. Acontece que se você mudar qualquer coisa que atrapalhe o esforço que eles investiram no aprendizado, eles vão te odiar, mesmo que a mudança tenha sido pra melhor. Aliás, não importa o que você faça, alguém sempre vai odiar.

Imagine que seus usuários tinham um limite ridiculamente pequeno de dados que podiam guardar no seu site. Imagine agora que de um dia pro outro você acabe com os limites e permita uso ilimitado. Toda funcionalidade permaneceu inalterada. Eu aposto o dinheiro que você quiser que algum infeliz vai reclamar e dizer que preferia quando tinha limites, pois forçava ele a se organizar melhor. A vida é assim.

A solução: como eu queria ter uma solução pra esse problema... o máximo que se pode fazer é tornar cada atualização a menor possível. Se você quer fazer várias atualizações, contenha-se e faça uma de cada vez para dar aos usuários o tempo pra se acostumarem com a nova forma de se usar o sistema. Se você quer fazer mudanças radicais, permita que os usuários retornem ao modo antigo de ser, pelo menos durante um tempo.

3. Comunicação

Você mudava qualquer coisa e só tinha de virar pro lado e avisar pro seu colega que a mudança estava pronta. Agora não é mais tão simples assim. Os usuários não entendem quando coisas mudam sem explicações. Toda vez que alguma coisa relevante mudar (tipo toda semana) você vai ter de dar um jeito de explicar aos usuários. O problema é que é difícil ser ouvido. Ninguém quer ler seu blog e ninguém lê as mensagens que você coloca na página de login. Se você deixa um espaço na página principal do seu sistema pra avisos importantes, os usuários logo desenvolvem cegueira seletiva e param de ver o que está lá.

A solução: se quiser mesmo comunicar com seu usuário, varie. A regra básica é colocar seu comunicado o mais próximo possível do local em que o usuário vai usar o que está escrito. Se é uma funcionalidade nova, coloque um "novo!" discreto ao lado do botão ou seja o que for. Um balão estilo estória em quadrinhos apontando para a novidade também é uma boa. Deixe que o comunicado seja uma surpresa. Outra coisa importante é deixar que o usuário retire o comunicado da tela e que ele não apareça mais.

Há outros problemas, é claro, mas esses ficam pra outros posts. Os micos de realejo vão dar uma parada para os feriados e férias, mas voltaremos no final de Janeiro a todo vapor.

Boas festas!