#ffffuuuuconf

“Toda unanimidade é burra”. Talvez por isso prefiro diversidade de opiniões e perspectivas. Afinal, o que você espera aprender de pessoas que pensam igual a ti?

A Ffffuuuu Conf foi mais ou menos assim. Fui lá não porque queria ver uma opinião divergente, mas porque algumas das pessoas mais bacanas com quem já trabalhei fariam apresentações. E eu sabia que eles tinham algo a dizer.

Além disso, o espírito subversivo da conferência era instigante. Seria o oposto do que se vê na maioria das conferências, infestadas por drug-dealer-wannabes, com um “use isso que é legal”. Não! O espírito é o oposto: “use isso e se f*oda”!

E que venham as trollagens!

A keynote “Patterns of fail” foi épica. Ela apresentou aguns padrões que (infelizmente) presenciei. Também tinha o maior índice de trollagens por slide quadrado da conferência.
Gostei, em especial de:

• “The most interesting and character defining trait of these people is how they recovered” (de um #fail)
• Bikeshedding: quando todo mundo vai discutir picuinha. Já tinha visto isso, mas nunca imaginei que teria uma página na wikipedia. Pensei que, no máximo, numa tirinha do Dilbert.
• Behavioral Patterns, que foi o coração da apresentação. De chorar de rir… e de tristeza.

Só não posso concordar com alguns comentários sobre a 37signals & cia. Agora não me lembro de nenhum argumento em específico, mas só uma sensação de desdém sobre o trabalho deles. E sobre os fanboys que se acham depois de lerem o livro. Mas o problema não é do livro, pois eles também se achariam depois de verem meia dúzia de posts no highscalability.com.

Sinto muito, mas os caras são muito bons. Quanto ao livro, é meio um monte de causos, bem parecidos com o que já tinham escrito no blog. E alguns causos merecem ser contados, não por definirem uma verdade absoluta ou uma receita de sucesso, mas por trazerem uma perspectiva interessante. O errado é interpretar a experiência alheia, mesmo que contundente, como uma verdade científica. Vai ter gente achando que o livro é óbvio (eu, por exemplo, que já conhecia a maior parte dos pontos de vista apresentados), e vai ter gente que vai achar o livro revelador. Mas vamos voltar à ffffuuuu conf, que aqui não é sobre a 37…

Não sei como não rolou um banho de sangue depois desta apresentação.

Depois veio a excelente “Agile or Fragile”, do Rodrigo Campos.

Além do conteúdo bacana, ela fechava cada sessão com “possíveis soluções” para cada #fail.

Gostei principalmente de:

• Continuous development is not an excuse for short sighted definitions
• “new story: now we need to get back to earth safe and sound.” #hehe
• “You need to control the Drama Queens” #epic
• “The risk homeostasis syndrome” Não conhecia esse negócio. Chamei algo parecido com isso de “síndrome do coelho presunçoso”, no qual pessoas ficam cada vez mais displicentes à medida em que se apoiam em ferramentas melhores.

E aí vão alguns comentários:

• Pair programming: tal como as duplas de comédia, não é para qualquer um(s) nem para qualquer hora. Mas pode ser uma técnica válida, dependendo das pessoas envolvidas, do motivo e do momento. #captainobvious
• QA: um negócio que fiz uma vez foi deixar a turma de QA testando o produto do sprint anterior. Assim: os testes começavam durante o sprint e se intensificavam no final dele, mas seguiam um pouco além. Basicamente, QA seguia um ciclo diferente do desenvolvimento.

A Itil for failers foi ótima, e serviu para tirar um peso de não ter dado bola p/ Itil ou tentado implantar isso bonitinho.

Era algo que eu desconfiava, mas ficou mais claro agora.

Depois veio a mega-rápida-palestra do Fábio Akita. Prá variar, foi ótima.

Mas em algum momento ele dizia algo como “metodologias são supertições”. Discordo, pois percebo que metodologias têm supertições, o que é algo bem diferente. Se são, nem compensa pensar em olhar. Se têm, pode ser interessante tentar separar o que é útil do que é coincidência. Eventualmente tem algo lá que te sirva, nem que seja para falar mal (ffffuuuu).

Também citava que geralmente, quando alguma coisa não dava certo, tendíamos a nos culpar, dizendo que não usávamos a metodologia direito. Beleza, concordo até certo ponto. Algumas pessoas têm este perfil (mea culpa!), outras não. De vez em quando o problema está com a metodologia (tá errada!), ou com as pessoas (não se aplica neste contexto, não entendeu, …).

Minha experiêcia diz que, em geral, somos péssimos para entender e, por extensão, aplicar novos conceitos.

• Geralmente temos preguiça na hora de ler/buscar a informação, o que já f*ode tudo.
• Não temos a humildade para pensar que, talvez, tal coisa mereça uma análise mais profunda ao invés do “já entendi” depois de ler as primeiras duas páginas.
• Adoramos martelar a idéia à realidade. Não moldar ou enxergar, mas martelar. Usar o GIT como o SVN não dá certo. Nem achar que na Inception se levanta os requisitos ou que Scrum Master distribui tarefas. Mindset x abertura para novos conceitos.
• E muitas coisas exigem disciplina e preparação.

Quando é que o auto-engano está ligado e não percebemos que somos índios teimosos que tentam a dança da chuva mais uma vez ou que não estamos prontos? Não tenho a mínima idéia!

No final, me lembrei de algo que li faz tempo e que acho cada vez melhor: Enough of Processes: Let’s Do Practices, do Jacobson.

A apresentação do Ivan (You shall not get excited) foi, prá variar, ótima… e hilária. Me lembrou suas apresentações de OpenGL na UFMG.

E a citação “Ignorance more frequently begets confidence than does knowledge” também me fez lembrar de:

• “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.” — Mark Twain
• “The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts.” — Bertrand Russell

Só que foi pro lado do sucesso com o Erlang meio cedo: estava esperando mais histórias de fracasso. Era a ffffuuuu conf, afinal.

A do Trentas, How Not To Use The Right Tool For The Wrong Reason também foi bacana, mas ficou no contexto de infra/sysadmin. O que não foi bem o que eu esperava, até por que vi casos exatamente como o título.

Por fim, a apresentação do Renato Lucindo, Software Instability. Realmente são poucos os desenvolvedores que pensam que o negócio pode (vai!) dar m*rda algum dia e que uma voadora na cabeça para acordar é sempre bem vinda. Só de lembrar quando eu pedia pro povo para usar a p*rra do log direito… aaaargh!

Um ponto que pode ter sido polêmico foi sua observação sobre “No mocks”, na parte “Tests that matter”. Isso é um ponto muito #ffffuuuu para mim.

Nos últimos tempos, vejo o uso de testes unitários com um misto de satisfação e preocupação. Comecei a usar essa tranqueira em 2001 (com o JUnit e eventual TDD) e sempre buzinei no ouvido de muita gente que isto era um negócio legal, mas fiquei ANOS sem ter um feedback positivo (será que ninguém usa isso? #foreveralone). Nos últimos 2-3 anos foi que vi o pessoal comprar a idéia. Legal, né? Não!

O que vi foi, na verdade, o milagre da multiplicação dos mocks, de gente pedindo mais tempo para fazer os testes unitários, sistemas buguentos cheios de testes frágeis, que TDD é um axioma e que nada que presta foi feito sem isso, hudson-verde-tchau, dogmas e mais dogmas. Aaaarrrgggghhhh!!!! Sensação total de #ffffuuuu + #foreveralone. Vai tentar falar em testes automatizados depois disso!

E foi só. Tive que sair mais cedo e não pude voltar. Daí perdi as lightning talks, como a elogiada How to CrAP. :(

O mantra que mais se repetiu: contrate pessoal bom, demita os idiotas. O pessoal bom também vai falhar, mas consegue se virar.

E métodos prontinhos e bestas que qualquer curió pode seguir? Não! No final, só quem merece deve ser condenado à liberdade.