O oráculo de requisitos

Deu muito pano pra manga um post do Joel on Software chamado "The Duct Tape Programmer", em que ele argumenta que às vezes é melhor fazer um trabalhinho porco pra se lançar um produto rapidamente do que ficar tentando fazer código limpo e testado.

Deu pano pra manga porque tem uns que concordam, outros que discordam veementemente. Pela amostragem que tive, mais pessoas discordam do que concordam, como meu colega de blog Ademir que prefere chamar a técnica de bug-oriented programming. Pra mim o "trabalhinho porco" tem seu lugar sim: na construção do oráculo de requisitos, também conhecido como protótipo funcional.

Um oráculo de requisitos é um sistema que se comporta exatamente como o sistema que você quer desenvolver. Assim, sempre que você estiver em dúvida sobre como o sistema deve funcionar, basta perguntar ao oráculo. A diferença entre o oráculo e o sistema é que o oráculo tem bugs, é lento, seu código é complicado e difícil de se manter, ele não escala, enfim.

Quando se fala em protótipo vem em mente algo que é parecido com o que a gente quer fazer, mas que na verdade é de fachada: usa dados enlatados, simulações, nada é real. Um oráculo não é assim: ele funciona de verdade. Um usuário qualquer não deveria notar diferença alguma entre o oráculo e o sistema real.

Por que fazer um oráculo desses, ora? Não vai dar um trabalhão? Vai sim. Por que não investir o tempo em já desenvolver o sistema direito, uma vez só, certinho? Por causa de uma das leis de Brooks:

"Planeje jogar um sistema fora, você jogará de qualquer jeito"  - Fred Brooks, The Mythical Man-Month

Muito esperto esse Fred Brooks. O fato é que o sistema que você está construindo não vai ficar certo. Quando começarem a usá-lo, você vai descobrir que fez tudo errado. Aí você vai remendar ele todo pra ele ficar certo, e todo seu trabalho cuidadoso vai por água abaixo.

Muito melhor é você fazer um sistema pra se jogar fora. Construa a primeira versão sem se importar com escalabilidade, manutenibilidade, testabilidade, robustez, nada. Ela só tem de funcionar o suficiente pra você ter alguns usuários. Aí, disponibilize pra quantos usuários você puder. Estimule-os a usarem bastante. Observe e escute. Dessa forma você consegue descobrir o que fez errado. Conserte e repita até ficar certo.

Aí é só você construir o sistema de verdade. Agora você sabe o que fazer: um sistema extensível, versátil, bem escrito, testável, que se comporta exatamente como o oráculo de requisitos. Parabéns!

Vou construir meu próximo sistema dessa forma. Depois eu conto como foi.

Bug Oriented Programming

Funciona mais ou menos assim. São 3 passos básicos, bem simples e fáceis de serem decorados:

1. Não gaste muito tempo pensando qual a melhor maneira de implementar algo. Faça o que for mais rápido, só faça funcionar. Não importa como.
2. Faça o que for necessário para entregar. E não confunda as coisas, "entregar" não tem nada a ver com qualidade, a regra é passar a bola para frente ou para o futuro.
3. Para os bugs que aparecerão, utilize os passos 1 e 2 para tentar minimizar os efeitos.
   

Esta técnica foi batizada assim, "bug oriented", pois a filosofia principal é fazer o mínimo possível até o próximo bug aparecer. Devido a isso, a escolha da ferramenta para gerenciamento de bugs é crucial.

Existe também uma variação da técnica chamada "Extreme Bug Oriented Programming". Neste caso, no passo 3 você não age no bug imediatamente mas procura alguém para "resolver" por você. Basicamente, aplica-se a regra "passar a bola para frente" ao extremo.

A grande vantagem da Bug Oriented Programming é que ela se adere muito bem a qualquer projeto, em qualquer fase do desenvolvimento.

Apesar de muito atraente e amplamente utilizada, são muito raros - eu particularmente não conheco nenhum - os casos de projetos que aplicaram tal técnica com sucesso do início ao fim, ou por um longo tempo.

Você está fazendo errado

Se antes de decidir perder tempo lendo essa postagem você estava programando, as chances são grandes que você estava fazendo tudo errado.

Não que eu não respeite suas habilidades de programador, designer, arquiteto de software, engenheiro ou sei lá qual título você prefere. Tenho certeza que você está usando os patterns certos, reduzindo o acomplamento, aumentando a coesão, tornando o código legível e extensível e tudo mais que faz um bom programador. O problema é que você está construindo o sistema errado.

Eu falo de cadeira. Outro dia mesmo estava eu enfoguetando uma equipe inteira pra construir uma funcionalidade nova que ia mudar o mundo, e nós fizemos, e ficou super legal, cheio de toques elegantes e sutis. Lançamos para o nosso público de milhões com direito a festa de lançamento e camisetas. Ninguém usou. Ninguém se importou. Olhando pra trás a gente consegue ver que, realmente, acho que o que a gente fez com tanto carinho não é lá muito útil pra ninguém.

Você acha que o que você está construindo é importantíssimo? Tem certeza? Eu duvido. Como saber, então? Ora, pra mim tem um teste perfeito:

Se outra pessoa fizesse isso, VOCÊ usaria todos os dias?

Se você não responder um "sim" entusiasmado, esqueça. Você certamente está desenvolvendo algo que "os outros" vão achar legal. A verdade é que os outros são iguais a você. Se você não vai usar, por que alguém mais usaria?

Ah, mas meu usuário-alvo é um usuário diferente, você diz. É a criança, o adolescente, o funcionário do banco. Muito bem, se não tem um usuário desses que senta no seu colo pelo menos uma vez por dia, você está fazendo errado.

Conte sua idéia pra muitas pessoas e descubra se elas usariam. Não se preocupe, ninguém vai roubar sua idéia, ela não é tão boa assim e todo mundo tem mais o que fazer. Melhor ainda, faça pra você mesmo, que é garantido que você terá pelo menos um usuário. Outros certamente virão.

Lembre-se: só adianta fazer a coisa certo quando você está fazendo a coisa certa.