Em julho, o EuroPython 2013 ocorreu em Florença, Itália, pelo terceiro ano consecutivo. Um pouco sobre mim: sou italiano e sou programador Python, por isso estou entusiasmado para compartilhar mais sobre minha experiência no EuroPython. Python possui uma comunidade incrível, cheia de algumas das pessoas mais inteligentes e inspiradoras da indústria de TI. Após fazer parte desta comunidade por sete anos, posso dizer honestamente que as conferências de Python são todas sobre as pessoas. As pessoas tornam esta comunidade grandiosa.
Uma dessas pessoas inspiradoras é Alex Martelli, engenheiro sênior da Google e membro da Fundação de Software Python. Ele apresentou uma palestra principal na EuroPython deste ano intitulada “Bom o Suficiente” é Bom o Suficiente! ou, como ele disse, citando Richard Gabriel: a abordagem de Nova Jersey, conhecida como “Pior é Melhor” versus a “abordagem do MIT/Stanford, conhecida como “A Coisa Certa.” Eu não tinha certeza sobre o que ele falaria, mas o título era intrigante. E uma coisa que aprendi com as palestras de Martelli nos últimos sete anos é que quando ele fala, a melhor coisa a fazer é ouvir, aprender e tomar notas. Então, foi exatamente isso que eu fiz.
A palestra principal examinou duas abordagens diferentes para lançamento de software. A primeira, “A Coisa Certa”, recomenda buscar a perfeição (aceitar um lançamento de software que esteja abaixo de “perfeito” é um compromisso lamentável). A segunda, “Pior é Melhor”, diz mantenha simples, apenas bom o suficiente, lance cedo, lance frequentemente, obtenha bastante feedback (esta é a “abordagem de Nova Jersey” porque Unix é um bom exemplo e foi escrito em Nova Jersey).
Martelli explicou como Richard Gabriel identificou quatro valores fundamentais que ambas abordagens têm em comum: simplicidade, correção, consistência e completude. Ele prosseguiu explicando que o que realmente importa é a prioridade dada a esses valores. As conclusões de Gabriel podem ser resumidas por estas duas citações:
A filosofia do fazer certo é baseada em deixar os especialistas fazerem o seu trabalho de especialistas
coisa até o fim antes que os usuários coloquem as mãos nela.
Worse-is-better tira proveito das vantagens naturais do incremento
desenvolvimento. A melhoria incremental satisfaz algumas necessidades humanas…
Ele foi ainda mais longe, apontando como a interpretação de Gabriel se aproxima do que Eric Raymond descreveu em seu livro, “A Catedral e o Bazar”, no qual ele descreveu dois modelos divergentes de desenvolvimento de software: a catedral, onde os especialistas estão no comando e o núcleo é tudo sobre especialistas fazendo suas coisas de especialistas, versus o Bazar que é fonte colaborativa e caótica, onde a multidão está no comando e inclui pessoas que estão diretamente envolvidas, mas inevitavelmente até mesmo pessoas que estão apenas ajudando estão lá, porque precisam do produto do bazar para realizar trabalhos não relacionados.
Obviamente, o foco de Raymond estava nos bugs e ele acreditava que um milhão de olhos tornaria o processo de descoberta de bugs mais rápido – e esse é exatamente o ponto. Para ter um milhão de pessoas olhando para isso, você tem que liberar o código. Você tem que colocá-lo no mundo real e deixar as pessoas usarem. Como Martelli disse, se você quer liberar apenas a “Perfeição,” se você quer que o especialista faça o trabalho de especialista, então você precisa de um “Grande Projeto Antecipado,” identificação perfeita dos requisitos, arquitetura perfeita, design perfeito, implementações perfeitas, etc. E isso vai demorar para sempre! Mas ainda mais importante, a vida real não tende a cooperar.
Para citar Martelli novamente, “A vida real não tende a cooperar.” Os requisitos mudam, e também a arquitetura, o design e a implementação. O desenvolvimento iterativo é o caminho a seguir. Implante algo, corrija bugs, melhore, use controle de versão, revisões de código, estilo de código, testes (se você não está testando, está pedindo problemas) e, por último, mas não menos importante, documente claramente o que você fez.
Isso não significa que devemos baixar nossas expectativas. Como Martelli apontou, “nosso sonho deve continuar grande, mas a melhor maneira de alcançar esses sonhos continua sendo lançar cedo, lançar frequentemente.” Ele continuou mostrando exemplos sobre arquiteturas perfeitas que nunca foram implementadas, lançadas, ou que perderam a batalha contra seus rivais não tão perfeitos, incluindo, Xanadu vs WWW, TCP/IP vs ISO/OSI, MIT ITS vs UNIX.
O vídeo da palestra principal tem cerca de uma hora de duração, mas eu realmente sugiro que todos que desenvolvem software devem assistir. Mesmo que você discorde das conclusões, é uma ótima fonte de informações. Gravação da palestra principal: http://www.youtube.com/watch?v=gHG9FRSlPxw
Minha grande questão após a palestra foi, ‘Quando o “suficientemente bom” é suficientemente bom?’ Quando chega esse momento, quando você está no meio de um processo de desenvolvimento, quando você pode dizer, “Ei, é hora!” Felizmente, a resposta para minha pergunta já estava na palestra de Martelli, apenas esperando para ser notada.
Dica: aqui está um trecho do artigo de Eric Ries, autor de “The Lean Startup”, Bom o suficiente nunca é (ou é?). Esta é a definição dele de “produto viável mínimo”.
“O produto mínimo viável é aquela versão de um novo produto que permite
uma equipe para coletar a quantidade máxima de aprendizado validado com o menor esforço.
Aí está! Essa é a resposta que eu estava procurando. Implemente algo que melhore a vida de alguém, algo que resolva um problema real do mundo. Faça isso assim que estiver em um estado que permita a você e sua equipe aprender com as interações reais dos usuários, coletar dados reais e receber feedbacks reais. Aprenda a lidar com o fato de que os usuários vivem no mundo real – e esse mundo é imperfeito. Mas a alternativa é pior; se você apenas esperar que seu software cresça até a perfeição dentro de uma catedral, você nunca o lançará.
A perfeição é um processo, não um estado. Parafraseando Eduardo Hughes Galeano, a utopia é como tentar chegar ao horizonte que você nunca alcançará, mas isso nos faz avançar.
