Personal trainers para programadores

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

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

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

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

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

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

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.