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.