1up4Developers

Bom pessoal, já faz um tempo que não escrevo, isso se deve um pouco pela falta de tempo, mas muito pela falta de vergonha na cara! Sempre tenho idéias, mas pouca atitude. Como muitos sabem, em outubro passado o 1up4dev esteve representado no Rails Summit Latin America por mim, pelo Roger Leite e pelo André Farina. Muita coisa aconteceu naquele evento, e isso com certeza ficou evidente em muitos posts por aí (post do shadow, akitaonrails e muitos outros). As palestras simplesmente foram inspiradoras, enriquecedoras e com certeza mudaram a cabeça de muita gente, não tem como não se empolgar ao ver caras como Chad Fowler e Obie Fernandez falando! Os caras arrasaram em todos os sentidos. O fato de poder entrar em contato com figuras da comunidade que muitas vezes você só acompanha via GitHub, e melhor, poder trocar uma idéia com essa galera é muito legal.

Com certeza todos ficaram com um gostinho de quero mais, e com uma imensa vontade de agradecer ao Fábio Akita e todos aqueles que tornaram este evento possível. Mas uma coisa que não vi ser muito falada foi o happy hour que aconteceu ao final do último dia. Você consegue imaginar como seria poder tomar uma breja com o cara que escreveu um de seus livros preferidos?! Ou o cara que mantém aquele blog que te inspirou a aprender ruby/rails? Melhor ainda. Imagine poder passar um momento falando besteiras e dando muita risada com esses caras?! Bom, eu passei por isso!! E até agora a ficha parece não ter caído, não consigo acreditar que passei por isso.

Bom, para organizar os fatos a coisa aconteceu mais ou menos assim. Depois do fim da palestra do Obie Fernandez toda galera correu para tiras fotos, pegar autógrafos e coisas do tipo, foi agitação total como era esperado. Feito isso, o pessoal da organização começou a servir espumante e cerveja no saguão e é claro que corremos para lá. Foi muito legal, pois nesse momento conseguimos conhecer mais gente e ainda presenciar Dr Nic mandando ver numa Skol gelada! Nesse momento começou um movimento revolucionário lutando por uma causa que eu considerei mais que justa, procurar um lugar para comer e beber mais cerveja (e depois algumas caipirinhas, como pode ser confirmado pelo próprio Dr Nic no video abaixo!). Surgiu a idéia de comer um sushi, e é claro que só podia ser no bairro da Liberdade.

Rails Summit Happy Hourt, chegada from miguel aranha baldi horlle on Vimeo.

Nesse momento todos se mobilizaram, e o pessoal da LocaWeb ainda deu uma força na logistica, e todos foram para um restaurante na Liberdade. Muitos pegaram carona (como eu!), outros foram na Van da LocaWeb, mas o importante é que depois de algumas voltas estávamos todos lá. Simplesmente lotamos o lugar, um monte de nerds loucos para comer e tomar umas cervejas, todos loucos depois de um evento como esse. A galera se organizou em várias mesas, e fiquei em uma mesa com o Ricardo Yasuda (shadow) e o Márcio Trindade. Junto com a gente estava Dr Nic e um argentino maluco (qual que não é?! huahauhua). Em outras mesas estavam Obie Fernandez, Chad Fowler, Chris Wanstrath, David Chelimsky! A galera do Phusion Passenger também estava lá, assim como Vinicius Teles, Juan Bernabó e muitos outros (Incluindo Fábio Akita!). Bom, o resto foi um misto de muita bebida, risadas, e claro, muito papo nerd. E o mais legal de tudo é que sobrou um pouco de bateria na filmadora e eu consegui filmar alguma coisa (com a ajuda do nosso amigo argentino, que se alguem lembrar do nome por favor me avise).

O mais legal de tudo isso foi poder conhecer muita gente legal, ter contato com meus ídolos e ver que estes são pessoas muito acessiveis. Certamente esse dia não vai sair de minha lembrança, um abraço pra galera que esteve lá, devido ao nível alcoolico do momento não me lembro do nome de todos, huahuahuaha. E fica a chamada pra galera, quem esteve lá nessa noite por favor se manifeste e comente aí, gostaria de saber o nome da galera.

Rails Summit Happy Hour, hino nacional from miguel aranha baldi horlle on Vimeo.

Observações: Conforme eu for subindo mais videos no Vimeo eu vou atualizando este post, portanto fiquem ligados! Tentei deixar os videos em uma boa qualidade para quem for baixar. Ainda tenho que editar a maior parte da filmagem que foi feita pelo argentino maluco, que logo no inicio pegou a camera de mim e não soltou mais até acabar a bateria!

Espero que mais eventos como esse aconteçam, e que a galera compareça e participe como participou neste evento, abraço à todos!

Desenvolver software é uma atividade muito gratificante pois sempre podemos (ou deveríamos) exercitar nossa criatividade para solucionar os problemas dos clientes. Isto, apesar de divertido pode ser perigoso e/ou catastrófico se estivermos com o foco errado. Num ambiente cascateiro, onde cada envolvido está comprometido apenas com o processo e não se preocupa verdadeiramente com os problemas dos clientes, não é difícil que isto ocorra. Quase sempre o foco acaba sendo direcionado para a solução ao invés do problema.

Mas qual a diferença entre foco no problema ou solução? Vamos a um exemplo:

Quando a Nasa enviou os primeiros astronautas ao espaço, descobriu que as canetas não funcionavam com gravidade zero. Para resolver esse problema, os engenheiros contrataram uma empresa especializada para projetar a caneta espacial.
Dez anos e US$ 12 milhões depois, estava pronta a caneta que podia ser usada no espaço, em qualquer posição. Nem a temperatura poderia atrapalhar: a supercaneta funcionava bem fizesse frio ou calor.
Os russos, que tiveram o mesmo problema, optaram por uma solução mais simples: passaram a usar um lápis.

A história acima é bem famosa e mesmo sendo falsa, demonstra muito bem o que acontece quando o problema não está em foco. Neste caso, o problema é a impossibilidade de escrever em gravidade zero. Uma das soluções seria uma caneta que escreva nessas condições. Veja que aqui a solução já está em foco. Outra solução para o problema seria utilizar algo que escrevesse em gravidade zero: um pedaço de carvão ou um giz já serviriam. Assim, o problema seria resolvido.

Outro exemplo de falta de foco no problema é esta história da fábrica de pasta de dente, onde ocasionalmente algumas caixas da pasta de dente eram entregues vazias. Para eliminar este problema, a empresa gastou investiu milhões para garantir que durante a fabricação, nenhuma caixa ficasse sem o tubo de pasta de dente dentro. Mas o problema foi realmente resolvido depois que um operário deixou um ventilador soprando as caixas vazias para fora da esteira de produção. Simples não?

Na área de desenvolvimento de software não é tão raro acontecer algo parecido, onde o foco está inteiramente na solução. Sabe aquele sistema meio capenga, que funciona e dá dinheiro para empresa mas não é “web 2.0″ nem utiliza conceitos de “SOA”? De repente a diretoria decide que este sistema deve ser “migrado” para uma tecnologia da moda mais atual, que o permita “evoluir” mais facilmente.

Para atender esta necessidade, normalmente uma equipe nova é contratada, toneladas de documentos e diagramas são produzidos até que os programadores comecem a codificar. A esta altura, o prazo já está apertado e os “stakeholders” ainda não viram os resultados. Depois de muito tempo e dinheiro desperdiçados, um sistema feito às pressas, bonitinho mas meia-boca, é entregue com os mesmos defeitos do anterior. E o problema não foi resolvido…

Desenvolver software deve ser um investimento lucrativo, proporcionando algum ganho às partes envolvidas. Quando uma necessidade surgir, o primeiro passo é identificar o problema para então encontrar a melhor solução, ou seja, foco no problema. Neste exemplo da “migração”, o problema é que a manutenção do software atual é muito cara, porém “migrar” o sistema inteiro não vai resolver o problema, no máximo criará um novo.

Mas de quem é a culpa quando o foco está na solução? Eu respondo: a cascata! Apesar das metodologias ágeis estarem em alta e aos poucos serem adotadas pelas empresas, a maldição do waterfall ainda é está entre nós. Clientes continuam com a mania de pedir tudo no início do projeto. Ao exporem seus problemas, já estão pensando na solução. Fazem questão de engordar o escopo com coisas das quais não têm certeza da utilidade, mas querem que estejam lá pois podem precisar um dia. Os desenvolvedores também não estão isentos dessa culpa. Um legítimo analista cascateiro não se envolve com os problemas do cliente, apenas ouvem suas solicitações e transformam em casos de uso ou diagramas. É aí que uma simples necessidade se transforma numa bola de neve e a lenda da caneta da Nasa se repete…

Um verdadeiro desenvolvedor ágil deve se comprometer com o cliente, ouvir, entender e se envolver com suas necessidades para então sugerir uma solução simples, focada e que resolva o problema. Esta interação é muito importante e deve ser constante, pois o cliente passa a identificar o que realmente ele precisa, ou seja, o qual seu problema! Assim, começa a se concentrar em funcionalidades que realmente serão úteis e agregarão valor ao software e, consequentemente, ao negócio. Feedback é muito importante. O pessoal do Google sabe muito bem disso…

Este post é uma homenagem aos Arquitetos defensores do waterfall/cascata.

Recentemente tive o desprazer de conhecer um arquiteto, é isso mesmo, aquele com certificado e tudo, com direito a broche da Sun em seu terninho. Aliás, certificado é um tema polêmico que eu não tenho uma opinião muito certa e/ou formada… bom, vou deixar esta parte para um próximo post, quem sabe.

Voltando ao assunto, hoje no fretado, comecei a pensar nas semelhanças que um arquiteto de sistemas (certificado que decorou patterns inutéis da Sun) tem com um arquiteto de obras. Só para deixar claro, na tabela abaixo estou usando dois estados: FAIL e Ok. Fail quer dizer que vai dá merda não vai dar certo e não tem jeito, caso queira uma definição mais formal, o wikipédia ajuda, agora se você prefere imagens, o Fail Blog também serve.

Exemplo de FAIL

Parei a tabela por aqui pois já dá pra saber que o FAIL tende a infinito né.
Pergunta: o que ambos arquitetos estão fazendo!?!
Resposta educada: Estão fechando o escopo do projeto.

Arquiteto Cascateiro trabalhando ...

A resposta acima é uma frase chave pra você ter certeza que vive num projeto waterfall cascateiro. Fechar o escopo do projeto inteiro deve ser muito bom para o arquiteto de obras, já para um sistema, o efeito é contrário. Acredito muito na teoria que desenvolver software não é construir prédios. Livros de renome como Pragmatic Programmer citam isso.

Sei que este tema de construção civil já está batido. Comecei a escrever este post ao mesmo tempo que o Sr. Panachi publicou o anterior, e com a idéia de ficar menos repetitivo, já vou linkar as sugestões dos nossos incríveis leitores:

• O Diego Carrion (grande peruano! :D) cita este link, que fala que a engenharia civil também consegue ser ágil em alguns casos.
• O Witaro, fez um ótimo post “Desenvolvendo software como uma Rock Band” que quebra a barreira da analogia com a engenharia civil. Cara, continue escrevendo, porque a sua visão é muito legal!

Bom, agora que acabou o desabafo, vamos as possíveis soluções. O que fazer com o Arquiteto Cascateiro?

Acho que a primeira coisa seria conscientizá-lo de que ele não é o Oscar Niemeyer e que a primeira versão de seu software nunca será completa de uma vez. Você deve conversar sobre iterações com ele e mostrar que o software deve evoluir conforme o cliente também evolui nas descobertas das suas reais necessidades. Sei que o post já está cheio de links, mas este post do Phillip Calçado, Analista Pedreiro, resume bem o que quero dizer.

Arquiteto, este nome ou termo ou cargo ou seja-lá-o-que-for, é coisa de modelo waterfall/cascata. Numa equipe, não deve haver distinção desta maneira. Todos programam, modelam, configuram, trabalham no Banco de Dados quando necessário, ou seja, ninguém deve exercer um papel único. Papéis únicos, representam Guardiões que defendem somente seus interesses e não trabalham em pró da equipe/cliente/projeto.

O Arquiteto deve programar, colocar a mão na massa, assim como toda a equipe, pois UML, Caso de Uso, Diagrama de Sequência, etc. sempre compilam! Muito diferente na vida real, onde muitas vezes você é obrigado a implementar uma coisa diferente e torta para acompanhar estes documentos cascateiros. Caso você seja obrigado a gerar a documentação fútil acima, pense em algo que seja automatizado após você ter programado e testado, com certeza você será umas cinco vezes mais produtivo.

E por último e não menos importante, a equipe (inclusive o Arquiteto) tem que conhecer o negócio que implementa. Quando se inicia um novo projeto ou até mesmo decidem reestruturar um existente, o arquiteto cascateiro sempre prioriza novas tecnologias e frameworks, o que na maioria das vezes, não é necessário. Novos projetos ou refactoring em existentes, devem ter um único prioritário objetivo: KISS. Com esta prioridade em mente, novas tecnologias e frameworks serão escolhidos naturalmente, e não somente usar porque é a última moda no estilo SunTechDays.

E vocês leitores?! Sofrem ou já sofreram muito com Arquitetos Cascateiros!?!

Se você freqüenta este blog já deve ter percebido que nós não gostamos da maldita cascata. Fases bem definidas, detalhamento de requisitos, documentos inúteis, diagramas UML, papéis… tudo muito lindo na teoria. Eu fico até emocionado quando leio a documentação do RUP. Mas infelizmente a maioria dos profissionais de TI precisam são obrigados a trabalhar nestes ambientes cascateiros, enfrentando chefes sem noção, colegas com síndrome do funcionário público, prazos sem sentido, entre outras pérolas da área.

O principal apelo de um processo cascateiro são suas fases e papéis bem definidos, onde cada membro da “equipe” é responsável por uma determinada tarefa que é executada em uma seqüência previamente definida. Dentre os papéis, pode-se facilmente identificar os especialistas daquela tarefa, que defendem sua necessidade execução com unhas e dentes. Para ilustrar, resolvi chamá-los de guardiões, seja da tecnologia ou da atividade em questão. Um guardião protege sua fase, tarefa e interesses, defendendo-os para que o “processo” não seja quebrado. Desta forma, <sarcasmo> a “equipe” atinge seu objetivo: o software! </sarcasmo> Seguem alguns exemplos desses guardiões cascateiros:

O guardião do banco de dados: “Não rodarás nenhum script na base alheia“
Começo por este por ser o mais comum dos guardiões. Ele trata o banco de dados como um filho, mesmo que seja um adolescente que não obedeça inteiramente à 3ª regra normal. São vistos como semi-deuses, capazes de transcrever o modelo de negócio da empresa em uma linguagem de alto nível, impossível de ser compreendida por simples programadores. Protejem as tabelas com a própria vida e qualquer alteração na base de dados é motivo para um duelo até a morte! Utilizam um padrão para nomenclatura de campos que somente é conhecido pelo clã dos DBAs. Geralmente são seguidores do Oráculo, o senhor de todos os bancos de dados.

O guardião do projeto: “Guia-te pelo teu Gantt e serás recompensado”
Este guardião está presente em todos os projetos, garantindo que a palavra do Gantt seja cumprida, protegendo o escopo do projeto com a própria vida (ou a vida de algum programador). Adicionalmente atua como roteador de atividades: recebe os requisitos pelo email, encaminha para um recurso disponível (programador) que estima o esforço e define uma data de entrega, devolvendo para o guardião que atualiza seu Project.

O guardião do framework: “Venerarás o Struts e nada te faltarás”
O framework é o objeto de adoração deste guardião, nenhum outro framework é tão bom quanto o que ele venera. Ele provê solução para todos seus problemas simplesmente escrevendo um bloco de XML aqui, outro ali, mudando aquela linha acolá e estendendo uma classe X implementando aquela interface Z. Qualquer evolução do framework em questão não passa de uma tentativa frustrada de “reinventar a roda”.

O guardião da arquitetura: “Não usarás a instância do teu objeto em vão”
Uma variação interessante de guardião, que neutraliza seu oponente através de técnicas de tortura e perturbação mental, inundando as sessões de brainstorm com uma enxurrada de DTO’s, VO’s, Facades, EJB’s entre outros patterns que fazem a cabeça dos programadores entrar em conflito, até que seus órgãos faleçam (ou simplesmente se demitam). Geralmente são cúmplices dos guardiões do projeto, conspirando para a dominação do Gannt.

O guardião do root: “Teu processo não executarás no meu bash”
A jóia mais preciosa da empresa: a senha do root. Seu guardião é o mais honrado dos seres, sendo uma espécie de Frodo, protegendo-a com a própria vida pois uma vez em mãos erradas pode ser usada para a destruição da humanidade (ou apenas para reiniciar aquela instância do Tomcat travado em produção). Aquele que desafia este guardião perde o direito de executar seus processos como administrador local e fica vagando pelo filesystem eternamente.

O guardião dos guardiões: “Tua TI é um mal necessário”
Também conhecido como diretor, presidente, CEO, dono, investidor, sócio, etc. É o guardião das decisões, aquele que protege sua riqueza acima de tudo, economizando nos salários, contratando funcionários despreparados e investindo rios de dinheiro em consultorias e licenças de software para garantir seus investimentos.

Enfim, são guardiões dos próprios interesses. A “equipe” é apenas uma palavra que usam em discursos mas nunca aplicaram o conceito na prática!