Recentemente muita gente tem me procurado nos instant messengers da vida para perguntar sobre tendências. Existe uma idéia no Brasil de que quem está de for a “traz as novidades”. Isso podia ser verdade antes da Internet mas agora as coisas se espalham com tanta velocidade que em muitos aspectos o Brasil está muito na frente da Austrália.
Mas existe o outro lado que é o trabalho na ThoughtWorks. Os projetos que nós enfrentamos geralmente começam da mesma maneira que os que qualquer consultoria, de três letrinhas ou três pessoas, enfrenta. O diferencial que faz ser um lugar interessante para se trabalhar é o que acontece durante o projeto.
O que segue neste post é uma amarrado de impressões pessoais sobre os últimos doze meses, tanto sobre a Austrália quanto o que sei de outros escritórios. Se ele não for coeso ou fácil de ler eu peço desculpas mas encare como um braindump.
Os projetos para bancos e empresas do mercado financeiro em geral continuam bem parecidos. Em 2007 houve uma euforia em torno da bolha econômica e muitos projetos megalomaníacos –e, por conseqüência, extremamente interessantes do ponto de vista técnico- apareceram mas a crise os tirou do baralho nos tempos recentes. Os bancos estão gastando menos e buscando fazer mais dinheiro reutilizando a estrutura existente. A maioria dos projetos que eu tenho conhecimento dentro de bancos é para estender uma determinada oferta para novos clientes ou é para migrar de uma plataforma legada para algo menos dispendioso.
O interessante sobre o “legado dispendioso”, dentro e fora de bancos, é que muitas vezes ele se trata de coisinhas como WebSphere, Aqualogic, Biztalk, Tibco e produtos parecidos. Apos gastar rios de dinheiro implantando estes e não ver nenhum centavo de retorno real muitos dos grandes estão migrando para plataformas mais eficientes, quase sempre baseadas em software livre. Hoje em dia são comuns projetos de migração de Websphere para Jetty ou de BizTalk para serviços RESTful usando IIS, JSON e ASP.Net MVC, por exemplo.
Na parte de aplicações para Internet, onde geralmente eu me envolvo mais, as coisas também têm mudado bastante. Basicamente os projetos têm se dividido em startups e legado. As startups aparecem com um problema e algum montante de dinheiro. A plataforma mais utilizada para atender estes cenários é Ruby on Rails, geralmente fazendo deployment em algum serviço de Cloud Computing.
Cloud Computing é um tópico extremamente relevante tanto para ThoughtWorks quanto nos nossos clientes. Uma das coisas interessantes que fizemos no início do ano foi trabalhar junto com o Google no lançamento da AppEngine em Java (e outras linguagens).
As empresas com legado de Internet são sempre interessantes. Geralmente elas são algum grande prestador de serviço na área de mídia e possuem um ou mais websites antigos que têm aquela arquitetura manjada de rodar em um Weblogic ou Tomcat com um Apache de front-end. O problema é que hoje em dia o numero de usuários é muito superior e a velocidade com que funcionalidades têm que ser adicionadas e alteradas é muito maior. Após entender que os Googles e Facebooks da vida não usam Java EE e não pagam licença para a IBM as empresas estão desesperadas para atingir o mesmo nível de eficiência.
O que temos feito nesta área é utilizar a já citada Cloud Computing para realizar tarefas que não precisam ser executadas dentro do firewall (de crawling até rodar teste de carga), refatorar aplicações grandes para atingir escalabilidade horizontal e simplificar processos de deployment e gerenciamento de recursos.
Na área mais de programação em si as coisas não têm sido lá muito excitantes. As plataformas em específico não têm nenhuma novidade marcante mas a programação poliglota é uma realidade. Até hoje todos os projetos que tive alguma participação dentro da ThoughtWorks utilizavam mais de uma linguagem de programação (já descontando Bash e JavaScript).
Uma surpresa agradável foi a que tive no meu projeto atual, em que voltei a programar em .Net após 3 anos afastado. A maioria das coisas que eu realmente não gostava sobre C# e seu ecossistema foram removidos (exceto Windows e Visual Studio, duas peças que eu considero de qualidade inferior). A Microsoft continua enfiando frameworks e ferramentas terríveis pela guela dos seus clientes (MSBuild? TFS? WCF? WTF?!?) mas no geral as coisas estão bem melhores.
Em termos de livros sobre programação eu tenho me focado quase que exclusivamente nos conceitos presentes em linguagens e paradigmas de programação. Esta é a lista de livros relacionados que eu li desde que cheguei aqui:
Esta é a fila dos que faltam:
(fora os que ainda estão no meu carrinho de compras na Amazon. Livro na Austrália é ridiculamente caro)
Na parte de gerenciamento de projetos e metodologias as coisas estão engraçadas. Tem horas que a euforia anima, tem hora que dá náusea. Eu acho que o Bellware resumiu muito bem:
early agile adopters were looking for a way to do things better. later adopters are just trying to do agile, thus the failures
Eu vim para a ThoughtWorks para ver como é que quem introduz métodos ágeis há anos trabalha. Nos últimos meses eu trabalhei com pessoas que fazem isto há mais de dez anos e em empresas que adotaram agile antes de eu saber que ele existia. O que eu aprendi neste período inicial é exatamente o descrito acima: quando seu objetivo é ser ágil você falha, quando seu objetivo é sempre melhorar você tem chances de sucesso.
Todos os projetos que participei foram bem sucedidos? Depende de para quem você pergunta. Mesmo os clientes mais difíceis que tive acabaram ficando satisfeitos no final mas muitos projetos que participei (e o número de projetos é bem maior que o número de clientes) foram executados de uma maneira que o time não ficou satisfeito. Eu acho que neste caso é perspectiva. Como a maioria dos projetos são um fracasso colossal basta ter algum nível de sucesso que o projeto vira referência. O time, em compensação, tem um critério de sucesso muito mais alto e não considera o projeto como bem-sucedido.
É claro que no fim das contas o que vale mais é a opinião do cliente –tanto porque o problema dele foi solucionado bem como porque é ele quem paga a conta no final- mas eu já vi diversos problemas decorrentes deste tipo de coisa. De builds que começaram em 10 minutos e terminaram em duas horas de duração até um time que perde 50% do seu tempo corrigindo defeitos por falta de uma suíte de testes decente. Os problemas podem não ser grandes para aquele projeto em específico mas não prestar atenção há eles é mortal em médio prazo.
Minha conclusão é que a indústria está num estado melhor do que há alguns anos atrás. Tecnicamente estamos entrando em uma espécie de renascimento e isso promete render muito material para posts aqui. Em termos de gerencia de projetos e processos as pessoas estão finalmente se convencendo que tudo tem limite, até ineficiência.
[...] Fragmental Post visualizado 1 [...]
O que noto é que no Brasil desenvolvedores entusiastas de agile ainda sofrem tentando nadar contra a maré de uma cultura voltada para modelos cascata pouco flexíveis e com a visão.de que criar uma boa suite de testes é uma verdadeira perca de tempo.
E não por pragmatismo, mas por tempo demasiado gasto em BDUFs da vida… ou tirania mesmo.
Não consigo entender como essa paralisia ‘burrocrática’ ainda é defendida.
Poder de persuasão a favor do waterfall? Não sei.
Só sei que, se há algo que gostaria de ver virar uma tendência aqui, é uma mudança cultural nesse sentido, facilitando, no Brasil, a ascenção de práticas agile fora das fronteiras geeks!
Muito bom saber como são as coisas por aí e como está sendo para você. Meus conetários:
1. Gostei muito do texto. Acho que vai bombar
2. Adorei as notas de cada livro com os links para a Amazon (mas não dá para ir direto)
3. Também li livro do Antlr mas achei dificil de ler no Metrô. Valeu enquanto lia mas graças a Deus já esqueci 90% dele.
4. Sorte sua que pode ganhar a vida em projetos para grandes empresas sem precisar fazer next, next nos WLIs e BPMs da vida e depois arrotar SOA nas mesas de bar ou no GUJ. Não que eu esteja nesta. Até já fui convidado. Mas é mais prazeiroso ganhar o rico dinheirinho sem precisar enganar a si próprio e principalmente sem criar um legado terrível que é o que os consultores/vendedores de ferramentas SOA estão fazendo com as empresas.
5. Já tinha visto o tanto que seu colega Mark posta sobre .NET Agora fico sabendo que também foi abduzido pelas forças do mal. Só falta um post dizendo que .NET é muito melhor do que JEE. Pensando pragmaticamente, não duvido disto.
Olá,
Ótimas experiências, realmente podem trazer algum benefício.
Quanto aos comentários sobre o .Net, é fato que gosto não se discute, contudo amadurecer é preciso e vejo que algumas das tecnologias que a MS tem empurrado aos seus clientes apresentam este amadurecimento trazendo ganhos sensíveis em inúmeros projetos de grande porte que tenho participado.
[]’s
Ricardo Cunha
Oi, Ricardo,
Não sei exatamente como responder ao seu comentário. É mais que gosto já que eu convivo diariamene com .net e outras plataformas e posso fazer uma comparação com alguma base prática, além da teórica. A MS, assim como IBM, Sun e Oracle, possui alguns produtos bons e muitos ruins. É muito interessante ver que a comunidade está procurando alternativas (Nant, Nunit, NHibernate, Rake, Castle, Mono, etc.) mas ainda é triste ver que a maioria dos desenvolvedores prefere a solução com o selinho MS, mesmo quando ela é inferior -como as citadas.
[]s
Olá,
Concordo contigo, esta também é minha linha de raciocinío.
Minhas considerações na verdade baseam-se na maneira perjorativa como alguns comentários procuram comparar tecnologias quando, na verdade, na minha ótica, são imcoparáveis, mesmo tendo como objetivo final muitas coisas em comum. Talves pelo “time” de cada uma delas e da filosofia das pessoas que as conduzem… bem… mas não era este o foco do post, não é mesmo?
Parabéns pelo blog, tenho acompanhado faz uns 2 meses e tenho me divertido muito.
[]’s
Olá Phillip,
Parabéns pelo Post! Como sempre de ótima qualidade e acrescentando muito para a minha vida profissional.
Um abraço
Eu sempre tive uma certa curiosidade para saber como funciona no exterior a relacão cliente x fornecedor. Imagino que não seja como no Brasil, onde o fornecedor sempre está errado por padrão, mas também não creio que seja as mil maravilhas. No entanto, acredito que deva ser uma relacão muito mais profissional do que o comum por aqui, que você deve conhecer muito bem. Como funciona isso por aí?
Me canso (literalmente) de ver muitas situacões onde o lado político desse relacionamento tem muito mais forca do que uma eficiência técnica pelo menos mediana. Em outras palavras, muita gente prefere “dar” projetos para fornecedores que “fazem-rir” do que para fornecedores que demonstram competência técnica e profissional. Sem querer me iludir, mas isso me frustra.
‘Existe uma idéia no Brasil de que quem está de for a “traz as novidades”.’
Eu acho que na maioria das vezes, esse que é o caso… Não sei se aí fora o pessoal é mais atualizado, mas no Brasil a grande maioria dos ambientes de desenvolvimento é bem desatualizado com as ultimas tecnologias.