Arquivo para maio \17\UTC 2007

Você batiza seus bugs?

O título era para ser outro. Algo como “Você batiza suas sugestões de funcionalidade, pedidos de mudança, tickets, estórias de usuário ou seja lá como você gosta de chamar as solicitações de melhoria para suas aplicações?”, mas acho que ficaria um pouco longo demais. Resolvi generalizar tudo para “bugs”, mas por favor não se irrite se não escolhi seu termo favorito. Com uma lista de termos tão longa quanto essa, é difícil conseguir agradar a todos.

Uma vez trabalhei junto com alguns amigos em um jogo. Um jogo é só um programa de computador e, assim como qualquer programa de computador, acaba adquirindo alguns defeitos durante o desenvolvimento. A peculiaridade dos jogos é que eles costumam imitar o mundo real, tornando mais fácil fazer associações e analogias.

Nosso jogo tinha alguns defeitos particularmente interessantes. Um deles fazia com que alguns personagens começassem a se deslocar em uma direção que não coincidia com a animação exibida. Dava para ver o boneco tentando andar na diagonal enquanto o deslocamento real era na horizontal. Ficávamos entretidos olhando aquilo e acabamos inventando um nome para o defeito: Moonwalker, uma referência ao passo de dança popularizado por Michael Jackson.

Outro defeito tinha a ver com liberação de memória. Em algum ponto do código, estávamos liberando erroneamente a memória usada para armazenar os quadros da animação do movimento dos personagens. Isso de vez em quando fazia eles desaparecerem da tela por alguns milésimos de segundos e reaparecerem em outro ponto mais à frente. Chamamos isto de Tele-transporte. Um terceiro defeito, desta vez na rotina de detecção de colisão, fazia com que o personagem principal pudesse atravessar as paredes em alguns pontos. Este foi prontamente batizado com o nome “Ladrão Fantasma”.

Deixando a nostalgia de lado por um momento, o fato é que os nomes humanizavam todo o trabalho desde a detecção até a eliminação dos defeitos, do mesmo modo que os nomes de domínio humanizam os endereços na Internet (e as pessoas acabam usando os mecanismos de busca para levar a idéia ainda mais adiante). Para um computador é simples enviar uma requisição para 200.186.109.162, mas para uma pessoa é mais simples entrar no thiagoarrais.wordpress.com (e muita gente acha ainda mais simples buscar por “Mergulhando no Caos”). Do mesmo modo, pode ser natural para uma máquina marcar como resolvido o registro referente ao bug #1376, mas para um humano é mais natural levantar do lugar e dizer “Consertei o Moonwalker”.

O Motiro institucionaliza esta prática. Os “bugs” nele são chamados “sugestões de recurso” e toda sugestão de recurso é uma página wiki. Como qualquer outra página wiki, elas têm um título: um nome que precisa ser informado por quem registra ou edita um bug. Se a pessoa não estiver se sentindo muito criativa na hora, pode deixar de preencher o título e a página receberá um número.

Os demais sistemas de acompanhamento de que tenho notícia costumam usar um número para se referir aos bugs e disponibilizam um sumário para humanizar um pouco a coisa. O Motiro é o único que conheço que elimina os números de bug em favor dos títulos. O fato de nenhum outro sistema do tipo fazer isto pode significar duas coisas: ou esta é uma daquelas idéias que parecem ridiculamente óbvias depois que alguém as têm (como o Ovo de Colombo), ou é uma péssima idéia mesmo.

Se você parar para pensar, defeitos são coisas que se quer eliminar o mais rápido possível. Algo que você não quer andando por aí durante muito tempo. Se uma barata aparece na sua cozinha, você vai lá e mata. Não fica inventando nomes fofinhos e engraçadinhos para a intrusa. Se os defeitos são detectados e corrigidos rapidamente, não faz muito sentido perder tempo bolando nomes.

Por outro lado, os recursos para eliminação de defeitos são limitados. Pode ser que o chinelo não esteja por perto na hora que a barata aparece, pode ser que você tenha um pavor gigantesco de baratas e não consiga fazer nada além de gritar e correr ou pode ser que você precise estudar bastante antes de entender alguma tecnologia. Quando não é possível corrigir todos os defeitos ao mesmo tempo, alguns deles precisam existir por mais tempo que os outros e podem ganhar nomes.

Além disso, bugs neste contexto não são somente defeitos. Podem ser também sugestões de novos recursos e comentários para melhoria. Neste caso, também volta a fazer sentido batizar estas coisas. Algumas dessas sugestões podem precisar ser amadurecidas e um nome é uma boa forma de se referir a elas.

De qualquer modo, o fato de nenhum sistema atual favorecer as palavras em detrimento dos números é intrigante. Afinal, pessoas geralmente lembram melhor das palavras do que dos números, não?

E você? Costuma batizar seus bugs?

Anúncios

É “guiado”, oras!

Provavelmente vou mexer em um vespeiro dos grandes com o texto de hoje. Pelo menos é o que eu vejo acontecer quando alguém resolve desafiar, questionar ou simplesmente comentar qualquer coisa no campo da Agilidade (com letra maiúscula mesmo). Neste pequeno mundo, você nunca sabe quando está mexendo com alguma coisa sagrada para alguma pessoa. Também é o que eu vejo acontecer quando programadores discutem a questão traduzir ou não traduzir. Então parece que são dois vespeiros ao invés de um só. Mas eu gosto de exercitar a iconoclastia sempre que possível e vou continuar com o texto apesar de tudo.

Não sei como surgiu a tradução que parece ser normalmente usada por todo mundo aqui pelas bandas do Brasil para “Test Driven Development”, mas eu simplesmente não consigo evitar um certo incômodo mental quando alguém cita “Desenvolvimento Orientado a Testes”.

Pronto falei. Podem jogar as pedras.

Não é que os símbolos tenham algum papel extremamente relevante quando usados por pessoas com o mesmo domínio sobre o vocabulário. Evidentemente, não há nenhum problema nas palavras em si quando as pessoas sabem do que se está falando. Mas é quem não sabe que me preocupa.

Esta expressão “orientado a” deve ter vindo do mesmo baú do qual foram tirados alguns outros termos da moda como Programação Orientada a Objetos e Arquitetura Orientada a Serviços (que, como todo bom modismo, também costumam ser completamente mal interpretados). Não vou recorrer ao lugar comum de consultar um dicionário, mas este termo pode levar muita gente a pensar em simplesmente atentar para os testes e projetar sistemas testáveis. Esta postura certamente é melhor que não dar atenção nenhuma aos testes e relegar a atividade ao décimo-oitavo plano para ser realizada um pouco antes da implantação no caso de sobrar algum tempo. “Desenvolvimento Orientado por Testes” é um pouco menos ambíguo. Mas prefiro “Desenvolvimento Guiado por Testes” tanto por ser mais fiel ao original quanto por eliminar o já sobrecarregado termo “orientado”.

Desenvolvimento guiado por testes envolve uma certa atenção aos testes, mas também uma porção de outras escolhas técnicas e filosóficas. Envolve obrigatoriamente escrever os testes antes do código. Afinal, você não pode ser guiado por algo que não existe. Quando se abraça esta filosofia, os testes acabam virando uma das principais razões da existência do código, logo abaixo das necessidades do usuário. Certamente estas últimas são muito mais importantes do que os primeiros, mas um conjunto de testes bem projetado será o melhor reflexo das necessidades do usuário.

Mas, como disse, sou um iconoclasta atento e não acho que este tipo de posicionamento mental seja ideal para todos os casos. Particularmente, quando estou investigando algum tipo de tecnologia que imagino que vou precisar e com a qual ainda não tenho muita familiaridade, prefiro desenvolver apenas orientado a testes. Mantenho sempre a mente atenta à testabilidade, mas não necessariamente chego a escrever os testes. Depois que consigo algum domínio sobre a tecnologia, costumo voltar ao desenvolvimento guiado por testes e faço tudo que posso para escrever os testes antes do código de produção.

De qualquer modo, os termos em si não são tão importantes. São apenas símbolos e, se usados no contexto correto, não costumam gerar nenhum tipo de confusão. O importante são as diferenças filosóficas denotadas por eles.

Acho que minha doidice por linguagens de programação está começando a gerar uma doidice por linguagens naturais. Vai saber…

Pequenas vitórias

Todos nós já experimentamos. Alguns se arrependem e outros nem tanto. Alguns conseguiram encontrar um modo de se livrar e outros nem tentaram. Mas quase todo programador já trabalhou em “modo cego”.

Por meses seguidos.

Saber quando uma equipe está trabalhando em modo cego é fácil: é só perguntar quanto tempo faz desde que receberam algum tipo de comentário de um usuário final. Mais de um mês é um bom sinal de que estão ficando cegos. O tempo exato depende muito do tipo de aplicação que estão desenvolvendo, mas um mês geralmente é tempo demais para andar sem saber para onde vai. Além disso, não faz mal lembrar que um representante do usuário é melhor do que nada, mas não é páreo para um usuário de verdade.

Evitar entrar em modo cego também é fácil: basta estipular um prazo curto e entregar a aplicação do modo como estiver quando a data chegar. Durante este período a equipe exercita simultaneamente todas as habilidades que os aspirantes a desenvolvedor de software tão sabiamente estudam nas suas escolas, de modo a ter sempre algo usável. Fazer isso dá trabalho porque é preciso tomar algumas providências para garantir que a aplicação esteja pronta para ser entregue a todo momento. Afinal, a equipe certamente não vai querer chegar à data combinada sem ter algo apresentável. Mas não é nada humanamente impossível.

Apesar da atenção precisar ser redobrada, o resultado compensa. O usuário poderá oferecer seus comentários depois de ter colocado as mãos em algo concreto. Qualquer forma de tentar artificializar esta experiência através de documentos de especificação, apresentações elaboradas ou emaranhados de diagramas com certeza não oferecerá a mesma expressividade.

A possibilidade de receber continuamente comentários e sugestões de qualidade funciona como poderoso combustível para o potencial da equipe. Quando esta força energizante está disponível, há mais chance de se obter o sucesso. Há mais chance para vencer. Porém, como os períodos de iteração são curtos, estas vitórias serão necessariamente pequenas. Não há tempo para fazer nada muito grandioso e será necessário saber acumular estas pequenas vitórias ao longo do tempo para atingir uma vitória maior.

Ciclos curtos permitem que sejam alcançadas pequenas vitórias. Fracassos vão inevitavelmente se interpor no caminho da equipe, mas também serão pequenos. Estarão contidos em um período suficientemente pequeno para que não causem grande estrago e as vitórias serão tão mais freqüentes que eles passarão quase desapercebidos. Uma vitória pequena puxa a outra, e uma derrota pequena não faz muita diferença. Assim o moral da equipe é estimulado e o sucesso é naturalmente atraído. Ciclos longos, por outro lado, permitem causar grandes surpresas. Quando se trabalha muito tempo sem divulgar sua evolução, o resultado só pode ser grandioso. Se for um sucesso, será uma vitória estupenda. Mas a maior chance é que seja uma derrota miserável.

Porém há ainda quem sinta falta das vitórias extravagantes ou pelo menos do alívio de saber que acabou de deixar uma quantidade monumental de trabalho para trás. Muitas equipes que trabalham às cegas durante muito tempo costumam comemorar estrondosamente as entregas. Mesmo quando são tremendos fracassos comemorar é natural simplesmente porque todos acabam de se livrar de um fardo bastante pesado. Com ciclos curtos, esse sentimento se perde. Não faz muito sentido comemorar a entrega de uma semana de trabalho. Ao fim de dois meses, uma equipe com ciclos de uma semana provavelmente vai ter uma vitória acumulada muito maior do que uma equipe com um único ciclo de dois meses. Apesar disso, a segunda vai comemorar muito mais.

Usar prazos curtos para as entregas é uma boa forma de garantir que elas sejam vitoriosas. Pequenas vitórias, mas vitórias.