Archive for the ‘artigos’ Category

Fazer e Falar

Saturday, May 15th, 2010

Eu sou terrivelmente tímido. Você pode não acreditar dada a facilidade em que eu me meto em pagação de mico, mas esta é a verdade. Eu simplesmente morro de medo de começar uma conversa com uma pessoa que não conheço; o único motivo de fazê-lo com certa naturalidade hoje em dia é porque, apos tantos anos, eu descobri que ou me forço a falar com pessoas ou minha vida não vai para a frente.

A timidez me trouxe muitas coisas ruins mas também moldou meu comportamento de algumas formas que considero benéficas. Uma das conseqüências da timidez é que eu sou bem ruim em convencer os outros de alguma coisa. Isso é horrível em diversos cenários, mas uma coisa boa é que eu aprendi que antes de tentar convencer alguém é melhor ter meus argumentos, provas e protótipos prontos.

E, felizmente, durante a minha vida eu encontrei muitas pessoas com um comportamento parecido –ainda que, na maioria das vezes, não gerado por timidez mas sim por algum outro motivo. Especialmente, eu vi diversas vezes e espero continuar vendo o impacto que um time de “fazedores” tem em uma organização.

O cenário é sempre igual. Determinado lugar, seja um dos meus clientes atuais ou alguma das empresas para quem já trabalhei, possui um grupo de pessoas de alto prestígio dentro de casa. Infelizmente estas pessoas não entregam nada há anos, eles apenas vivem de política. Por algum motivo é formado um time com pessoas que se preocupam mais com fazer do que falar. Este time acaba entregando em uma cadência bem superior do que o melhor dos times antigos. A empresa fica feliz, os gestores resolvem espalhar a “cultura do fazer” (que sempre toma um nome mais buzzwordy como “agile”, “lean”, “times auto-geridos”, “gestão 2.0” ou coisa que o valha).

O problema é que a cultura do fazer não escala muito bem. As pessoas que preferem fazer à falar são chamadas pela diretoria e se pede a eles que ajudem a espalhar a boa nova para toda a organização. Neste ponto, em minha experiência, o time original se divide em dois.

O primeiro grupo é formado por pessoas que vêem na oportunidade um reconhecimento de que, finalmente, atingiram o nível de “ninja” –ou qualquer outro nome saído de algum desenho animado que os desenvolvedores superstar resolvam usar—e sua missão agora é virar alguma espécie de evangelista. Estas pessoas, então, passam a maior parte do seu tempo falando, e quando fazem alguma coisa estão ou trabalhando em algum projeto para reinventar a roda ou atrapalhando a vida de alguém com alguma de suas idéias brilhantes.

O outro grupo até tenta entrar na roda. Eles vão às primeiras reuniões, aos coding dojos e aos outros eventos. Eventualmente eles percebem no que estão entrando. Eles percebem que, se ficarem ali, sua vida mudará. Eles entendem que seu novo cargo não é nem um pouco diferente daquelas antigas “pessoas de alto prestígio dentro da empresa”. Possivelmente eles descobrem que tais pessoas foram, um dia, fazedores. Que estas pessoas foram convertidos de fazedores para peso-morto em um processo parecido com o que se está iniciando.

E então ocorre algum cisma. O primeiro grupo, dos desenvolvedores hax0r-evangelista-superstar-ninja-estrelinha-blogueiro-palestrante-modelo-atriz-manequim fazem da torre de marfim sua nova casa. Os desenvolvedores do segundo grupo voltam para sua caverna e tentam continuar trabalhando em paz.

Eventualmente o grupo dos ninjas começa a contratar pessoas com uma opinião parecida com a sua própria. Em pouco tempo a empresa está tomada por um estilo que um amigo costuma chamar de “awesome, dude!” (em uma voz de americano que acabou de fumar alguma coisa estranha).

Existem alguns benefícios, claro. Os problemas históricos da empresa são, geralmente, trabalhados. O problema é que ao invés de resolver o problema o time awesome está mais interessado em usar as novas ferramentas ninja. Se a ferramenta ninja não possui o necessário para resolver o problema é melhor ainda, eles podem usar suas maravilhosas habilidades awesome para desenvolver o necessário –ainda que isso signifique fazer a organização pagar um custo absurdo para desenvolver infra-estrutura em casa quando existem centenas de alternativas consolidadas e amplamente disponíveis, ainda que não sejam ninja.

Apos algum tempo as coisas começam a ficar engraçadas. O clã dos ninjas perde prazo atrás de prazo, entregando novas rodas ao invés de valor de negócio. Quando a coisa começa a apertar, o clã lança uma bomba de fumaça e some na escuridão; sua fama no meio awesome-ninja-modelo-atriz-manequim já o garantiu um outro emprego de evangelista ou coisa parecida em outro lugar. Todos os filhotes de ninja ficam perdidos. Lideranças alternativas aparecem e guerras internas sobre o que, afinal, significa ser awesome destroem a produtividade. Plataformas são reescritas a cada quinze dias.

De repente, alguém repara que o único time que anda entregando algo é o time daquele povo que fazia parte do grupo de fazedores original mas recusou-se a converter em ninja awesome. Alguém resolve visitar a caverna destas pessoas e descobre o que restou deles lá dentro, no escuro, isolado das ondas de hype. Usando ferramentas e técnicas que fora banida pelos ninjas há muito.

Infelizmente nem todos estão ali, alguns já desistiram e foram para outras organizações. E, nestas organizações, eles vão eventualmente encontrar outro grupo de fazedores. E vão entregar software de qualidade e no prazo. E vão ser chamados pela gerencia para espalhar a boa nova pela empresa. E o ciclo se repete.

Aldo Dórea vs Fred Brooks

Tuesday, October 23rd, 2007

Eu não tenho nada contra a maioria dos gerentes de projetos mas se tem alguma coisa que me irrita é alguém que acha que gerenciar projeto de software e levantar um prédio é a mesma coisa. Veja bem: eu tenho uns bons dez anos de experiência com projetos e recomendo fortemente uma abordagem ágil, iterativa e incremental para eles, mas estou falando de projetos de software, não de projetos em geral. Eu não tenho a menor idéia se isso funcionaria para levantar um prédio, sei que funciona para software e por isso você não vai encontrar neste blog ou em alguma publicação minha qualquer dica para gerenciar a reforma do seu banheiro. Na verdade eu até evito comparações com outras engenharias porque elas sempre são danosas (o próprio conceito por trás do nome ‘engenharia de software’ é danoso).

Neste cenário temos o número atual da Mundo PM e um artigo de Aldo Dórea Mattos, M. Sc.. Aldo é um profissional com bastante experiência no mundo da construção civil. Segundo seu mini-curriculum na revista ele é engenheiro, advogado, mestre, já trabalhou em projetos em 4 países e é autor do livro “Como Preparar Orçamento de Obras”. Aldo escreveu um artigo com o título muito interessante de “Por que os cronogramas ‘furam’?”.

Em seu artigo Aldo foca em um relatório apresentado num grande congresso do PMI com este tema. O relatório foca… construção civil. Eu realmente achei que era uma leitura interessante até porque eu sempre tenho a dúvida se só nós sofremos com tantos problemas quando alguém cisma de usar técnicas de waterfall e controle total nos nossos projetos, mas o autor faz questão de citar este infeliz exemplo:

[...]O desenvolvimento de um cronograma é feito a partir de premissas de planejamento, que são pressupostos assumidos pelo GP e sua equipe. As premissas de planejamento estão na definição das produtividades que geram as durações das atividades - por exemplo produtividade do pedreiro no levantamento de uma parede de alvenaria (em m² /h), produtividade de um programador no desenvolvimento de linhas de programação (linhas/dia), produtividade de uma máquina na fabricação de componentes industriais (un/h)[...]

-Mundo PM #17, Pg 34

O que está errado na frase acima? Eu imagino que Aldo tenha muito conhecimento sobre construção civil, não imagino quanto de conhecimento ele tem sobre indústrias mas definitivamente não creio que ele saiba muito sobre programas de computador e quem os escreve.

Veja bem: ele compara o levantamento de uma parede -algo que é feito por um profissional com conhecimento meramente operacional- ou a produtividade de uma máquina à de um programador. Enquanto ainda não faz tal comparação infeliz o texto diz:

[...]A quantidade de recursos pode definir a duração da atividade ou, ao revés, ser determinada por ela. É só pensar numa tarefa alvenaria, cujo quantitativo seja de 600m² e cujo recurso prioritário seja pedreiro, com uma produtividade de 10m²/dia. Pode-se proceder de duas maneiras[...]fazer a parede em 15 dias, são requeridos 4 pedreiros; ou[...]com uma equipe de 5 pedreiros levanta-se a alvenaria em 12 dias[...]

-Mundo PM #17, Pg 33

Posso tirar pelo trecho seguinte, mostrado acima neste post, que o autor não faz distinção entre o tal pedreiro e sua parede do programador e seu código.

Como vocês estão carecas de saber eu já fui consultor, tanto autônomo quanto associado à uma empresa, incluindo empresas de três letras. Já entrei em muitos enormes clientes ansiosos por uma resposta aos seus problemas: por que eles não conseguem sequer prever o prejuízo num projeto de software? E sei que um artigo deste tipo cai como uma bala de prata.

Ops, bala de prata? Já que estamos neste tema vamos chamar ao diálogo Frederick Brooks, autor do paper seminal chamado “No Silver Bullet”. Fred também é uma pessoa importante no seu meio. Hoje dá aulas na Universidade da Carolina do Norte -onde fundou o departamento de Ciência da Computação- mas é mais conhecido como “o pai do Operating System/360″, um dos maiores projetos de software já realizados. Por este trabalho ele ganhou a medalha nacional de tecnologia dos EUA em 1985. Seu livro “Mythical Man-Month, The: Essays on Software Engineering” ganhou um dos prêmios mais importantes do mundo da computação, o Turing Award.

E lá vem Brooks discordar:

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 1

Não faz muito sentido comparar isso com um muro de tijolos, faz? E quem será que entende mais de software? E sobre recursos em um projeto?

The second fallacious thought mode is expressed in the very unit of effort used in estimating and scheduling: the man-month. Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them (Fig. 2.1). This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
[...]
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule [...]. The bearing of a child takes nine months, no matter how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 2

Não adianta você adicionar mais mulheres ao processo, a gestação dura quase sempre nove meses. Você não pode calcular progresso apenas pelo número de pessoas dividido pelo número de tarefas, isso é cálculo de padaria inútil no caso de software.

O problema não é nem a confusão feita pelo autor com relação à o que é um trabalhador relativamente operacional -pedreiro-, o que é uma máquina industrial e o que é um trabalhador de criatividade como um programador. O deslize de um é o de menos. O problema é que esse tipo de informação publicado numa revista que atinge a um mercado tão seleto quanto aos gerentes de projeto do Brasil (e que custa a bagatela de R$23,90) vai influenciar negativamente todo o mercado.

Eu tive que copiar trechos da SafariBookshelf (serviço que uso e recomendo) para fazer este post. Eu tenho o livro do Brooks, ou pelo menos tinha. Em algum momento de 2004 eu emprestei o livro para meu então Gerente de Projetos e ele nunca mais devolveu. Dia desses estive com ele e perguntei do livro, ele ficou de me devolver. Perguntei se ele leu e ele disse que não. O livro está na mesa dele há 3 anos e ele não leu, mas sei que ele assina a Mundo PM. A literatura ‘fácil’ ganha da literatura adequada, eu diria.

Eu continuo sem saber se construção civil e construção de software são parecidos o suficiente para utilizarem as mesmas técnicas de gerenciamento de projetos. O exemplo infeliz da revista me faz acreditar que não são, mas tem algo curioso nele: O artigo em si é sobre diversos problemas que resultam em atraso, problemas presentes em construção civil no caso mas que também acontecem em construção de software. As soluções que o autor propõe talvez funcionem em engenharia civil mas eu já as vi aplicadas à construção de software e… bem, não funcionam. Algo que tem funcionado com relativo sucesso para desenvolvimento de software, entretanto, é inverter os conceitos do artigo e tentar algo mais simples: metodologias ágeis. Se a construção civil sofre tanto de atrasos talvez, só talvez, seja a hora de uma das mais antigas engenharias aprender algo com uma das mais novas. Mas só talvez.

Se você quer saber como não fazer seus cronogramas ‘furarem’ em vez de gastar R$23,90 fiquem com uma frase de alguém que realmente entende de ciência da computação:

1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity starts, do not significantly change as the start time draws near, no matter how wrong they ultimately turn out to be.

–Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Capítulo 14

E pensem em como sua metodologia apóia este tipo de revisão de estimativa, como seu cronograma pode se adaptar a isso. Se não achou nada no seu cenário atual, mude.

Adaptação de Linguagens

Thursday, October 18th, 2007

Mais um texto no fragmental.tw, desta vez algo mais genérico sobre modificações em linguagens. Eu ando lendo bastante sobre linguagens embutidas em outras (DSLs Internas) e outras formas de modificação de linguagem como Fluent Interfaces. É bem complicado chegar à qualquer conclusão em temas tão abstratos mas a experiência no uso destas técncias no dia-a-dia e no laboratório me mostraram que existem diferenças entre as formas de alterar uma linguagem. Em Language-Oriented Programming você cria linguagens, com Fluent Interfaces não.

Bom, mais sobre isso em Language Adaption.

Você Pergunta 001: DAOs e Repositórios

Thursday, March 1st, 2007

Como todo mundo que bloga há anos, eu estou sem tempo e inspiração para escrever muito (dá pra ver a distância entre um post e outro), então resolvi colocar aqui algumas respostas de e-mails que recebo com questionamentos sobre artigos, posts e etc.

O primeiro segue abaixo:

fromLeandro André Zis
date Feb 23, 2007 11:15 PM
subject Artigo MVC e Camadas, Repositorio e DAOs

Ola Phillip,

No artigo MVC e Camadas mostra os DAOs herdando do repositorio, isto
esta correto?

Leandro Zis

Oi, Leandro,

Sim, está.

Um repositório é um conceito abstrato. Ele representa o lugar onde os objetos estão guardados esperando serem utilizados por alguma operação. Os outros objetos de negócio não enxergam nada além dele, ou seja, não sabem onde os objetos são guardados de fato, num banco de dados, arquivos CSV, etc.

Um DAO (Data Access Object) é uma encarnação do padrão Data Mapper cuja responsabilidade é mapear um objeto para tabelas e vice-versa.

Desta forma o DAO pode se tornar a implementação do Repositório. Os objetos de negócios sabem apenas que podem guardar e recuperar objetos do Repositório, nada além disso. Por baixo dos panos eles estão utilizando um DAO que implementa o Repositório, cuja responsabilidade é apenas salvar e recuperar objetos do banco de dados nada além disso.

Existem casos onde os Repositórios devem ter lógica de negócio incluída. Isso não é muito comum, se for o caso vale uma revisão do design da aplicação, mas se realmente for necessário aí provavelmente você vai querer criar o Repositório como uma classe de negócios que delega as atividades de persistência para um DAO. Fazer este Repositório com regras uma classe abstrata que o DAO herda seria ruim porque numa classe (o DAO) haveria responsabilidade de negócios e persistência.

[]s

VO, BO e Tudo Mais que você não deveria utilizar

Tuesday, January 2nd, 2007

Postei um novo artigo no wiki sobre o uso de VOs/BOs. Sim, mais um artigo sobre a prática questionável de utilizar “classes de dados” e “classes de lógica” em vez de objetos de verdade. A idéia é ter uma referência para indicar quando alguém citar “VO” ou “BO” em uma conversa.

Artigo Ressuscitado

Sunday, October 8th, 2006

Devido a pedidos, acabo de disponibilizar o artigo Identificando e Convertendo Código Orientado a Objetos e Código Procedural em PDF.

Este artigo foi publicado no PortalJava há alguns meses, mas infelizmente por problemas técnicos saiu do ar. Agora está disponível ;)

Artigo na MundoJava: Fontes (enfim) Disponíveis

Monday, June 5th, 2006

Para quem estava esperando e encheu a minha caixa postal e a do Guapo com e-mails (o que é bem legal, diga-se de passagem :D ) está disponível o código-fonte do meu último artigo.

Antes de mais nada quero deixar claro que a culpa no atraso foi minha unicamente, a Revista cumpriu seu papel, eu que tive problemas de tempo-espaço.

O código é basicamente o exemplo do texto (você não tem a revista ainda? Tá nas bancas, corre! - viu só, tô aprendendo marketing descarado…).

Como sei que muita gente estava esperando uma aplicação completa, o que fugia do escopo do texto, fiquem ligados que vocês vão ter uma surpresa em breve…

Strict POJOs

Tuesday, May 16th, 2006

Muito tem se falado em POJOs (Plain Old Java Objects), boas e más coisas. As boas coisas geralmente mencionam como é mais fácil desenvolver sem utilizar parafernalhas como EJB 2.x e sobre o poder que utilizar OO pura te dá. As coisas ruins falam sobre como a comunidade Java é formada por um bando de idiotas que acaba de descobrir que existe vida além de frameworks e dão para este conceito um nome estúpido.

Justificando a ‘abordagem POJO’, vamos tentar entender o porque do hype em cima de POJOs. Antes de mais nada vamos a uma definição:

Um POJO é um objeto java normal que não implementa nenhuma interface nem estende nenhuma classe específica de um framework.

Exemplificando, isso é um POJO:

public class Venda{

private List vendas = new ArrayList();

public void adicionarItem(Item i){
vendas.add(i);
}

}

Esta classe não depende de nenhum framework, ela lida apenas com os objetos do domínio em questão.

Mas isto não é um POJO:

public class AdicionarVendaServlet extends HttpServlet {
...
public void doGet (HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
venda.add(daoItens.get(req.getparameter("item"));
}
}

Porque para criar um Servlet você precisa estender uma classe do framework de Servlets.

E porque dar um nome para classes Java normais? Bem, segundo Fowler, um dos autores do termo, basicamente o termo surgiu como um vocabulário comum e cool para se referir a esta técnica. É aquela história de vocabulário comum que falamos outro dia.

Um sistema baseado em POJOs utilizando Camadas, DIP e outras técnicas para eliminar a dependência de frameworks e outras classes de infra-estrutura é bem interessante. Na revista Mundo Java deste mês há um artigo introdutório meu falando sobre como você pode aplicar POJOs no desenvolvimento do seu Domain Model, utilizando Patterns específicos.

Uma coisa que andei pensando estes dias é uma lei que restrinja ainda mais o acoplamento de POJOs na Camada de Negócios com a infra-estrutura. Taí o que eu chamo de Strict POJOs:

Um POJO só pode se relacionar diretamente com outro POJO ou com POJIs.

POJI são Plain Old java Interfaces, é o mesmo conceito de POJO aplicado a interfaces. A idéia é baseada no DIP (Dependency Inversion Principle, mais detalhes na revista) e a sua classe de infra-estrutura deve implementar uma POJI para poder ser utilizada por seu POJO. Confuso?

Exemplo:

Imagine que temos uma classe Usuario que precisa acessa o banco de dados para consultar seus grupos. Como é uma classe de negócio ela não deve nem pensar em encostar em hibernate, JDBC, JDO ou o que estiver utilizando. Normalmente alguém faria um DAO acessar o banco de dados e a classe de negócios utilizar o DAO. Bem, DAO é uma classe de infra-estrutura e para aplicarmos nosso conceito de Strict POJOs o Usuario não pode conversar com ela. E agora?

Abstraímos o banco de dados seguindo o padrão Repository:
public interface RepositorioGrupos{
public List listarGrupos(Usuario u);
}

Esta interface é uma POJI. Agora faremos nosso usuário lidar com esta interface ao invés de com o DAO:

public class Usuario{
private RepositorioGrupos repositorio=null;

/** Checa se o usuário pertence a um dado grupo */
public boolean pertenceA(Grupo g){
List meusGrupos = repositorio.listarGrupos(this);
boolean pertence = meusGrupos.contains(grupo);
return pertence;
}

}

E faremos o DAO implementar a interface RepositorioGrupos (essa parte foca para você).

A vantagem desta abordagem é separar completamente a infra-estrutura da sua aplicação. Se você trabalha com um processo onde se produzem diagramas antes de codificar, isto permite que você crie diagramas muito mais reais, já que neles você não precisa se preocupar com bancos de dados e etc. O uso de um framework como Spring ou Java EE 5.0 ajuda muito já que você não precisaria nem mesmo isntanciar seus objetos.

A idéia básica é que você deve manter seus objetos de negócio isolados de tudo que não seja regra de negócio.

Bom, espero que gostem do artigo ;)

NOTA: Os arquivos estarão disponíveis até o fim da semana. Deixe seu email aqui nos comentários e você será avisado.

Coluna no PortalJava

Monday, January 30th, 2006

Há algum tempo o pessoal do portalJava me chamou junto com outras pessoas para fazer parte do seu time de colunistas. Hoje foi lançada a parte de colunas do portal.

Minha primeira contribuição é entitulada Identificando e Convertendo Código Orientado a Objetos e Código Procedural e refelte mais ou menos o que eu penso em fazer nesta coluna: artigos curtos e práticos sobre conceitos amplos e teóricos aplicados.

Para feedback, os adminsitradores prepararam um fórum específico. Parabéns ao PJ pela iniciativa e estamos aí ;)

Matéria na Revista Mundo Java

Friday, January 13th, 2006

Este mês saiu um artigo meu na revista Mundo Java (edição 15). É uma transcrição da palestra sobre Camadas que ministrei na Maratona4Java de Brasília e no RioJUG, quem não teve oportundiade pode conferir o conteúdo.

Feedback é muito apreciado e aguardem próximas novidades ;)