Fragmental

Meu post sobre Análise de Sistemas já teve 65 comentários (incluindo respostas, é claro). Acho que já descartei uns 20 comentários anônimos para este. Nem todos falavam da minha mãe, alguns tinham coisas interessantes mas infelizmente este blog não aprova comentários anônimos, sejam criticas interessantes ou xingamentos.

Esta manhã eu recebi um destes anônimos interessantes e, apesar de não o aprovar, gostaria de comentar trecho deste:

Francamente modelar com o código é o mesmo que fazer um projeto de uma casa com tijolo e cimento.

Este trecho me despertou o interesse porque há algum tempo fiz um experimento e gostaria de convidar vocês para repeti-lo. Como falei em posts anteriores Melbourne, minha cidade atual, é um lugar razoavelmente conhecido por suas boas universidades e centros de pesquisa. Como conheço alguns estudantes de graduação ou recém-formados (A ThoughtWorks possui um programa para contratar graduandos) eu conheci algumas pessoas que lecionam em universidade locais, entre eles uma simpática senhora que ensina disciplinas num curso de arquitetura e edificações local.

O dialogo foi sobre especificações, plantas e modelos.

- Imagine que a senhora pudesse, ao invés de criar um modelo em papel, construir seu projeto incrementalmente. Em dois dias a senhora tem o banheiro pronto, em três dias a varanda.
- Como numa maquete?
- Não, eles estão prontos mesmo. Você pode usar o banheiro, pode dormir no quarto, pode efetivamente utilizar o prédio.
- Mas e se eu precisar mudar algo? Isso iria ficar muito caro.
- Imagine que o custo é apenas o de dois dias de trabalho. Sem custo material. A cada dois dias você termina um pedaço da casa e mudar é tão simples quanto construir.
- Ok. Seria ótimo. Qual seu ponto?
- Isso ainda afaria requerer uma planta baixa, um modelo em papel ou AutoCAD?
- Precisaria porque eu preciso comunicar o projeto aos trabalhadores.
- Ah, sim, claro, mas imagina que construir não seja um trabalho braçal. Você tem, sei lá, robôs que sobem paredes e fazem o trabalho pesado, você só diz qual a dimensão, inclinação, que material, etc. e eles constroem. Você desenha no AutoCAD e os Robôs constroem imediatamente, daí você pode entrar no prédio e se tem algo errado em segundos você conserta. Você pode levar seu cliente para andar no prédio.
- Ok. Mas neste caso você não está eliminando o modelo gráfico.
- Não?
- Não, neste caso você automatizou a construção. O que você fez foi fazer com que o trabalho do arquiteto seja simplificado eliminando o custo da construção. Se qualquer coisa que eu mudar no modelo muda no prédio real imediatamente e sem custo o papel do modelo é ainda mais importante. Você não tem real diferença entre modelo e prédio. Você não tem transformação real entre um e outro. O modelo é o prédio.

Deste ponto eu comecei a explicar para ela como engenharia de software funciona. A conclusão que nós chegamos é que engenheiros de software possuem o poder que falta para engenheiros civis/arquitetos e ainda assim usam as ferramentas de quem não tem este poder.

Arquitetos adorariam modelar com tijolos, paredes e coisas reais. Eles não podem. Nós podemos.

Este tópico no GUJ chamou atenção, especialmente porque o li logo após um interessante texto noblog do Marcelo Araújo sobre uma outra faceta do mesmo tema: modelagem usando especificações não executáveis.

O que eu quero dizer com isso? Dada a tecnologia atual na maioria das empresas (desconsiderando o uso de coisas como DSLs ou mesmo alguma solução MDSD que, ao contrario de MDA, funcione) todos os documentos comumente utilizados para “modelagem” não são verificáveis, não são executáveis e requerem um trabalho manual enorme. Como bem disse o Emerson Macedo no post, você acaba programando duas vezes, uma na sua notação gráfica (UML) e uma na sua notação executável (Java, C#, Ruby… o que for).

Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?

Há algum tempo que eu me pergunto porque que se usa UML para “modelar”. Não me entenda mal, UML é uma ótima noção gráfica para Orientação a Objetos e com ela você consegue passar uma big picture muitas vezes mais rapidamente do que código; mas ela fica por aí: comunicação.

Quando modelamos o comportamento de objetos nós estamos descrevendo como este se comporta em diversas situações. Ao modelar uma determinada atividade você precisa descrever um conjunto grande de detalhes sobre esta, e UML não esta pronta para este tipo de coisa - e nem é a idéia por trás dela. Se modelar em UML fosse eficiente nós estaríamos programando em UML não em C#, Java ou o que for.

O primeiro problema ao tentar introduzir este pensamento na indústria é: mas eu não posso deixar que meus “implementadores” façam o que quiserem. Pergunta: o que raios é um implementador? Um datilografo de luxo?

Supondo que sua empresa seja a típica empresa de três letrinhas, aquelas que contratam qualquer um como “programador júnior” porque ele vai receber instruções do analista. Neste cenário eu pergunto: para que o tal programador? Que tal dar ao seu “analista” uma ferramenta mágica em que ele consiga criar um modelo abstrato e ao mesmo tempo executável? Que tal se ao invés de gastar rios de dinheiro pagando 10-reais-mais-o-busão para seus implementadores você eliminasse completamente a necessidade deles, fazendo com que o “analista” sozinho cuide do serviço?

Não precisa sacar seus milhões do banco nem pensar em como justificar o gasto com esta ferramenta no orçamento, você muito provavelmente já possui o necessário dentro da sua empresa: uma linguagem de programação decente. Faça seu “analista” usar código para expressar a modelagem. No final dá no mesmo para o nível de modelagem desejada e você ainda ganha algo verificável e executável. Economia de rios de dinheiro quase que instantânea.

Mas como assim? O “modelo lógico” é muito diferente do “modelo físico” e o “analista” não pode perder tempo com essas coisinhas de tecnologia, tem que pensar em modelar o negocio. Muito bem, duas coisas:

1. Analista de Sistemas não é analista de negócios. Se você não sabe o que é um analista de negócios eu recomendo que você mande um e-mail pro Paulo Vasconcellos perguntando.
2. Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo “diagrama de domínio”. POJO/POCO, Hibernate, IoC, Camadas, OO, AOP, EJB3, MVC… toda essa parafernália de letrinhas permite que seus objetos de negocio não tenham o menor traço de infra-estrutura. Claro que alguém vai ter que fazer a infra-estrutura –ainda que seja mínima. Caso seus “analistas” sejam de qualidade extremamente baixa eu recomendo que você contrate um bom técnico para atuar como arquiteto e líder técnico do time.

Verdade seja dita: esta não é a primeira vez que este blog trata do tema e desde a última vez muita coisa melhorou, mas ainda há muito que melhorar.

A melhor coisa sobre meu trabalho atual é que, como consultores, tentamos sempre pensar fora da caixa. Isso não é fácil numa consultoria, você pode imaginar, já que o mercado tende à empresas de três letrinhas que não se interessam tanto em otimizar ou melhorar e sim em cobrar por hora.

Um desses momentos recentes me fez passar por algo que eu nunca havia visto na pratica: como fazer deployment (instalação) e administração de software de maneira ágil?

O cliente em questão possui times ágeis em diversos segmentos há alguns anos. Durante o andamento de um projeto enorme surgiram algumas dificuldades em gerenciar ambientes e versões do software. Apesar de toda a agilidade os testadores ainda precisam que versões específicas, com bases de dados específicas, estejam instaladas em ambientes para homologar o sistema. Para piorar mesmo os desenvolvedores precisam ter uma instância de uma search engine (algo como o Lucene) e popular esta engine para que seja usável demora por volta de 10 horas.

Era preciso controlar qual desenvolvedor possui acesso à qual instalação da search engine e quais as versões instaladas em quais ambientes. No passado já ocorreu algumas vezes de um deployment para QA demorar mais que o esperado pela confusão generalizada de ambientes e isso atrasar o release para produção em uma semana.

A primeira proposta que eles tiveram foi clássica: vamos automatizar tudo. Construir um mega-sistema que controle o que está instalado onde, avise por email os responsáveis, tenha um controle de workflow, se integre ao sistema de QA, seja parte do IBM Tivoli, faça café… e seja extremamente caro.

Uma outra proposta surgiu do “grupo de governança” da empresa: ninguém faz deployment de nada sem ser autorizado. Toda vez que alguém precisa subir algo para QA ou outro ambiente precisa usar o Jira, toda vez que alguém precisar de uma modificação numa instancia da search engine precisa usar o Jira. Todos os pedidos são aprovados pelas pessoas competentes.

Aí começa o trabalho da nossa equipe: como ter o benefício esperado sem ter que vender a empresa pra comprar o sistema ou passar 20% do tempo preenchendo formulários?

O início deste trabalho foi feito seis meses atrás e foi parte do meu primeiro projeto aqui. Apos analisarmos o sistemas vimos que ele era estupidamente complexo sem a menor necessidade. O débito técnico foi se acumulando com o passar dos anos e uma coisa simples como instalar um WAR no Tomcat estava levando mais de duas horas, e trabalhando em par! Um dos grandes problemas era que das duas horas uma você gastava andando pelo corredor perguntando para outras pessoas o que fazer no caso X, qual a versão que está no servidor Y, etc.

A primeira coisa a se fazer era resolver o débito técnico. Não há solução que agüente mais de um mês em pé com aquela quantidade de problemas para resolver (incluindo um build que durava mais de quarenta minutos). Para isso os donos do negocio aceitaram alocar 10% dos pontos de uma iteração e, conforme a previsão, a maioria dos problemas graves se solucionou em cinco meses.

Enquanto isso, para amenizar o problema de maneira imediata, nós resolvemos usar um quadro-branco com a configuração dos ambientes. Quando a pressão do release passou o quadro foi para no wiki interno, numa grande tabela que qualquer um editava. Para o problema das instâncias de search engine nós criamos tokens: cada instancia tinha um cartão. Se você precisa de uma instancia você vai até uma parede e pega um cartão, adiciona as configurações daquela instancia na sua máquina e cola o cartão no seu monitor.

Simples e eficiente, a solução do cartão dura até hoje. O mesmo não se pode dizer do wiki. Enquanto o grupo de usuários era pequeno o wiki serviu de maneira ótima, após passarmos de algumas dezenas de pessoas -e diversos sub-projetos e spikes rodando em paralelo- ele se tornou inviável. O problema é que a tabela não comporta mais todos os dados de maneira eficiente e qualquer tentativa de organizar em sub-páginas faz com que as pessoas “esqueçam” de atualizar o wiki. Solução? Seguir o exemplo do que deu certo: cartões!

Acima você pode ver uma das paredes de cartões para nosso controle de mudanças e versões. O cartão rosa, no topo, tem o nome do ambiente. Cada um dos cartões azuis abaixo deste representa um dos componentes, os post-it laranja indicam as versões que foram instaladas. Os amarelos indicam qual instancia da search engine é usada em qual ambiente.

Os outros post-its colados nos cartões são meta-dados, eles indicam, por exemplo, que um serviço está inativo:

Esta solução tem funcionado nos últimos meses de maneira exemplar. Na verdade ela funciona tão bem que o problema agora é convencer os analistas de negocio que o problema do deployment não está solucionado e que eles ainda precisam investir nele.

Uma das conseqüências dessa técnica é que as duas pessoas que ficavam alocadas 100% do tempo gerenciando ambientes estarão em breve voltando a desenvolver as histórias e gerar valor de negócios ao invés de dar suporte aos desenvolvedores.

Muitas vezes você não precisa de milhões de dólares nem de burocracia, basta pensar fora da caixa.

Esta então é a prometida lista de livros para desenvolvedores. Claro que não é nenhuma lista exclusiva ou “o guia definitivo”, apenas minha recomendação de leitura, partindo do principio que você já sabe programar em uma linguagem como Ruby, C# ou Java.

Este guia é bem genérico, sem tentar se especializar em nada e sem tentar abranger mais que o mínimo necessário. Espere modificações nesta lista.

1. Operating Systems: Design and Implementation: Este ode não ser o melhor livro sobre Sistemas operacionais –ou pelo menos não o mais didático- mas eu gosto bastante. A maioria dos conceitos básicos de um Sistema Operacional está presente mesmo nas máquinas virtuais e seja como for, antes de abstrair você precisa entender como seu computador funciona. Claro que se você cursou SO na faculdade e, principalmente, se lembra de como memória virtual, filesystems e demais funcionam pode passar por este item –eu acho que uns 5% dos desenvolvedores que conheço se enquadram nisso, entretanto.
2. Fundamentals of Object-Oriented Design in UML: Este livro ensina métricas e princípios básicos para desenvolvimento de sistemas Orientados a Objetos. Se você passou por projeto estruturado provavelmente conhece o autor e algumas de suas métricas.
3. Head First Design Patterns: Uma introdução suave aos Design Patterns. A vantagem em começar com este ao invés do clássico (que é o próximo na lista de qualquer modo) é que você não tem que lidar logo de cara com Smalltalk e C++. Aprender um conceito não-tão-simples quanto Design Patterns enquanto tenta entender uma sintaxe fora do dia-a-dia é criar complexidade acidental.
4. Design Patterns: Elements of Reusable Object-Oriented Software: Apesar de não ser indicado ao iniciante eu não acredito que voc6e consiga ir muito longe sem ler este livro. Pelo menos as narrativas são fundamentais para entender as motivações e a evolução do conceito de patterns. A falta desta leitura faz com que pessoas cometam erros grotescos.
5. Agile Software Development, Principles, Patterns, and Practices: (em versão Java ou .Net) este livro traz uma visão bem pratica sobre alguns aspectos mais teóricos da Orientação a Objetos. Como u organizo pacotes? Qual o problema em ter dependências e como me livro delas? Devo sempre retornar null? O que significa herança na pratica?
6. Refactoring: Improving the Design of Existing Code: Conforme você for entendendo mais sobre design de software vai sentir uma vontade enlouquecedora de apagar todo o seu sistema e começar de novo. Antes de sair por aí cometendo carreiracídio leia este livro, ele vai te ensinar a fazer pequenas mudanças que melhoram a qualidade do sistema e identificar código que fede.
7. Patterns of Enterprise Application Architecture: A maioria dos patterns que você teve contato até aqui tratam de design em um nível micro. Como classes interagem, como elas colaboram e como gerenciar seus problemas. Este livro, entretanto, fala sobre padrões em um contexto mais amplo, sobre arquitetura de software.
8. Domain Driven Design: Os livros até então falam de sotware pelo software. Como criar uma classe, como gerenciar dependências entre classes… mas ninguém te mostrou o que deve ser uma classe e o que não deve. Eric Evans supre esta demanda mostrando uma abordagem simples e eficiente para criar domínios que se aproximam do mundo real.
9. POJOs in Action e/ou Applying Domain-Driven Design and Patterns: With Examples in C# and .NET: É normal que exista uma certa dificuldade em levar estes conceitos para o dia-a-dia. Estes livros não são indispensáveis mas eles ajudam bastante a entender como aplicar conceitos, ainda que algumas vezes de maneira “não canônica” mas ainda assim eficaz.
10. The Pragmatic Programmer: From Journeyman to Master: Infelizmente muitas vezes, especialmente em consultorias de três letrinhas e faculdades McDonald’s, não temos um ambiente sadio para nos ensinar como programadores profissionais se comportam. Este genial livro traz uma boa parcela deste conhecimento condensado. Eu adicionaria o The Art of UNIX Programming, especialmente para aqueles que vêm de uma cultura drag’n'drop para o mundo real
11. Ship it! A Practical Guide to Successful Software Projects Este livro é bem interessante para entender como um desenvolvedor utiliza ferramentas simples como controle de versão e issue tracker. Ótimo par aquém está profissionalizando uma empresa.
12. Agile and Iterative Development: A Manager’s Guide Antes de você se dedicar a estudar mais uma metodologia de desenvolvimento em específico uma boa idéia é ler este livro, que traz um apanhado de diversas metodologias e as compara.

Com mais calma agora, volto a falar do evento. O fórum foi patrocinado pela IASA, que possui um capítulo bem forte em Melbourne. A idéia é prover mais mesas redondas do que apresentações, minha palestra foi uma das três únicas que não seguiam este formato.

Eu cheguei atrasado e fui direto para uma mesa redonda sobre REST x SOAP. O apresentador/moderador era claramente tendencioso a favorecer REST e, apesar de adorar essa arquitetura, eu acho que isso foi uma falha grave. A parte boa foi que diversas pessoas tentaram defender SOAP usando argumentos bem interessantes. Nenhum deles me convenceu inteiramente mas me fizeram pensar sobre alguns cenários onde usar REST seria reinventar SOAP, ainda que mais coeso.

Minha apresentação foi bem interessante, eu não sei estimar tempo de palestras em inglês ainda e acabei usando apenas 30 minutos dos 50 esperados. Isso acabou sendo bom porque houveram muitas perguntas, especialmente sobre os widgets em JavaScript. No final da apresentação eu tive uma conversa muito interessante com uma pessoa que foi arquiteto de um dos principais canais de TV australianos e é impressionante como os cenários e problemas são os mesmos.

Durante o resto do dia eu fiquei no stand da ThoughtWorks conversando com as pessoas. Foi bem interessante ver o que os arquitetos presentes pensam da ThoughtWorks e fazer contatos profissionais, tanto para possíveis futuros colegas quanto para futuras oportunidades de projetos.

Uma coisa engraçada em eventos ora do Brasil é que apesar de nos consideramos os seres mais sociais do universo conhecido nossos ventos são sobre grupinhos. As pessoas não interagem com desconhecido. Nos eventos aqui e em outros países, no entanto, é tudo sobre networking. Chega a ser meio constrangedor você está saindo do banheiro e alguém fala um “Oi, eu sou X, quem é você?”.

Segunda-feira eu embarco para Sydney para mais um dia de evento. Isto é algo também interessante, como o evento é durante a semana e Melbourne e Sydney são cidades distantes o mesmo evento ocorre nos dois lugares.

Estes últimos dias (meses?) foram bem corridos e eu fico feliz de pelo menos esta tarefa se concluir.

A apresentaçao em Melbourne acabou de terminar. Foi bem interessante e o evento em si está sendo uma experiência diferente. É algo mais como mesas redondas do que apresentações, mais sobre isso depois.

| View | Upload your own

Aproveitando, agradecendo novemente ao Antônio Carlos pela liberação dos nomes e marcas, a apresentação ia ficar bem sem graça sem os screenshots :)

Falando em coisas agitadas, fui convidado para palestrar no Australian Architecture Forum 2008. O título é “Lightweight SOA Through Web Widgets” e falar de SOA com REST num evento onde vai estar presente o impagável Jim Webber é algo bem diferente.

Como meu Google Analytics diz que ese blog é acessado por pessoas aqui na Austrália fica o convite.

Recebi este e-mail esses dias (nome oculto por falta de permissão do autor):

[…]

Eu trabalho com Java a pouco tempo (desde maio de 2006), mas sempre procurei aprender bastante. Na época eu não conhecia nada, […] não sabia Java a fundo[…] comecei num projeto que já tinha essa arquitetura de usar TO, BO, etc. e tal, e a partir dele comecei a aprender e abstrair, com isso acabei criando umas coisas que depois viraram o “framework das arquiteturas” da empresa, framework que segue aquela porcaria de lógica de negócio separado de dados. Não trabalho mais nessa empresa, e meu antigo analista me fala com orgulho que aquele framework que fiz já é base para 5 projetos, me deixa feliz e ao mesmo tempo preocupado. Hoje estou em outra, e faltamente com a responsabilidade de novo de definir a arquitetura dos projetos (não acho que tenha experiência suficiente
para isso, mas eu tento estudar ao Maximo e fazer o melhor), e dessa vez, o negócio é grande, pois a empresa é infinitamente maior.

Lendo as várias discussões que vocês têm no GUJ, bem como seu blog, eu tenho certeza que aquele framework era errado. Quando criei, ainda era dependente de tecnologias, muita coisa mudou, e no fim não era mais dependente de nenhum framework especifico, ele continha uns utilitários, as interfaces e algumas abstrações para serem implementadas e especializadas em cada projeto, mesmo assim não
consegui juntar os dados com a lógica.

Bem, juntar eu até consigo, mas ai não consigo mais imaginar um framework, perfeito, vocês falam que esse framework é, teoricamente, uma coisa ruim. Porem morrendo esse cara, todos meus programadores terão de programar o modelo sempre do zero, bem como saber programar
da forma certa (o que acredite em mim, acho que 80% das pessoas não fazem noção nem do que é a forma certa, quem dirá fazer, eu posso ser uma delas, mas pelo menos tenho noção de que da forma que esta feito, é errado), ai que volto a pensar em ter um framework para eles
estenderem e não precisarem se preocupar com tanta coisa.

Ai surgem minhas duvidas, para mim, seguir os conceitos de DSL, DDD, Fluent Interfaces etc. é algo que exige do programador um bom conhecimento, e eu não tenho muita experiência com bons programadores, a maioria se quer sabe a importância de uma interface, programa em
Java como se estivesse programando em C, como cobrar desses caras uns conceitos que nem eu entendo a fundo, ai volto a pensar naquele framework, que ao menos obriga eles seguirem algo dividido em camadas, fazendo eles separar a lógica de negocio do acesso aos dados, a lógica de negocio de cliente da lógica de negocio de fornecedor, enfim, consigo que pelo menos saia algo não tão feio, e que em eventuais manutenções consigo fazer de forma rápida.

Mas para mim isso é péssimo, porque não consigo evoluir, não consigo aplicar nos projetos as coisas que gostaria de aprender. Mas acho que a culpa é minha, porque em todo lugar tem programadores que devem não conhecer, e isso não pode ser um impeditivo.

Por isso, gostaria muito que você me indicasse livros, mas que seguisse uma ordem certa de aprendizado, o que eu preciso saber primeiro, depois e depois, eu não sei se eu devo começar lendo sobre a modelagem em si, ou conceitos DDD, DSL, sei la, queria apenas que você me guia-se recomendando links e principalmente livros.

Por exemplo, nesse tópico você deu exemplo de vários livros http://guj.com.br/posts/list/60/71466.java (na pagina 5 do tópico), qual seria o mais recomendado para iniciar, e depois, depois etc. […]

Antes de mais nada eu diria que você está na trilha certa. A primeira coisa que um bom arquiteto deve fazer é se questionar o tempo todo, e justificar suas escolhas para si mesmo antes mesmo de alguém falar qualquer coisa.

Uma coisa que você precisa ter em mente é que o framework perfeito não existe. Quando discutimos design muitas vezes focamos no ideal, mas nem sempre o ideal deve ser implementado. Dificuldades tecnológicas são um grande fator, mas como você mesmo notou um fator muito importante é que arquitetura é sobre pessoas. Não adianta você ter a arquitetura tecnologicamente, perfeita, o design que melhor modela seu domínio e a maior performance possível se seus desenvolvedores não entendem ou não entenderão este zoológico.

Eu fui freelancer por um bom tempo, e nesse período não só eu era completamente verde sobre tecnologias bem como na época o acesso à informação era restrito (Internet só depois da meia-noite, lembra do pulso único?). Ainda assim eu tive que definir arquiteturas para alguns sistemas que duram até hoje, e aprendi bastante com isso.

Uma das coisas que aprendi é um clichê: Keep it Simple. Uma boa arquitetura, sofisticada ou não, é composta de primitivas arquiteturais bem definidas. Para entender essa afirmação pense na linguagem Java. A linguagem possui primitivas que giram em torno de objetos, definidos por classes que trocam mensagens através de métodos. Você não precisa de exceções à estas primitivas, consegue implementar tudo no seu sistema com elas. Assim deve ser sua arquitetura.

Se você ainda não tem conhecimento para utilizar conceitos mais rebuscados se mantenha simples e elegante -e elegante para mim significa ter boas primitivas e pouquíssimas exceções. Claro que sua arquitetura não vai servir para todas as coisas mas lembre-se que arquiteturas devem ser pensadas de acordo com o projeto, não existe arquitetura de referência.

Mas se eu não tenho uma arquitetura de referencia como confio nos meus desenvolvedores? Primeiro você deve contratar desenvolvedores bons, ou experientes ou com um bom potencial. Como falei diversas vezes neste blog entre 2005 e 2007 uns bons 40% do meu tempo foi dedicado contratando gente. O que eu aprendi nessa fase é que os bons desenvolvedores dificilmente vão caber no seu orçamento. Eles já são superstars em outras empresas. O que você precisa fazer é criar um time de pessoas eficientes, compromissadas e competentes. Este tipo de pessoa pode não ter a bagagem técnica necessária mas possui um potencial tão grande que você cria seus próprios superstars.

Mas se você não está contratando ninguém, como fica? Então você precisa é de gerencia de conhecimento. Muitas vezes eu já entrei num projeto onde as pessoas repetiam um mantra qualquer como “Não podemos fazer isso porque vai dar conflito com a rebimboca” o tempo todo e quando você pergunta ninguém consegue te explicar direito o que é a tal rebimboca ou porque ela cisma de conflitar com seu software.

Pense no seguinte: se as pessoas fossem ler por si só livros e bibliografias complicadas elas já teriam feito isso por elas mesmas. Se elas não procuraram para ter sucesso profissional elas não vão procurar apenas para entender seu software.

Criou uma arquitetura nova? Crie uma página no wiki da empresa (ou na Intranet, ou sei lá) contendo a descrição do que vocês fizeram. Não pense numa especificação de arquitetura, pense que você está escrevendo um artigo para um grande site sobre a arquitetura. O objetivo é criar algo útil e informativo. Organize sessões onde as pessoas troquem conhecimentos, talvez através de palestras ou de lighting talks ao menos duas vezes por mês.

E quanto aos livros? Recomendar livros depende muito do que você quer aprender. Eu não vou recomendar os livros neste post, vou tentar fazer algo mais abrangente e criar uma serie de posts chamados Proposta de Trilha. Eles vão conter uma bibliografia que eu ache interessante e na ordem que eu gostaria ter seguido. Imagino posts específicos para: Desenvolvedor, Arquiteto, Testador e Gerente de Projeto. Talvez mais, talvez menos.

Todo projeto que já participei, dos meus pet-projects até os com equipes imensas, possuem algum nível de tech debt. Sempre a mesma história: não temos tempo para isso agora, na próxima oportunidade corrigimos.

O problema é que em muitos casos o acúmulo de coisas que deixamos pelo meio do caminho é prejudicial à saúde do projeto. Mais que preciosismo de nerds e perfeccionistas, tech debt pode –e geralmente vai- atrasar o andamento do time.

Nos projetos que eu gerencio eu gosto de alocar um orçamento para resolver estes problemas. Durante o planning game eu deixo claro que precisamos resolver problemas enquanto estamos implementando funcionalidades e geralmente aloco alguns pontos na iteração para eles, normalmente algo perto de 20% do trabalho. Normalmente eu aceito que estas histórias técnicas tenham prioridade baixa e no geral tudo ocorre bem.

Se temos uma emergência então eu costumo não ser muito flexível em relação à solução do problema. As histórias técnicas neste caso ganham prioridade máxima dentro da iteração.

Como geralmente o cliente está satisfeito com a velocidade da equipe num processo ágil (se não está temos outro problema) quando sobra –e quase sempre sobra- tempo extra numa iteração geralmente eu preencho com tech debt, e em especial deixo os desenvolvedores priorizarem o que querem fazer. Muitas vezes não dá tempo para fazer homologação destas mudanças durante a iteração vigente e elas acabam indo para produção apenas na iteração posterior, mas é uma boa estratégia.

O que importa é não deixar o tech debt acumular. Se você tem duvidas dos problemas que o acúmulo de histórias técnicas causam basta lembrar a última vez que você entrou em um projeto para dar manutenção em um sistema pré-existente. Eu nunca vi um caso onde o sistema antigo não tenha toneladas de problemas causados por “deixar para depois” mudanças que não eram urgentes mas foram crescendo em urgência com o tempo.

E claro que meu projeto atual não é diferente. Trata-se da conversão de boa parte de um sistema legado em Java para Ruby (não Rails, Ruby). Como todo projeto deste tipo o orçamento não contempla uma reescrita do sistema, apenas uma conversão. Isso quer dizer que se um módulo assovia e chupa cana em Java ele, teoricamente, vai assoviar e chupar cana em Ruby.

O bom de trabalhar em um time ágil é que não é porque no início do projeto não se pensou em melhorar as coisas que isso precisa ser verdade até o fim dele. Após a equipe (desenvolvedores, analistas de negócios e gerente de projetos) percebemos que alguns itens realmente estavam atrapalhando o andamento do projeto. Nossos dias estão cercados de tarefas repetitivas que existem apenas para contornar alguma “gambiarra” que o sistema original tinha e nós estamos reproduzindo de maneira burra. Levamos a questão aos clientes e fizemos entender que se gastarmos alguns pontos nestas tarefas em algumas iterações nossa velocidade irá aumentar, e muito.

Apos conseguirmos 25% dos pontos de uma iteração para histórias técnicas veio a questão: temos dezenas de problemas, o que faremos primeiro? Como é um time grande cada um tem seu ponto de vista sobre o que está errado e o que precisa melhorar, então fizemos da maneira ágil: disciplina e flexibilidade.

Marcamos uma reunião com o time e coletamos em cartões todos os problemas que conseguíssemos pensar. Os cartões foram pregados na parede, divididos entre coisas do dia-a-dia e coisas que realmente indicam a visão que o sistema deve tomar, aspectos arquiteturais.

Depois cada um recebeu 5 votos para distribuir entre os cartões. Quase todas as histórias eram importantes então precisamos limitar o numero de votos para entender o que realmente é critico.

Apos este exercício nós criamos um backlog paralelo para o produto, apenas com histórias técnicas. Este backlog foi estimado e baseado nele o time decide que história técnica entra nos 25% de pontos disponíveis.

Uma das vantagens dessa abordagem já foi percebida. Nosso sistema é um fluxo de operações em sequência. Operações em sequência são uma ótima área para programação procedural e isso fez com que os desenvolvedores originais do sistema seguissem este paradigma.

Claro que quando se mistura uma linguagem orientada a Objetos com código procedural é necessária muita cautela, e a maioria das pessoas acha que para o código ser procedural basta usar atributos públicos nas suas classes. Existem muitas métricas para qualidade de código procedural (a maioria das métricas de código OO são evoluções ou adaptações destas, na verdade) e nosso código não seguia nenhuma.

Aproveitando o nosso orçamento para histórias técnicas nós introduzimos um sistemas de jobs, uma implementação do padrão Chain of Responsibility. Até agora 50% das funções já foram convertidas para o modelo novo e a cada iteração mais são convertidas.

O resultado das ultimas iterações mostra um aumento consistente de 10% na velocidade. Todos os envolvido creditam esta melhoria à mudança e ainda estimamos que quando todo o sistema for convertido para a nova arquitetura teremos por volta de 25% de aumento total.

Existem coisas simples que podem decidir se um projeto vai ser um sucesso ou fracasso. Não esconder sujeira debaixo do tapete é uma delas.

O Laércio Queiroz me entrevistou sobre DSLs. O resultado você vê no blog dele.